Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full burden and discloses key behaviors such as sampling up to 10,000 records, default sample size 1,000, support for numeric/string/date columns, and automatic type detection. It does not mention side effects because it is a read-only analysis, but the disclosed operational traits are sufficient for informed use.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections, but it is lengthy and contains redundancy: 'What you'll get' and 'Analysis includes' overlap, and use cases repeat the 'Use this tool when' content. It could be trimmed significantly without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description compensates effectively with a 'What you'll get' section that outlines return information, plus performance notes and examples. It covers all essential aspects—purpose, usage, behavior, and parameters—making it complete for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions for all parameters, including defaults and bounds (e.g., sample_size min/max, include_outliers default). The description adds little beyond the schema; the 'Performance notes' mostly echo parameter constraints, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Perform advanced statistical analysis of a column's data distribution including nulls, distinct values, percentiles, and outlier detection.' This uses a specific verb and resource, and clearly differentiates from siblings like get_table_schema or execute_query by focusing on distribution profiling and statistics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit 'Use this tool when' list and multiple example queries, giving clear context for when to deploy this tool. However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden. It discloses the read-only nature implicitly through 'Browse and search' and details the expected output fields (package IDs, names, descriptions, categories, provider info, versions, sizes, pricing). It does not mention side effects, authentication requirements, or limitations, but for a non-mutating marketplace browse tool, this is acceptable and adds meaningful context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (when to use, what you'll get, categories, examples, use cases). It is front-loaded with the main purpose, and every section provides actionable information. There is no filler or redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although the tool is simple (2 optional params, no output schema), the description is comprehensive. It explains the tool's scope, typical use cases, example queries, and the structure of returned data. For an AI agent, it provides enough context to decide when and how to invoke the tool without additional information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents both parameters with descriptions, and schema coverage is 100%. The description adds value beyond the schema by supplying example queries and categories that clarify how to use the filters (e.g., 'currency' or 'benchmark' for search_term). This helps the agent map natural language to parameter values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb and resource: 'Browse and search available data packages in the SAP Datasphere marketplace.' It is distinctly different from sibling tools, which focus on connections, tables, queries, and administrative operations. The description also enumerates the types of data returned, further reinforcing its unique purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes an explicit 'Use this tool when:' section with concrete scenarios (e.g., 'What data packages are available?', 'Looking for external reference data'). It also provides example queries and use cases. However, it does not explicitly mention when not to use the tool or any sibling alternatives, so it stops short of full guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explicitly flags the tool as HIGH-RISK, requires user consent, states that passwords are auto-generated and shown once, and includes security notes about retention and privilege principles. This goes beyond a typical create operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with headings, bullet lists, a JSON example, and a CLI mapping. The high-risk warning is front-loaded, and every section adds practical value for such a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex nested parameters, absence of output schema, and high-risk nature, the description is remarkably complete. It covers return behavior ('password is auto-generated and returned'), parameter details, security warnings, usage examples, and even a CLI equivalent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds substantial meaning: it explains the nested user_definition structure in detail, clarifies that database_user_id is a suffix prefixed with space name, and recommends output_file for credential safety. This far exceeds the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Create a new database user in a SAP Datasphere space with specified permissions.' It clearly distinguishes this from sibling tools like list_database_users, update_database_user, and delete_database_user by focusing on creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'Use this tool when' bullets and example queries, making the intended use clear. It does not include when-not-to-use or alternative tool recommendations, but the context is strong enough for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and delivers richly: it labels the operation high-risk and write, requires consent, mentions audit logging, deploy behavior by default, mock mode, validation rules, injection prevention, and idempotency (fails if table exists).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with headers, bullet points, and code blocks. Each section (parameters, example, prerequisites, mock mode, security) earns its place, though some redundancy (e.g., repeated CLI command) could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers prerequisites, mock mode, security, and examples robustly. The only gap is that it merely states 'Returns the created table metadata' without detailing the response structure, and since there is no output schema, slightly more specificity would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: a full column JSON format with allowed types, defaults, regex validation, optional parameters explained, and a complete worked example. This goes well beyond the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a new local table in a SAP Datasphere space, with a specific verb and resource. It also distinguishes this tool from siblings by noting that views, analytic models, and other object types are CLI territory, not this tool's scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance, including concrete user queries ('Lege eine Tabelle X in Space Y an'), provisioning use cases, and prerequisites for real mode. It also warns against using this tool for other object types and directs to docs for those cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool never returns tokens or secrets, that session validity is checked via `config secrets check` without disclosing values, and that an unauthenticated state requires the user to run an interactive login. It also explains the behavioral distinction between the MCP server's OAuth identity and the CLI's separate session, preventing false confidence from a healthy MCP connection.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but every section earns its place: purpose, usage triggers, background, output contract, critical caveat, division of labour, and safety. It uses clear headers and bullets, front-loads the core purpose, and avoids redundancy. This is effective information density, not bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description provides a complete contract: output shape, diagnostic notes, security behavior, and user fallback instructions. It also clarifies the boundary between CLI capabilities and MCP tools, giving the agent full context for invocation and interpretation. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema provides no semantics; the baseline for 0 params is 4. The description adds value by detailing the output fields (`cli_available`, `cli_path`, `version`, `host`, `authenticated`, `notes`) and how to interpret them, but there is no parameter syntax to document. This meets the baseline and slightly exceeds it with output context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource statement: 'Check whether the SAP Datasphere CLI is installed, configured and logged in.' It clearly distinguishes this tool from siblings by explaining it validates the CLI's separate identity versus the MCP server's OAuth-based data access, and ties it to CLI-backed tools like create_table and *_database_user*.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'Use this tool when' bullets listing concrete triggers: after a CLI-backed tool fails, before promising object creation, and when diagnosing CLI/auth errors. It also includes a 'Division of labour' section that says when to use a CLI command instead of an MCP tool, and an 'Important' note that the agent cannot perform the interactive login. This is exemplary when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description takes full responsibility for disclosing behavioral traits. It explicitly states the action is IRREVERSIBLE, permanently deletes the user, terminates all active sessions, revokes all privileges, and logs the deletion for audit. It also warns about potential errors if the user owns objects, going well beyond what annotations could convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Although the description is long, it is highly structured with sections (IMPORTANT, WARNING, Use this tool when, What happens, Required parameters, Safety considerations, Before deleting, Example queries, Best practices, Note). Each section earns its place by addressing a distinct concern—risk, use cases, effects, parameters, safety, procedure, examples, best practices, and CLI mapping. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high-risk nature, absence of annotations, and lack of output schema, the description leaves nothing to guesswork. It covers the action, consequences, prerequisites, safety checks, step-by-step pre-deletion actions, example queries, and even a CLI equivalent. The tool is fully contextualized within its environment, making it safe for an agent to act on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents each parameter clearly. The description adds value by grouping them under 'Required parameters,' clarifying the force flag as optional, providing example queries that map to parameter values, and noting the uppercase requirement for space_id. While not dramatically expanding on the schema, it reinforces practical usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a database user from a SAP Datasphere space' with a specific verb and resource, and it distinguishes itself from sibling tools like create_database_user, update_database_user, and reset_database_user_password by focusing solely on deletion. The explicit 'Use this tool when' list reinforces its unique purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use scenarios (e.g., 'User explicitly requests...', 'Decommissioning user accounts') and a detailed 'Before deleting' checklist that includes verifying dependencies and getting approvals. It also suggests an alternative ('Consider deactivating instead of deleting') and references sibling tools like list_database_users for pre-checks, making usage boundaries crystal clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses critical behaviors: read-only access, blocked operations (INSERT, UPDATE, etc.), no SQL comments, query sanitization, user consent requirement, default row limit, and mock-data/OAuth notes. It even labels itself 'HIGH-RISK', providing strong transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with headers, bullet points, and front-loaded purpose and risk warnings. It is verbose and contains some redundancy (e.g., 'no write operations' repeated, 'user consent' mentioned twice), but each section adds useful information. Slightly over-long but organized enough to earn a 4.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (SQL execution, security restrictions), the description covers use cases, capabilities, security rules, best practices, examples, error handling, and environment-specific notes. However, with no output schema, it does not explicitly describe the exact response format (e.g., array of objects), leaving a minor gap in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters have rich descriptions in the input schema, covering defaults, ranges, case requirements, and syntax examples. The tool description adds examples and best practices but does not introduce new parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate due to 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Execute read-only SQL queries against SAP Datasphere tables to retrieve and analyze data.' It clearly states the tool's purpose and scope (read-only SQL on tables), distinguishing it from siblings like query_analytical_data or query_relational_entity. Examples further reinforce the SELECT-only nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a dedicated 'Use this tool when:' section with explicit scenarios (data retrieval, aggregations, joins, filtering). It also suggests checking table schema with get_table_schema() and mentions using search_tables() for missing tables. However, it does not explicitly name alternative tools or provide 'when not to use' exclusions, which prevents a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful details such as multi-space search by default, intelligent caching, a configurable 50-asset limit, and case-insensitive search. While it doesn't cover error handling or pagination, it gives a solid behavioral picture beyond the basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (overview, when to use, expected results, use cases, examples, performance notes). It is somewhat long but each section adds value and the core purpose is front-loaded. No wasted sentences, but it could be slightly more concise without losing substance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with no output schema and no annotations, this description is remarkably complete. It explicitly lists what the user will get (asset names, types, space IDs, column info, URLs), covers a wide range of use cases and example queries, and even notes performance characteristics. This fully compensates for the missing structured metadata.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema descriptions already cover 100% of parameters, so the baseline is 3. The tool description reinforces parameter usage through example queries but does not add significant semantic meaning beyond what the schema already provides. It correctly mentions default behaviors like case-insensitivity and the 50-asset limit, which appear in schema defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource+scope: 'Find all assets (tables/views) containing a specific column name across SAP Datasphere spaces.' This clearly distinguishes it from siblings like search_tables or get_table_schema, and the detailed use cases reinforce the tool's specialty in column-based discovery.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'Use this tool when' bullets and multiple use cases, giving clear context for when to invoke it. However, it does not explicitly name alternative tools or state 'when not to use' this tool, so it stops short of a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description is the only source of behavioral information. It discloses the automatic identification of analytical elements via SAP annotations and outlines the returned schema components. However, it does not mention any side effects, prerequisites, permission requirements, or failure behavior. For a read-only metadata retrieval, this is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences, immediately states the action and resource, and adds relevant detail about return content and behavior without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately covers the tool's purpose, return content, and a key behavior for a metadata retrieval tool. Without an output schema, it does enough to set expectations about dimensions, measures, hierarchies, and aggregation. However, it lacks information about the exact CSDL format or how missing annotations are handled, which could be useful but is not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description indirectly relates to the identify_dimensions_measures parameter by mentioning automatic identification, but does not provide explicit parameter-level guidance beyond the schema. The main parameters space_id and asset_id are only described in the schema, not elaborated further in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Retrieve' and clearly identifies the resource as 'CSDL metadata for analytical consumption of a specific asset.' It distinguishes itself from sibling tools like get_relational_metadata by explicitly specifying analytical metadata, and mentions the return schema content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context that this tool is for analytical and BI integration needs, but does not explicitly name alternatives or exclusion criteria. The context signals show several sibling metadata tools, but the description relies on the term 'analytical' to differentiate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the full behavioral disclosure burden. It does explain the CSDL parsing behavior, which is useful, but it doesn't explicitly confirm this is a read-only operation, mention required permissions, or warn about potentially large response sizes. The 'Get' verb implies non-destructive behavior, but as a general read tool, more explicit transparency would be better.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary function and a detailed list of return types. The second sentence adds value by explaining the CSDL parsing logic. There is no redundant or vague wording, and every word contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema is present, but the description explicitly lists the return contents (entity sets, dimensions, measures, query capabilities) and explains the parsing behavior, which compensates for the missing schema. However, it lacks guidance on when to choose this over similar tools, and does not mention any limitations or prerequisites. Given the tool's complexity (2 required params, technical metadata), this is reasonably complete but not perfect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with descriptions (asset_id, space_id, include_metadata), so the baseline is 3. The tool description does not add any extra meaning beyond what the schema already provides; it merely says 'specific analytical model' without elaborating on parameter roles or relationships.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the OData service document and metadata for a specific analytical model, including entity sets, dimensions, measures, and query capabilities. The mention of CSDL parsing and SAP aggregation roles adds a specific technical detail that distinguishes it from sibling tools like get_analytical_metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., get_analytical_metadata, list_analytical_datasets). It only describes what the tool does, leaving the agent to infer usage context without explicit exclusions or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It explains the compound-key mechanism, the API endpoint, and the comprehensive return content (dimensions, measures, relationships, technical/business context). This is robust disclosure for a read-only retrieval operation, exceeding the typical vague 'retrieves data'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than typical but well-structured with headings and bullet lists, and front-loaded with a concise summary sentence. Every section serves a clear purpose, though some repetition exists (e.g., 'same metadata as get_asset_details' appears twice in different forms).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter retrieval tool with no output schema, the description is exceptionally complete. It covers use cases, parameters with examples, behavior, endpoint, and comparison with sibling tools, leaving little ambiguity for an agent to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds substantial meaning: it explains how space_id and asset_id combine into the OData compound key, provides a concrete format example, and includes example queries. This enriches the parameter understanding beyond the schema's simple field types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Retrieve asset using OData compound key identifier' with a specific verb and resource, and immediately distinguishes it as an 'alternative access method' relative to get_asset_details. The title 'null' is compensated by a dense first sentence that precisely defines the tool's unique function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit bulleted 'Use this tool when' criteria and a dedicated 'When to use this vs get_asset_details' section, listing both scenarios and alternatives. This goes far beyond implied usage, giving the agent clear decision rules.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It is transparent about the tool's read-only nature (implicit via the GET endpoint note) and thoroughly discloses the output structure. It does not explicitly state 'does not modify data' or discuss potential errors, permissions, or rate limits, but for a metadata retrieval tool, the behavioral expectations are clearly conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with clear headings (Use this tool when, What you'll get, Required parameters, etc.). Every section contributes useful information, though there is some redundancy between 'Use this tool when' and 'Use cases' sections. It is front-loaded with the primary action and remains organized throughout.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (returns comprehensive metadata, no output schema), the description compensates admirably. It lists the full spectrum of returned information, includes the API endpoint for context, provides example queries, and covers parameter usage. It leaves little ambiguity about what the tool does and when to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes all parameters with examples (100% coverage), so baseline is 3. The description adds value by providing real-world example values (e.g., 'SAP_SC_FI_AM_FINTRANSACTIONS'), explaining the purpose of expand_fields with examples, and mapping parameters to use cases. This goes beyond the schema's dry field names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a clear, specific verb+resource statement: 'Get comprehensive metadata for a specific SAP Datasphere asset.' It then enumerates the detailed metadata fields (dimensions, measures, consumption URLs, relationships, etc.), which clearly distinguishes this tool from siblings like get_asset_by_compound_key or list_space_assets by focusing on a single asset's complete metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit 'Use this tool when' section with concrete scenarios (e.g., 'Show me details about the Financial Transactions asset') and a 'Use cases' list. However, it does not explicitly mention when not to use it or suggest alternative tools, stopping short of the full 5-point criteria for exclusions/alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the full burden. It discloses the source ($metadata) and return payload (variables, filter annotations, column list) with variable attributes. This is adequate for a read-only metadata retrieval operation, though it stops short of stating side-effect absence or potential errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences that front-load the action, then provide usage guidance and a summary of return values. Every sentence earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main use case (pre-query variable discovery), return fields, and the metadata source. It omits details on filter annotation structure or the meaning of 'wave 2026.10', but for an agent deciding whether to invoke the tool, the information is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions already cover both parameters (asset_id and space_id) with 100% coverage, so the description adds only marginal semantic context by referring to 'asset' and 'parameterised'. It does not further explain the parameters' relationship or any constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves input variables and filter-capability annotations from the OData $metadata of a SAP Datasphere asset. It specifies the exact resource (asset metadata) and distinguishes itself from sibling tools like get_asset_details or get_analytical_metadata by focusing on parameters and filter annotations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit usage context: 'Use this when the asset is parameterised' and before querying to know bindable variables and filterable fields. However, it does not name alternative sibling tools for non-parameterised assets, so the guidance is clear but not fully comparative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool shows granted vs. available scopes, includes scope descriptions, and lists the token's current scopes, which goes beyond a simple listing. It implies a read-only operation with no side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each adding value: it lists the output, the included details, and the usage scenario. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters, no output schema, and no annotations, the description fully covers what the tool does, what it returns, and when to use it. Nothing is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is 100%. The description correctly adds no parameter-specific information since none exist. Baseline for zero-param tools is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists OAuth2 scopes for the current user, distinguishing between granted and ungranted scopes. This is a specific verb+resource that differentiates it from sibling tools like get_current_user or get_tenant_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use it to understand API access capabilities and troubleshoot permission issues. It provides clear context for when to use the tool, though it does not mention alternatives or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It clearly indicates a non-mutating read operation ('Get') and describes the returned data (user ID, roles, permissions, account status). It does not explicitly state that no side effects occur, but the verb and context make this apparent for a simple profile endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main action, and every phrase earns its place. It lists result fields without redundancy and provides a clear usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple zero-parameter tool with no output schema, the description is complete: it states what the tool does, what information it returns, and gives a practical use case. No additional context is necessary to invoke or interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is 100% (vacuously). The description adds no parameter details because none exist. A baseline of 4 is appropriate since the schema is complete and no parameter explanation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' and identifies the resource as 'authenticated user information', listing key fields (ID, email, roles, etc.). This clearly distinguishes it from sibling tools like get_tenant_info or list_database_users.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'Use this to understand the current user's identity and access rights.' While no alternative tools are mentioned, the context is clear and there are no direct siblings that compete with this purpose, making the guidance sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the transparency burden. It discloses that the tool returns deployment status, runtime metrics, execution history, and performance statistics, and implies a read-only listing operation. It does not mention auth requirements or limitations, but for a list operation this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose and followed by concrete use cases. Every word earns its place, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description must convey return value nature. It mentions deployment status, metrics, execution history, and performance statistics, which gives a reasonable picture. It could be more explicit about output structure or the fact that both active and inactive objects can be listed, but overall it is adequate for a moderately parameterized tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all six parameters documented in the input schema. The description adds general context about what metrics and statuses are returned but does not provide parameter-specific details beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'runtime/deployed objects', specifying it operates in SAP Datasphere. It distinguishes the tool from sibling asset-listing tools by focusing on runtime/deployed objects and monitoring use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this for monitoring deployed assets, tracking execution status, analyzing runtime performance, and identifying active vs inactive objects.' This provides clear use contexts, though it stops short of naming alternative tools or explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the burden of disclosing behavior. It clearly indicates a read-only 'get' operation and details what content is retrieved (columns, keys, SQL, dimensions, transformations). While it doesn't mention permissions or side effects, the read-only nature is implied by the verb 'Get' and the listed return content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: two sentences that front-load the core purpose and then provide additional detail on object types and use cases. Every sentence adds value without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and lack of an output schema, the description provides helpful context by listing what is returned for each object type. It also differentiates from sibling tools by covering multiple object types, though it doesn't specify response structure or pagination. This is reasonably complete for a retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description does not add any additional parameter-specific semantics beyond what the schema provides, which aligns with the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('complete design-time object definition from SAP Datasphere repository'). It enumerates specific object types (tables, views, analytical models, data flows) and their content, which differentiates it from siblings like get_table_schema or get_asset_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases: 'understanding object implementation details, extracting schema information, or planning migrations.' This gives clear context for when to use the tool, though it does not explicitly mention when to prefer alternatives like get_table_schema or get_analytical_model.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It states 'Get' (read-only) and enumerates the returned metadata types, which is useful. However, it does not disclose any limitations, authentication requirements, error behavior, or how include_sql_types affects the response, leaving some transparency gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no extraneous words. The core purpose is front-loaded, and the second sentence adds relevant context about the intended workflow. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately describes return content (column definitions, data types, SQL type mappings, ETL capabilities). It does not cover error scenarios or pagination, but for a metadata retrieval tool with simple parameters, this is sufficient and complete enough for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions for all three parameters. The tool description does not add parameter-specific meaning beyond implying that the tool targets a specific entity (asset_id, space_id). Baseline 3 is appropriate since the schema handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Get detailed metadata for a specific relational entity' and enumerates the content (column definitions, data types, SQL type mappings, ETL extraction capabilities). This distinguishes it from siblings like get_relational_metadata (broader scope) and get_table_schema (narrower focus on table columns).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies the tool's niche: 'Optimized for data warehouse loading and transformation workflows,' which implies when to use it. However, it does not explicitly mention alternatives or cases where other metadata tools would be preferable, so it lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It transparently discloses the return content ('complete schema information including tables, columns, data types, primary/foreign keys, and relationships') and the SQL type mapping behavior. It does not mention potential limitations or output format, but for a read-only metadata retrieval tool, the level of disclosure is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the main action, and each sentence adds value: what it does, what it returns, and a key feature. No fluff or redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description sufficiently explains what the tool returns (complete schema info, relationships, SQL type mapping). It covers the core need for relational access and ETL planning. However, it could be slightly clearer about how this differs from similar metadata tools, and it doesn't mention any pagination or limit behavior, which might matter for large assets.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so all three parameters are already documented. The description adds no extra meaning beyond what the schema provides; it only mentions SQL type mapping, which is already described in the schema. Baseline 3 is appropriate since the description doesn't need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Retrieve CSDL metadata for relational consumption of a specific asset.' It specifies the resource (CSDL metadata for a specific asset) and the purpose (relational consumption), and it lists concrete deliverables (tables, columns, data types, keys, relationships) that distinguish it from siblings like get_analytical_metadata or get_table_schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives context ('for relational data access and ETL planning') which implies when to use it, but it does not explicitly differentiate from closely related siblings like get_relational_entity_metadata or list_relational_entities. There is no explicit 'when not to use' or alternative recommendation, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly warns that the list is not the whole space, explains it comes from the Catalog API and only includes deployed/exposed objects, and details what will be returned (asset names, descriptions, types, exposure status, consumption URLs, timestamps, counts, pagination info). This is highly transparent and goes beyond a simple listing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with clear headers (use when, what you'll get, examples, filters, asset types, use cases). It is front-loaded with the core purpose. Some redundancy exists between 'Example queries' and 'Use cases,' but every section contributes meaningfully, so the length is justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no output schema, and no annotations, the description is remarkably complete. It explains the API endpoint, limitations, return content, pagination behavior, asset types, and provides usage examples. It even offers guidance on alternative tools when results are missing, fully contextualizing the tool within its environment.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description substantially enriches parameter understanding. It provides example filter expressions for common use cases (by type, exposed only, name pattern, combined), lists asset types with semantics, and gives example queries. This goes well beyond the schema's terse descriptions, making the filter_expression parameter actionable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource+scope: 'List all data assets within a specific SAP Datasphere space.' It clearly distinguishes from siblings like list_catalog_assets and search_catalog by emphasizing the space-scoped browsing, and explicitly mentions the alternative list_repository_objects for missing objects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

A dedicated 'Use this tool when' section lists concrete scenarios, and the description gives explicit exclusion guidance: 'If something you expect is missing, check the repository with list_repository_objects before telling the user it does not exist.' This tells the agent both when to use and when not to use the tool, with an alternative named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses output contents (metadata, tables/views, schemas, row counts, connection info) and error behavior (if space not found, list_spaces() shows available spaces). It does not explicitly state read-only nature, but the wording strongly implies it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, when to use, what you'll get, parameter, examples, errors). It is slightly verbose but every section adds practical context. Slight redundancy with the parameter requirement already in schema, so not perfect.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description compensates with a detailed list of returned data types. It covers purpose, usage, expected output, parameter specifics, and error handling. Missing only minor details like performance implications, but is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and already documents space_id with UPPERCASE requirement and examples. The description repeats this without adding new semantic meaning, so it meets the baseline but does not go beyond.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description opens with a specific verb and resource: 'Get comprehensive information about a specific SAP Datasphere space.' It clearly lists what is included (metadata, tables/views, schemas, row counts, connection info) and implicitly distinguishes from sibling tools like list_spaces by focusing on a single space.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Includes a dedicated 'Use this tool when' section with concrete triggers (user asks about a specific space, need to see tables/views, checking configuration). It explicitly mentions following up from list_spaces() results and suggests list_spaces as an alternative when space is not found.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description must disclose behavioral details. It does so by listing what the response includes (column list, data types, primary key indicators, descriptions, table metadata) and noting the case-sensitivity of the table name. It doesn't mention potential errors or permission requirements, but for a read-only schema lookup, the disclosure is reasonably thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but well-structured with clear headings and bullet points. Each section (use cases, expected output, parameters, examples, best practices, next steps) contributes to usability. There is some minor redundancy with schema details, but the organization makes it easy to scan quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with only 2 parameters, no output schema, and no annotations, the description is extremely comprehensive. It covers when to use the tool, what results to expect, parameter constraints, example queries, best practices, and follow-up steps. An agent has all the information needed to select and invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already fully documents both parameters with examples and uppercase requirements. The description's 'Required parameters' section and example queries reinforce this but add little new meaning beyond the schema. It provides contextual usage examples, but the baseline of 3 applies because the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get detailed schema information for a specific table or view' with a specific verb and resource. It distinguishes itself from sibling tools like search_tables (which finds table names) and execute_query (which runs queries) by specifying that this tool retrieves schema details, and provides example queries that make the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The tool explicitly lists 'Use this tool when:' scenarios, 'Best practices' (including 'Use search_tables() first if you don't know the exact table name'), and 'Next steps' (suggesting execute_query()). This gives clear when-to-use guidance and names alternative tools, making it easy for an agent to decide between this and related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses sorting order ('Sorted by most recent first'), statuses included, and detailed response fields. It also mentions the API endpoint. However, it does not mention potential limits, pagination, or error behavior, which would be useful for full transparency, but the disclosure is still strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with clear headings, bullets, and sections. It is front-loaded with the core purpose and then provides examples and use cases. Some redundancy exists between 'What you'll get' and 'Response includes', but overall it is scannable and every section contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description compensates by thoroughly listing every response field with descriptions. It also provides a workflow example, API endpoint, and use cases. For a tool with only two simple parameters, this is comprehensively sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each parameter already has an informative description including examples and casing requirements. The tool description repeats these examples and adds query examples, but does not introduce new semantic meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Get the execution history for a specific task chain or object in SAP Datasphere.' It clearly differentiates from siblings like get_task_status (status) and get_task_log (log details) by focusing on historical runs. The 'Use this tool when' list further reinforces its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Use this tool when' section lists six concrete use cases. The workflow example demonstrates how to chain get_task_history with get_task_log, indicating when to use the alternative. Example queries provide practical context for invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the underlying API (GET), explains the four detail_level outputs, lists response fields (logId, status, messages, children), and enumerates possible status values. This is exceptionally transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections and bullet points, but it is quite verbose for a simple read tool. There is redundancy between 'What you'll get' and 'Optional parameters' both explaining detail_level, and the 'Use cases' section largely repeats the 'Use this tool when' list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description compensates thoroughly by detailing response contents, status values, example queries, and use cases. It gives an AI agent everything needed to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema documentation covers all 3 parameters with descriptions, so the baseline is 3. The description adds extra value by explaining where log_id comes from, providing example space_id values, and elaborating on the detail_level enum beyond the schema's bare enumeration.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' and identifies a precise resource: 'detailed information about a specific task execution in SAP Datasphere'. It clearly distinguishes this from sibling tools like get_task_status and get_task_history by focusing on a single log and referencing run_task_chain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit 'Use this tool when' scenarios (checking status, investigating failures, viewing logs, monitoring progress). It also indicates log_id provenance from run_task_chain or get_task_history. However, it lacks explicit when-not-to-use guidance or named alternatives like get_task_status.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses return contents (task IDs, status, timestamps, duration, records), filtering options, and task types. It doesn't explicitly state it's read-only, but the verb 'get' and context make that clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections and bullets, but a bit verbose. Every section contributes useful information, though the 'Task types' list is somewhat redundant with the overall purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and only two optional parameters, the description is remarkably complete. It covers when to use, what to expect, filtering behavior, example queries, and return fields, leaving little ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining the no-parameter behavior, how each filter works, and providing concrete example values for each parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves status and execution details for data integration/ETL tasks. It distinguishes itself from siblings like get_task_history and get_task_log by focusing on current status and run details, supported by explicit examples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear 'Use this tool when' scenarios and example queries. It gives strong contextual guidance but does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It describes what is retrieved but does not explicitly state safety traits like read-only behavior, permission requirements, rate limits, or any side effects. The verb 'Retrieve' implies a read operation, but the description adds no deeper behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single well-structured sentence that front-loads the primary purpose, then enumerates key fields and ends with a usage note. Every phrase earns its place, with no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless read tool with no output schema, the description is quite complete: it lists the returned data types (tenant ID, region, version, etc.) and the use case. It does not mention error cases, authentication needs, or response format, but the level of detail is adequate for a simple retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is empty (0 parameters), so the baseline is 4. The description correctly implies that no parameters are needed, and there is nothing more to explain about parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves SAP Datasphere tenant configuration and system information, listing specific fields. It uses a specific verb ('Retrieve') and resource ('tenant configuration'), but does not explicitly distinguish from sibling tools like get_space_info or get_current_user, though the tenant-level scope is implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use this for system administration and capacity planning,' providing clear context for when to use it. However, it does not mention when not to use it or name alternative tools, so it lacks exclusions/alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full transparency burden. It correctly frames the operation as a read-only listing and explicitly states what is returned, which is the most important behavioral trait. It doesn't mention auth or side effects, but for a list operation this is reasonably sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core verb and object, and every sentence adds useful information about purpose, scope, or return value. There is no wasted verbiage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a paginated list tool with no output schema, the description adequately covers what the tool does, its scope, and what it returns. It doesn't need to repeat schema details, and the overall context is sufficient for an agent to select it appropriately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers all four parameters with descriptions, examples, and defaults, so the description adds no additional parameter semantics. This matches the baseline score of 3 when schema coverage is high.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('List') and a specific resource ('analytical datasets within a specific asset'), clearly distinguishing this discovery tool from query-oriented or metadata-only siblings. It also names the expected return content (entity sets, names, types, URLs), making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly frames when to use the tool: to discover analytical datasets/models that can later be queried for business intelligence. It does not explicitly name alternative tools or exclusion criteria, but the 'can be queried' phrasing implies this is the discovery step, so the usage context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosure. It transparently describes the return fields (IDs, names, types, spaces, URLs, timestamps), pagination parameters with defaults and limits, and even includes the underlying Catalog API endpoint. It implies read-only behavior through 'browse' and 'consumption URLs,' though it does not explicitly state that it is a read-only operation or discuss rate limits or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: purpose, when-to-use, expected output, parameters, examples, filters, asset types, and a note. The opening sentence states the core function immediately. While the description is long, every section provides actionable details and no superfluous content. It earns a 4 rather than 5 due to its length; a more compact version could retain the same value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 optional parameters, no output schema, no annotations), the description is exceptionally complete. It explains what results look like, provides usage guidelines, gives numerous examples, details common filters, and even names the underlying API. It fully equips an agent to know when and how to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents all 5 parameters with 100% coverage, so the baseline is 3. The description adds value by providing concrete examples for filter_expression (e.g., spaceId eq 'SAP_CONTENT'), showing typical select_fields usage, and giving common filter combinations. It also explains asset types that appear in results, which enriches the parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear, specific statement: 'Browse all data assets across all SAP Datasphere spaces.' This distinguishes it from siblings like get_space_assets (specific space) or find_assets_by_column (column-specific search). The 'Use this tool when' section further reinforces the tool's role as a system-wide catalog browser.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit 'Use this tool when' list with concrete scenarios like building a complete data catalog or discovering assets across all spaces. However, it does not name alternative tools for exclusion, such as 'use search_catalog for targeted text search' or 'use get_space_assets for a single space.' This is clear context but lacks explicit when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses return fields (IDs, names, types, status, host, timestamp) and lists supported connection types. It does not explicitly state the operation is read-only, nor does it mention permissions or error behavior, but the 'List' verb and status focus imply a non-mutating operation. This is a solid but not exhaustive disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a clear one-sentence summary, then organized into scannable sections with bullets. Every section—supported types, example queries, use cases—provides distinct value. There is no fluff or repetition; the length is justified by the rich context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter, no annotations, and no output schema, the description is remarkably complete. It explains what the user will get in terms of return content, lists valid connection types, and gives concrete usage examples. Nothing critical is missing for the agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the single optional parameter with examples, giving 100% coverage. The description adds value by enumerating possible connection types (SAP_ERP, SALESFORCE, etc.), which is not in the schema. This goes beyond the baseline, though the core semantics are already clear from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb 'List' and a well-defined resource: 'all external data source connections and their current status.' This clearly distinguishes it from sibling tools like test_connection (which tests) and get_task_history (which shows task history). The purpose is unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit 'Use this tool when' section with concrete examples like 'What data sources are connected?' and 'Checking connection health.' It also lists example queries and use cases. However, it does not include explicit when-not-to-use guidance or name alternative tools, so it stops short of a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains the output structure ('What you'll get') and access types, giving good insight into behavior. However, it does not explicitly state that the operation is read-only or mention side effects of the optional output_file parameter, so it falls short of perfect transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear headings, bullet points, and examples. It front-loads the primary purpose and provides necessary details in an organized manner without unnecessary verbosity. Every section (usage, output, required param, examples, access types) contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description compensates by detailing the expected return values (user IDs, status, permissions, etc.). It also includes example queries and a CLI reference, making it comprehensive for a list operation. The optional output_file is covered by the input schema, so the description remains complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description repeats the space_id parameter with uppercase examples, adding minimal value beyond the schema. The output_file parameter is not mentioned in the description at all, so the description does not significantly enhance parameter understanding beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'List all database users in a specific SAP Datasphere space.' It uses a specific verb (list) with a resource (database users) and scope (space), and distinguishes itself from sibling tools like create/update/delete_database_user.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use this tool when' section explicitly lists scenarios such as auditing user access and checking who has database access to a space. It also advises using it before creating a new user to avoid duplicates, providing clear context for when to use this tool over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, but it only says 'Returns OData entity sets' without stating that the operation is read-only, requires specific permissions, or has side effects. It does not disclose pagination behavior or other limitations beyond the schema's top parameter, leaving significant ambiguity about execution behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main verb and resource, and contains no redundant wording. It efficiently communicates purpose and return type.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool, the description covers the core action and return type, but without annotations or an output schema it leaves gaps: what exactly an 'OData entity set' contains is unspecified, and pagination is only hinted at via the top parameter. It is adequate but not rich.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so space_id, asset_id, and top are already fully documented with examples and defaults. The description adds no additional parameter-specific meaning, only a general reference to 'a specific SAP Datasphere asset' that loosely maps to the required parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'List all available relational entities (tables/views) within a specific SAP Datasphere asset.' It also clarifies the return type ('Returns OData entity sets') and distinguishes the tool from query or metadata tools by focusing on enumeration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'within a specific SAP Datasphere asset for row-level data access and ETL operations' gives context on when the tool is useful, but it does not explicitly contrast with sibling tools like query_relational_entity or get_relational_entity_metadata. Usage guidance remains implicit rather than direct.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full transparency burden. It discloses the repository read path (not Catalog API), visibility of objects with consumption.external false, CLI installation requirement, and per-type CLI call cost. It doesn't mention return format, but the read-only nature and key operational traits are well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the core purpose, then usage, prerequisites, and cost. No redundancy; each sentence contributes unique information relevant to tool selection and invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with no annotations and no output schema, the description covers all essential decision-making context: purpose, when to use vs. alternatives, prerequisites, and cost behavior. Parameter details are left to the schema, which is appropriate given 100% schema coverage. This is a complete, practical description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds valuable context for object_types by explaining each type costs a CLI call, reinforcing the schema's advice to narrow types. It also links technical_names to existence checking, which is already in schema but reinforced. This extra practical guidance justifies a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists design-time objects in a space via the Datasphere CLI repository, explicitly contrasting with Catalog API-based siblings. It names specific alternatives (search_catalog, get_space_assets, smart_query) and distinguishes their scope, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: use when an object is expected but missing from catalog-based tools, and for true inventory of a space. It also notes prerequisites (CLI installed and logged in) and performance advice (keep object_types narrow), giving comprehensive usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description carries the full burden. It discloses what the tool returns (space IDs, names, status, counts, owner with include_details=True) and implies a read-only operation via 'list.' However, it does not explicitly state permissions, pagination, or potential errors, which would be even more transparent. The default behavior and detail flag are explained, earning a 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections and is front-loaded with the main purpose. Some content, like example queries, is slightly redundant but still useful for intent recognition. It is not overly verbose, so 4 is appropriate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with one optional parameter and no output schema, the description thoroughly covers use cases, expected outputs, parameter semantics, and next steps. It is fully complete for an agent to understand when and how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents include_details well. The description adds minor context by mentioning 'quick space listing' vs. detailed information, but largely duplicates the schema's parameter description. Thus it meets the baseline without significant added meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists all SAP Datasphere spaces with their status and metadata. It distinguishes itself from siblings by mentioning it's for discovering spaces, while get_space_info is for exploring a specific space and search_tables is for finding tables. This provides a specific verb-resource pair with scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'Use this tool when' bullets, example queries, and next steps that point to alternatives like get_space_info and search_tables. This constitutes clear usage context and alternative guidance, satisfying the highest bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden for behavioral disclosure. It explains query capabilities but does not mention whether the operation is read-only, potential side effects, authentication requirements, rate limits, or performance implications. The read-only nature of a query is assumed but not stated, and there is no disclosure of limitations or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences: the first states the core purpose, the second lists supported OData syntax, and the third mentions typical use cases. Every sentence contributes information without redundancy or fluff, and it is well-structured with the most critical information front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's main function and query syntax, but lacks key contextual details: there is no output schema, and the description does not specify the response format or structure of returned data. It also does not explain the relationship between space_id, asset_id, and entity_set, which are required parameters. For a tool with 10 parameters and no output schema, this leaves some gaps for an agent trying to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and each parameter has a detailed description. The description adds semantic value by mapping parameters to OData query concepts ($select, $filter, $orderby, $top/$skip, $apply), which helps an agent understand how to combine parameters. While the schema already includes examples, the description provides a cohesive syntax overview that goes beyond individual parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it executes OData queries on analytical models to retrieve aggregated data with dimensions and measures. The verb+resource combination ('Execute OData queries on analytical models') distinguishes it from relational query tools like query_relational_entity and generic tools like execute_query. Listing supported OData syntax reinforces the specific purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by mentioning business intelligence, reporting, and data analysis, but it does not explicitly state when to use this tool versus alternatives (e.g., query_relational_entity for relational data or execute_query for SQL). No exclusions or alternative tool references are provided, so guidance is implied rather than direct.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden for behavioral disclosure. It adds useful context like support for large batch processing (up to 50,000 records), filtering, column selection, and pagination, but does not mention return format, error handling, or whether it is strictly read-only. Since it is a read-oriented query tool, the information provided is somewhat adequate but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: three sentences, front-loaded with the core purpose, and includes only relevant details like limits and a prerequisite. Every sentence contributes value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters and no output schema, the description covers the core purpose, capabilities, and batch limit, but omits return format and error semantics. The prerequisite guidance is helpful, but the absence of output schema information creates a noticeable gap for an agent predicting results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description mentions capabilities like filtering, column selection, and pagination, which map to existing parameters (filter, select, top/skip), but it does not add new semantic meaning beyond the schema. The reference to list_relational_entities is also already embedded in the entity_name parameter description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Execute[s] OData queries on relational entities' for 'ETL data extraction', a specific verb and resource. It distinguishes itself from sibling tools like query_analytical_data by explicitly focusing on relational entities and OData, and by mentioning the prerequisite discovery tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool ('data warehouse loading and analytics pipelines') and explicitly instructs to 'Use list_relational_entities to discover available entity names first', which is a helpful prerequisite. It does not explicitly state when not to use it or name alternative tools to avoid, but the relational/analytical distinction is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It does an excellent job: 'Old password is invalidated immediately', 'New password is auto-generated securely', 'User must change password on next login', 'Action is logged for security audit', 'All active sessions are terminated', and the high-risk warning. This far exceeds typical MCP descriptions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with headings and bullet points, making it scannable. It is longer than average, but this is justified for a high-risk mutation tool. There is minor redundancy (e.g., security reminders in both 'Security considerations' and 'Best practices'), but every section serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema and no annotations, the description covers operational context, security implications, example queries, CLI mapping, and best practices. It is complete enough for an agent to confidently invoke the tool and handle the response correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the input schema already describes each parameter. The description adds contextual meaning by listing 'Required parameters' and explaining their purpose in the workflow, plus recommending 'output_file' to save credentials. This adds value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear explanation: 'Reset the password for an existing database user in SAP Datasphere.' This uses specific verb+resource language and distinguishes the tool from sibling tools like create_database_user or update_database_user by focusing specifically on password reset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists use cases: 'Use this tool when: User requests "Reset password for database user JEFF" / Password forgotten or compromised / Regular password rotation policy / Account locked due to failed login attempts.' It does not explicitly mention when not to use it or alternative tools, but the examples and best practices provide clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, but the description fully discloses asynchronous behavior, immediate return of a logId, ordered child task execution, permission requirements, and the ability to investigate failures. This goes beyond basic expectations for a run-triggering tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Although the description is long, it is meticulously structured with labeled sections: when to use, what happens, required parameters, output, examples, and workflow. Every sentence provides useful information, making it efficient despite its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has async behavior, a logId output, and related sibling tools. The description covers initiation, what to expect, how to track via get_task_log, how to view history via get_task_history, and even the underlying API endpoint. This is complete for a complex trigger tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by providing concrete examples for space_id ('SALES_SPACE') and object_id ('Daily_ETL_Pipeline') plus a workflow example, reinforcing the practical meaning beyond the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Execute a task chain in SAP Datasphere and get a log ID for tracking' with a specific verb and resource. It also differentiates from sibling tools by naming get_task_log for status and get_task_history for history, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit 'Use this tool when' list with concrete trigger phrases, and in 'What you'll get' explicitly directs to get_task_log and get_task_history as follow-up tools. This completely answers when and how to use it versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses advanced syntax (SCOPE, Boolean operators) and supported scopes, which is useful. However, it doesn't explicitly state read-only behavior, result format, or pagination limitations. The description is adequate but lacks deeper operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each serving a distinct purpose: stating the tool's scope, listing supported item types, and providing usage syntax. It is front-loaded with the core purpose and contains no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description doesn't explain what the tool returns (e.g., result list format, metadata). It also omits information about result ordering or grouping. The schema covers parameters well, but the lack of return value disclosure leaves a gap for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds a bit of context about query syntax (SCOPE, Boolean operators), but this is also partly in the schema. It doesn't further elaborate on parameters like facets or include_why_found beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a 'Universal search across all catalog items' and enumerates supported item types (KPIs, assets, spaces, models, views, tables). This distinguishes it from sibling tools like search_tables (table-specific) and list_catalog_assets (listing, not searching).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description conveys broad applicability ('Universal search') and provides explicit syntax examples (SCOPE prefix, Boolean operators). While it doesn't explicitly contrast with alternatives like search_tables, the scope is clear enough for an agent to choose it for cross-type searches. No when-not-to-use guidance is given, but the use case is well implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully covers behavioral traits: it searches both names and descriptions, uses case-insensitive matching, supports partial matches, returns results from all spaces or a specific space when filtered, and includes table metadata (type, columns, row counts). This gives the agent a strong understanding of the tool's runtime behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear headers for use cases, behavior, tips, examples, and next steps. It is longer than strictly necessary, but each section serves a distinct purpose and the front-loaded summary makes the core meaning immediately clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a simple 2-parameter search tool with no output schema, the description is comprehensive: it explains what the tool does, when to use it, how search works, provides practical tips, example queries, and next steps. It leaves little ambiguity for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% parameter descriptions for space_id and search_term with examples. The description adds extra semantic value by explaining search behavior (case-insensitive, partial matches) and offering search tips like 'Partial matches work: cust finds CUSTOMER_DATA.' This goes beyond the schema but is not essential given the schema's completeness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action and target: 'Search for tables and views across all Datasphere spaces by name or description.' This clearly defines the tool's scope and differentiates it from siblings like get_table_schema (single table) or list_catalog_assets. The example queries reinforce the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

A dedicated 'Use this tool when' section lists four concrete scenarios, such as 'User asks Find tables with customer data' and 'Searching across multiple spaces.' It provides clear context for when to use the tool, though it does not explicitly mention when not to use it or name alternative tools for different search types.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden and meets it exceptionally. It discloses automatic routing, fallback behavior, response contents (method used, execution time, routing logs), error handling, and performance characteristics. This goes beyond a simple 'executes queries' statement and provides rich behavioral context for an AI agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections, emojis, and bullet points, but it is overly verbose and includes redundant content. For instance, the advantages of smart_query are repeated in both the 'Why use' list and the later 'When to use individual tools' section, and the final note restates the same message. While front-loaded, it would benefit from trimming to make every sentence earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the absence of annotations, and the lack of an output schema, the description is remarkably complete. It covers query modes, supported query patterns, response fields, error handling, performance expectations, and when to use alternatives. An agent would have sufficient context to select and invoke the tool correctly and to interpret its output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds meaningful context beyond the schema: it explains each parameter in a dedicated 'Parameters' section with added semantics like mode examples, default behavior of fallback, and the purpose of include_metadata. This enriches the bare schema definitions and provides practical usage guidance. A score of 4 reflects this added value while acknowledging the schema already covers the basics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a specific verb+resource: 'Intelligent query router that automatically selects the best execution method for your query.' It clearly identifies what the tool does and differentiates itself from sibling query tools by positioning as a composite router with fallback logic. The scope is explicit and not a tautology or vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'Use this tool when' and 'When to use individual tools instead' sections, naming exact alternatives like query_relational_entity, query_analytical_data, and execute_query. This gives clear guidance on when to choose smart_query versus alternatives, satisfying all rubric criteria for usage guidelines.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It clearly states the tool tests the connection and checks OAuth status, implying a non-mutating diagnostic operation. It does not describe return values or failure behavior, but for a simple connectivity check this is largely sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and front-loads the main action. The second sentence is slightly redundant with the first ('Use this tool to check...' restates 'Test the connection'), but the overall structure is clear and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema health check, the description provides sufficient context to understand the tool's purpose and when to use it. It lacks explicit return value details, but the simple nature of the operation makes this less critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the baseline is 4. The schema already has an empty properties object, and the description adds no parameter-specific detail because none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Test the connection to SAP Datasphere', providing a specific verb ('Test') and resource ('connection'). It also adds 'verify OAuth authentication status', making the scope precise and distinguishing it from sibling tools like list_connections or datasphere_cli_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use this tool to check if the MCP server can successfully connect to SAP Datasphere', giving clear guidance on when to use it. However, it does not mention alternatives or exclusions, so it falls just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.