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

With no annotations, the description discloses key behaviors: max 10,000 records, default sample size 1000, works with numeric/string/date columns, automatic type detection, and specific statistics computed (percentiles, IQR). It omits permission requirements or side effects, but for a read-only analysis tool, this 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 well-structured with sections and front-loaded with purpose, but it is verbose and contains some repetition (e.g., 'data quality' appears multiple times). Could be more concise without losing clarity.

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 5 parameters, no output schema, and no annotations, the description covers purpose, parameter details, use cases, performance notes, and expected output statistics. It fully enables an agent to select and invoke the tool correctly without needing external context.

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 baseline is 3. The description adds marginal value by explaining sample_size trade-offs and default values, but these are already in the schema. Additional context like use cases does not directly enhance parameter understanding.

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 advanced statistical analysis of a column's data distribution, including nulls, distinct values, percentiles, and outlier detection. It distinguishes itself from sibling tools like get_table_schema or find_assets_by_column by focusing on distribution analysis rather than metadata or search.

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., data quality checks, profiling, outlier detection) and example queries. However, it does not explicitly state when not to use this tool or contrast with alternatives like querying directly, but the 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, the description carries full burden. It discloses what the tool returns (package IDs, names, categories, provider, versions, sizes, pricing) and lists categories and use cases. Missing details on pagination, rate limits, or result format (e.g., list), but adequate for a browse 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?

Well-structured with sections (when to use, what you get, categories, examples, use cases). Concise enough, though slightly verbose. Information is front-loaded with purpose and usage guidelines.

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 annotations and no output schema, the description provides thorough information about output contents and categories. Missing return type (e.g., list) and error handling, but sufficient for effective use.

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% as descriptions are provided for both parameters. The description adds context beyond schema: category filter and case-insensitive search, with examples. Provides meaningful guidance for parameter 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 that the tool browses and searches available data packages in the SAP Datasphere marketplace, with specific verb 'browse and search' and resource 'data packages'. It distinguishes from siblings as no other sibling tool covers marketplace browsing.

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 when-to-use scenarios are listed (e.g., 'User asks what packages are available'), including example queries and use cases. However, it does not mention when not to use or specific 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 full burden and excels. It discloses that the tool is high-risk, requires user consent, auto-generates a password, and includes security notes (minimum privilege, audit retention). It also hints at the one-time nature of credential display.

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, bullet points, and code blocks. It front-loads the critical risk warning and example usage. Every sentence adds value—no filler. Despite length, it remains scannable and organized.

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 (nested user_definition, high-risk, no output schema), the description is highly complete. It covers required parameters, JSON structure, security implications, and even includes CLI mapping. It leaves no ambiguity for an agent to misuse the 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 has 100% description coverage, but the description adds significant value: it explains the user_definition structure in detail, provides example JSON, clarifies that database_user_id will be prefixed with space name, and recommends the optional output_file for security. This goes well 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 'Create a new database user' and specifies the scope (in a SAP Datasphere space with permissions). It distinguishes from sibling tools like delete_database_user, reset_database_user_password, and update_database_user by focusing on creation. The provided example queries further clarify 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?

The description explicitly lists when to use the tool (e.g., user requests create, setting up user access) and provides example queries. It does not explicitly state when not to use, but the contextual examples implicitly guide against misuse. The high-risk warning also sets expectations.

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 provided, so the description carries the full burden. It thoroughly discloses the tool's high-risk nature, irreversibility, immediate termination of sessions, privilege revocation, and audit logging. The warnings are prominent and accurate.

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 lengthy, the description is well-organized with bold headings, bullet points, and numbered lists. Every section (warnings, when to use, what happens, parameters, safety considerations, before deleting, examples, best practices) serves a clear purpose. No redundant information, and the length is justified by the tool's high risk.

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 all necessary aspects: purpose, usage guidelines, behavioral effects, parameter details, safety precautions, prerequisites, and examples. Despite no output schema, it explains what happens post-deletion (no recovery). It is comprehensive for a destructive tool with high potential impact.

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?

Input schema already describes all 3 parameters, but the description adds valuable context beyond the schema. For example, it specifies the default for 'force' as false, reiterates the uppercase requirement for 'space_id', and uses examples to clarify parameter usage. This enhances understanding beyond the schema alone.

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. It distinguishes from sibling tools like create_database_user, update_database_user, and list_database_users by emphasizing the irreversible deletion and providing alternative actions like deactivation.

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?

Explicitly lists when to use the tool (e.g., user explicitly requests deletion, decommissioning accounts) and when not to (consider deactivating instead). Provides a step-by-step checklist before deletion and best practices, which guides proper usage.

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 discloses behavior: read-only, high-risk requiring user consent, query sanitization, row limits, and development mock data. Error handling details are also included.

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 front-loaded critical warnings. However, it is somewhat lengthy and contains some redundancy (e.g., read-only mentioned multiple times). For a high-risk tool, the length is acceptable.

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 and 3 parameters, the description covers behavior, security, best practices, examples, and error handling exceptionally well. It addresses prerequisites and provides actionable guidance 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%, so baseline is 3. The description adds value with example queries for sql_query, clarifies space_id context (uppercase), and explains limit defaults and range. This goes slightly beyond schema but doesn't introduce new 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 the tool executes read-only SQL queries against SAP Datasphere tables, with specific verb and resource. It distinguishes from sibling tools like analyze_column_distribution and smart_query by emphasizing generic SQL execution and high-risk operations requiring consent.

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?

Explicitly lists scenarios when to use (data retrieval, aggregation, joins) and provides best practices for query construction. Although it doesn't mention alternatives, the guidelines are comprehensive and include error handling 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 fully covers behavior: search across spaces, caching, default limits, case-insensitivity. It also details what the agent will receive in results, ensuring no surprises.

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 bullets, and the first sentence clearly states the purpose. However, some repetition exists (e.g., 'Use cases' overlaps with 'Use this tool when'), making it slightly longer than necessary.

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 4 parameters and no output schema, the description adequately explains what is returned (asset names, types, space IDs, column info, etc.) and includes performance notes. Covers all essential context 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%, so baseline is 3. The description adds usage examples but no new semantic info beyond the schema's parameter descriptions. Minimal added value.

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 'find' and the resource 'assets containing a specific column name across SAP Datasphere spaces.' This is distinct from sibling tools like search_catalog or search_tables, which are broader. No ambiguity.

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 lists specific queries and use cases (data lineage, impact analysis). It provides explicit context but does not mention when not to use or alternatives, so it's slightly below the top tier.

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 full burden for behavioral disclosure. It mentions automatic identification based on SAP annotations but does not state performance implications, error handling, or whether the operation is read-only. The read-only nature is implied but not explicit.

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 with two sentences, front-loading the core purpose. It avoids redundancy but could be slightly more structured, e.g., by listing return fields explicitly. Still, it earns its place with no wasted words.

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 lack of output schema, the description should more fully describe the returned structure (e.g., hierarchy details, field types). It mentions dimensions, measures, hierarchies, and aggregation info but omits details on error conditions or response format, making it incomplete for a metadata 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 coverage is 100% with clear descriptions for all three parameters. The description adds context about the identify_dimensions_measures parameter by linking it to SAP annotations, but this is already in the schema. Baseline score of 3 is appropriate as no significant additional meaning is provided.

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 CSDL metadata for analytical consumption, including dimensions, measures, hierarchies, and aggregation information. It distinguishes from siblings like get_analytical_model and get_relational_metadata by focusing on analytical schema for BI integration.

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?

No guidance is provided on when to use this tool versus alternatives such as get_analytical_model or list_analytical_datasets. The description lacks context about prerequisites or scenarios where this tool is preferred.

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 provided, so description carries full burden. It explains return content and parsing logic (CSDL, annotations, fallback), but omits side effects, authentication requirements, or error handling. 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?

Two sentences, no redundancy. First sentence states purpose and output, second sentence provides technical detail. Every word 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?

Given no output schema and no annotations, the description adequately explains the tool's return content (dimensions, measures, entity sets) and parsing methodology. Lacks output format specifics and error scenarios, but sufficient 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 covers 100% of parameters with descriptions. The description adds technical context about returned metadata and parsing approach but does not elaborate on parameter syntax or constraints beyond the schema. Baseline score 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 clearly states it retrieves the OData service document and metadata for a specific analytical model, listing key components (entity sets, dimensions, measures, query capabilities). It distinguishes itself from siblings by focusing on a single model's metadata with parsing 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?

No guidance on when to use this tool versus alternatives like get_analytical_metadata or list_analytical_datasets. Lacks context on prerequisites, exclusions, or typical use 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 explains the compound key format and underlying API call, but could mention idempotency or error scenarios for completeness.

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 thorough but lengthy with multiple sections. It could be more concise while retaining key 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?

Given no output schema, the description adequately explains what is returned (same as get_asset_details, comprehensive metadata). It provides a complete picture for the tool's usage.

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 parameters are already well-documented. The description adds value by showing the compound key format and providing examples, going 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 it retrieves an asset using a compound key, and explicitly distinguishes it from the sibling tool 'get_asset_details' by noting it offers simplified parameter passing.

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 guidance on when to use (having space_id and asset_id, cross-references) and when to use the alternative 'get_asset_details' (for expand options). Includes example queries.

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 provided, so description carries full burden. It mentions the API endpoint and return data fields, but does not explicitly state read-only nature or discuss side effects, auth needs, or rate limits. Adequate but could be more explicit.

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 sections, bullet lists, and examples. Each section adds value, though the length is slightly above necessary. Front-loaded with 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, but the description comprehensively lists what metadata will be returned, covers params, examples, use cases, and API details. Lacks error conditions but adequate for the tool's complexity.

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 descriptions. The description adds value with examples, format hints (UPPERCASE for space_id), and explanation of optional expand_fields, enhancing beyond 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 verb 'Get' and resource 'comprehensive metadata for a specific SAP Datasphere asset.' It distinguishes from siblings like get_space_assets (list) and get_analytical_model (specific model type).

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:' with examples, 'What you'll get', 'Use cases', and example queries. Does not state when NOT to use or name alternatives explicitly, but 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 fully discloses the tool returns variables (name, type, default, nullable, multi_value), filter annotations, and the column list. It implies a read-only operation and adds context beyond the name, though it could mention prerequisites like asset deployment status.

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: first states core functionality, second adds usage guidance. It is relatively concise and well-structured, though the first sentence is slightly lengthy.

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 2 params, no output schema, and no annotations, the description provides a good overview of inputs and outputs. However, it lacks details on output structure (e.g., array of objects) and possible error conditions, leaving some gaps 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?

Schema coverage is 100% with descriptions for both parameters. The description adds some context by explaining the asset type (view/analytic model), but does not significantly enhance the meaning beyond the schema. Baseline of 3 is appropriate given 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 the tool retrieves input parameters/variables and filter-capability annotations from OData $metadata of a SAP Datasphere asset. It specifies the verb 'Retrieve' and the resource, and distinguishes from siblings by mentioning it is for parameterised assets like views or analytic models.

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 when to use this tool: when the asset is parameterised and variables need to be known before querying. It provides clear context for use but does not mention when not to use it or suggest alternatives among the many sibling 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?

No annotations are provided, so the description carries full burden. It describes the listing behavior but does not explicitly state it is read-only or safe. The name implies a read operation, but additional context on safety or side effects would be beneficial.

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: first states what the tool does, second provides a use case. No unnecessary words, effectively 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?

Given no output schema, the description adequately covers what the tool returns (scopes, granted/available status, descriptions, token scopes). For a simple list tool, this is sufficiently complete.

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 no parameters, so the description cannot add meaning beyond the schema. Baseline for 0 parameters is 4, and the description appropriately focuses on the tool's output.

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, distinguishing between granted and available, and includes descriptions and current token scopes. This is specific and differentiates from siblings which do not deal with OAuth scopes.

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 advises using the tool to understand API access capabilities and troubleshoot permissions. While it doesn't explicitly state when not to use it, the context is clear and no alternatives are needed given the tool's unique purpose.

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 returned fields but does not mention potential errors, authentication requirements beyond being authenticated, or side effects. For a simple read tool, this is acceptable but not exhaustive.

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?

Single, well-structured sentence that front-loads the purpose and details, with no superfluous words. Every part adds 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?

For a parameterless tool with no output schema, the description fully covers what the tool does and what it returns, listing specific fields. No additional information is necessary for an agent 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?

The tool has no parameters (0), so the baseline is 4. The description does not need to add meaning as there are no parameters to document.

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 'Get' and the resource 'authenticated user information', listing specific fields (user ID, email, etc.), and distinguishes itself from sibling tools which focus on different aspects like spaces or tenants.

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 says 'Use this to understand the current user's identity and access rights', providing clear context. It does not explicitly mention when not to use it or alternatives, but given its unique purpose, this is adequate.

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 indicates that the tool returns runtime data but does not disclose whether it is read-only, requires specific permissions, or has any rate limits. It is adequate but minimally transparent beyond stating the output.

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 with two main sentences plus a list of use cases. It front-loads the core purpose and avoids verbosity. The 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?

Given the tool has 6 parameters and no output schema, the description adequately covers the returned data types but lacks details on pagination behavior (beyond schema) and result structure. It is minimally complete for the complexity.

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 all parameters well. The description adds no additional meaning beyond the overall purpose. It does not explain parameter relationships or provide examples, meeting the baseline but not exceeding it.

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 ('List') and resource ('runtime/deployed objects'). It further elaborates on what is returned (deployment status, runtime metrics, execution history, performance statistics) and lists use cases. This distinguishes it from sibling tools like 'get_asset_details' which focus on non-runtime aspects.

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 for monitoring and analysis (monitoring deployed assets, tracking execution status, analyzing runtime performance). However, it does not mention when not to use this tool or suggest alternatives, which slightly reduces 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 burden. It implies read-only behavior by describing retrieval of structure and metadata, but does not disclose authentication needs, rate limits, or error handling (e.g., object not found). Adds some value beyond schema 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?

Two sentences with zero waste. Front-loaded with purpose, followed by detailed examples of what is retrieved for each object type. Efficient and scannable.

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 4 parameters and no output schema. Description explains what it returns for different object types (tables, views, models, data flows). Missing are error cases, performance notes, or output format hints, but overall sufficient for typical use.

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 all parameters. Description provides general context (e.g., example values) but does not add significant additional meaning beyond what the schema 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?

Description clearly states the tool retrieves complete design-time object definitions from SAP Datasphere repository, listing specific object types (tables with columns/keys/indexes, views with SQL, analytical models with dimensions/measures, data flows with transformation steps). It distinguishes from siblings like get_table_schema or get_analytical_model by emphasizing 'complete' and broad coverage.

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?

Description explicitly states use cases: 'understanding object implementation details, extracting schema information, or planning migrations.' It provides clear context but does not mention when not to use or suggest alternatives, which would have made it stronger.

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 alone must convey behavioral traits. It describes a read operation but does not disclose potential side effects, permissions required, rate limits, or how missing identifiers are handled. The lack of detail is insufficient for full 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?

Two sentences that are front-loaded with the tool's purpose and value. Every sentence adds meaning; no redundant or filler content. Ideal length for quick comprehension.

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 lack of an output schema and moderate complexity, the description covers the key return items (columns, types, mappings, ETL capabilities). It could be slightly more explicit about the output format (e.g., JSON), but overall it provides sufficient context for its straightforward metadata retrieval purpose.

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 all three parameters with descriptions (100% coverage). The description adds context about the returned data but does not significantly enhance parameter semantics beyond what the schema already provides. Baseline score 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 clearly states the tool gets detailed metadata for a specific relational entity, listing concrete details like column definitions, data types, SQL type mappings, and ETL extraction capabilities. It distinguishes itself from siblings by emphasizing optimization for data warehouse loading and transformation workflows.

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 mentions it is 'optimized for data warehouse loading and transformation workflows,' which implies a use case but does not explicitly state when to use this tool versus alternatives like 'get_relational_metadata' or 'get_table_schema'. No exclusion or alternative guidance is provided.

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 the return includes schema information and SQL type mapping, but lacks details on side effects, authentication requirements, or rate limits. Adequate but not exhaustive.

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 purpose, and each sentence adds value—no wasted words. Ideal conciseness.

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 3 parameters, no output schema, and presence of sibling tools, the description adequately covers purpose, included schema elements, and SQL type mapping. It lacks details on output structure or potential edge cases, but is mostly 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 coverage is 100%, and the description adds no additional meaning beyond the schema's parameter descriptions (e.g., 'Space identifier (e.g., 'SAP_CONTENT')'). With high coverage, 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 'Retrieve CSDL metadata for relational consumption of a specific asset,' specifying the verb (retrieve) and resource (CSDL metadata for a specific asset). It lists included elements (tables, columns, data types, keys, relationships) and distinguishes 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 indicates usage for 'relational consumption' and 'relational data access and ETL planning,' providing context. However, it does not explicitly state when not to use or offer alternatives, though sibling tool names like get_analytical_metadata serve as implicit contrasts.

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 details what the tool returns: asset names, descriptions, types, exposure status, consumption URLs, timestamps, counts, pagination. It also notes the underlying API call. It does not mention auth requirements or rate limits, but for a read-only listing tool, the transparency is high.

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 fairly long but well-structured into clear sections (use cases, parameters, examples, filters, asset types). Each section adds relevant information without redundancy. It is appropriately sized for the tool's complexity.

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 4 parameters, no output schema, and no annotations, the description is remarkably complete. It covers all parameter usage, provides practical examples, common OData filter patterns, and lists asset types. An agent can fully understand how to invoke the 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 coverage is 100%, so baseline is 3. The description adds significant value with example values ('SAP_CONTENT'), default values for top and skip, common filter examples, and descriptions of asset types. This goes beyond the schema definitions.

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 'List all data assets within a specific SAP Datasphere space' with a specific verb and resource. It distinguishes from siblings like list_catalog_assets and search_catalog by focusing on assets within 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?

The description explicitly lists user queries and scenarios that trigger the tool, such as 'What assets are in the SAP_CONTENT space?' and 'Filtering assets by type within a space.' However, it does not provide explicit when-not-to-use guidance or name alternative 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?

No annotations provided, but description clearly implies a read-only operation ('Get comprehensive information') and lists what will be returned. It adds context like uppercase requirement for space_id. Could be more explicit about being read-only or lack of 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?

Well-structured with sections for usage, output, parameters, examples, and error handling. Every sentence is meaningful and adds value. No unnecessary text.

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 parameter and no output schema, the description covers all necessary aspects: purpose, when to use, parameter details, example queries, and error handling. It is complete.

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 schema already documents the parameter. Description adds value by specifying the uppercase requirement and providing example queries, though it largely restates the schema 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 explicitly states 'Get comprehensive information about a specific SAP Datasphere space' and lists specific outputs (metadata, tables/views, schemas). It clearly distinguishes from siblings like list_spaces by specifying it targets 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?

Provides explicit 'Use this tool when:' section with concrete scenarios (user asks about a space, need to see tables/views, follow-up from list_spaces). Also gives error handling guidance (if space not found, use list_spaces).

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 fully explains the output: column list, data types, primary keys, column descriptions, and table metadata. It doesn't mention permissions or rate limits, but for a read-only schema tool, the behavioral disclosure is sufficient and accurate.

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 (use cases, what you'll get, required parameters, examples, best practices). It is front-loaded with the core purpose. Though somewhat lengthy, every section contributes useful context 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?

Despite lacking an output schema, the description details the output contents and provides a complete usage flow: prerequisites (search_tables), inputs, and next steps (execute_query). It addresses all common use cases and integrates well with sibling tools.

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 largely repeats parameter information (case-sensitivity, uppercase). It adds value through examples (e.g., 'SALES_ANALYTICS') and context, but the baseline for high coverage is 3, and the description doesn't substantially enhance understanding 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 schema information for a table or view. It differentiates from siblings by explicitly mentioning using search_tables() if the table name is unknown, and contrasts with execute_query() for querying. Examples reinforce the specific use case.

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 lists concrete scenarios like checking columns or planning JOINs. Best practices advise using search_tables() first if uncertain, and Next steps suggest execute_query() after schema retrieval. This provides clear guidance on when to use and what alternatives exist.

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 fully discloses the tool's behavior: it returns a sorted array of runs with fields like logId, status, timestamps. It notes the API endpoint and that it's a GET request, indicating a safe read 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 well-organized with bullet points and sections, but is somewhat lengthy. However, every section adds value, and the most important information is 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?

Given no output schema, the description details the response structure, includes example queries and use cases, and provides a workflow example. It lacks mention of pagination or limits, but is otherwise thorough.

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 value with examples, required parameter listing, and context on parameter values (e.g., uppercase space IDs). This goes beyond 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 clearly states the tool fetches execution history for a task chain or object in SAP Datasphere, with a specific verb and resource. It distinguishes from siblings like get_task_log and get_task_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?

The description provides a comprehensive list of when to use the tool, including analyzing runs and finding failures. It gives a workflow example showing integration with get_task_log, but does not explicitly state when not to use it.

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 API endpoint, response structure per detail_level, status values, and example queries. It does not mention rate limits or auth, but for a read operation, the provided information is sufficient and 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 longer but well-structured with clear sections (use cases, parameters, status values, example queries). It front-loads the purpose and organizes information logically. While some redundancy exists (e.g., repeating detail_level options), it remains efficient for the complexity.

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 by detailing the response for each detail_level, status values, and providing example queries. It covers use cases and prerequisites. The tool's complexity (multiple detail options) is addressed adequately.

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 value beyond the schema: it specifies that space_id must be uppercase, log_id is obtained from specific tools, detail_level defaults to 'status', and explains each option. This extra context helps the agent use parameters correctly.

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: 'Get detailed information about a specific task execution'. It uses a specific verb+resource and distinguishes from siblings like get_task_history (which lists logs) and get_task_status (which likely returns simpler status) by specifying that log_id comes from those tools and offering multiple detail levels.

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 when to use the tool with bullet points (e.g., checking status, investigating failures, monitoring progress). It does not directly exclude alternatives, but the use cases are specific enough to guide selection. The note about log_id source (from run_task_chain or get_task_history) provides necessary context.

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 the output structure (task IDs, status, timestamps, etc.), filtering behavior, and task types. However, it does not mention if the tool is read-only, required permissions, or any rate limits, which would add 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 sections (use cases, output fields, filtering options, examples) and uses bullet points for readability. It is comprehensive yet concise, with every section adding 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 that there is no output schema, the description thoroughly explains the expected return values (task IDs, status, timestamps, duration, records processed, space info). It also covers filtering options and provides example queries, making it complete for an agent to use 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 has clear descriptions for both parameters (100% coverage). The description adds context by explaining the effect of no parameters ('Show all tasks') and providing example usage, which goes beyond the schema and helps the agent understand 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 the purpose: 'Get status and execution details of data integration and ETL tasks.' It specifies the verb 'Get' and resource 'task status/execution details', distinguishing it from sibling tools like get_task_history or get_task_log.

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., 'What tasks are running?', 'Monitoring data pipeline execution') and example queries. However, it does not explicitly mention when not to use this tool or compare to alternative tools, which would elevate it to 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 states the tool 'retrieves' information, indicating a read-only operation, and enumerates the returned data. It does not mention authorization requirements or rate limits, but the nature of a read-only configuration tool is adequately 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 concise, consisting of two sentences. The first sentence front-loads the purpose and scope, while the second provides usage guidance. Every sentence adds value with no wasted words.

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 zero parameters, no output schema, and no annotations, the description fully covers the essential information: what the tool does, what data it returns, and when to use it. It leaves no significant gaps 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 tool has no parameters (0 params, baseline 4). The description does not need to add parameter information beyond the schema, which is already 100% coverage. It appropriately describes what the tool returns without referencing 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 tool retrieves 'SAP Datasphere tenant configuration and system information' and lists specific fields like tenant ID, region, version, license type, storage quota/usage, user count, space count, enabled features, and maintenance windows. This verb+resource combination is specific and distinct from sibling tools like get_space_info or get_asset_details, which focus on other scopes.

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 system administration and capacity planning,' providing a clear use case. While it does not exclude alternatives or mention when not to use, the context is sufficient for a simple read-only tool with no side effects.

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 must carry the burden. It states the tool lists and returns data, implying a read-only operation, but does not disclose any behavioral traits such as permission requirements, rate limits, or side effects. For a simple list tool, this is adequate but not fully 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 two sentences, front-loaded with the main purpose, and each sentence adds value: first sentence states the action, second sentence elaborates on return details. No superfluous 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?

Given the lack of output schema, the description partially explains return values (names, types, URLs). It does not cover pagination or error conditions, but for a list tool with well-documented parameters, it is reasonably complete. Could be improved with usage guidance.

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 descriptions for space_id, asset_id, top, and skip. The description adds no additional meaning beyond the schema (e.g., 'within a specific asset' aligns with asset_id). 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 tool lists analytical datasets within a specific asset, distinguishing it from siblings like list_catalog_assets or get_analytical_metadata. The verb 'list' and resource 'analytical datasets' are specific.

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 when you need to discover analytical models for an asset, but it does not explicitly state when to use this tool versus alternatives like list_catalog_assets or query_analytical_data. No when-not-to-use guidance is provided.

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 full burden. It states the tool uses a GET API (read-only) and lists what will be returned. It does not explicitly mention side effects, but 'browse' implies non-destructive. Adds context like asset types and fields returned, but could note limitations or auth needs.

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, bullet points, and examples. It front-loads the main purpose. However, it is somewhat lengthy and repeats asset types (once in a list and again later). Minor redundancy prevents a 5.

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 lacking an output schema, the description compensates by detailing what will be returned (IDs, names, types, URLs, timestamps). It also covers usage scenarios, common filters, and provides example queries, making it complete for an asset listing 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 coverage is 100%, so baseline is 3. The description adds significant value by explaining each parameter with examples, defaults, and common filter expressions, such as default top 50, max 1000, and sample OData filters.

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 'Browse all data assets across all SAP Datasphere spaces.' The verb 'browse/list', resource 'data assets', and scope 'all spaces' are clear. It distinguishes from siblings like 'get_space_assets' (space-specific) and 'search_catalog' (search vs list).

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 such as 'User asks "What assets are available in Datasphere?"' and 'Building a complete data catalog'. It includes example queries and common filters, giving clear context for usage.

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 disclose behavioral traits fully. It states the tool returns connection IDs, names, types, status (CONNECTED/DISCONNECTED/ERROR), host info, and last tested timestamp, establishing it as a read-only listing operation. No destructive behavior is implied. It could mention permissions or caching, but the current level is adequate.

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 sections (when to use, what you get, supported types, examples, use cases). Every section contributes meaningful information. While slightly lengthy, the organization ensures agents can quickly parse key details.

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 lack of an output schema, the description fully explains the return fields (IDs, names, types, status, host, timestamp). The tool has low complexity (one optional parameter), and the description covers all necessary context for correct invocation and interpretation. No gaps remain.

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 the single optional parameter with a description, achieving 100% coverage. The description adds value by listing supported connection types (SAP_ERP, SALESFORCE, etc.) and providing example queries that illustrate parameter usage, such as filtering by 'SAP_ERP' or 'SALESFORCE'. This enriches the schema's 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 defines the tool as listing external data source connections and their status. It distinguishes itself from siblings like 'test_connection' by focusing on listing rather than testing individual connections. The verb 'list' and resource 'connections' are specific and 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 description provides explicit guidance on when to use the tool, including common user queries and troubleshooting scenarios. It implicitly suggests using 'test_connection' for testing individual connections, but lacks an explicit 'when not to use' statement. Nonetheless, the usage scenarios are clear and practical.

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 must carry the full burden. It lists what you get (user IDs, status, etc.) but does not explicitly state read-only nature, authentication requirements, or error handling. Some behavioral context is implied but not confirmed.

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, what you'll get, required parameter, examples). It is front-loaded with the purpose. Slightly verbose with access types and CLI note, but each section adds 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 no output schema, the description explains the return fields (IDs, names, status, etc.). Input schema is fully covered. Missing details like pagination or error cases, but adequate for a list 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 coverage is 100%, but the description adds value by specifying the format for space_id (uppercase) and providing examples. The optional output_file parameter is also explained. This goes 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 'List all database users in a specific SAP Datasphere space' with a specific verb and resource. It distinguishes from sibling tools like create_database_user and 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?

Explicit use cases are provided (e.g., 'User asks What database users exist in SALES space?') along with example queries. While it doesn't explicitly state when not to use, it clearly implies alternatives exist.

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 must carry the full burden. It implies read-only behavior by stating 'list' and 'returns', but does not explicitly confirm non-destructiveness or mention authentication needs, rate limits, or side effects. The disclosure is adequate but not 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?

Two sentences, front-loaded with the core action and resource, then clarifying the return type. Every word serves a purpose with no 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 explains the return (OData entity sets) and connects to broader workflow (ETL operations). Without an output schema, it provides sufficient context for a list operation. Could be more complete by explicitly noting that it is the starting point for subsequent queries.

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%, providing clear descriptions for all three parameters. The description adds contextual purpose but no additional meaning beyond what the schema offers. 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 'relational entities (tables/views) within a specific SAP Datasphere asset'. It distinguishes from siblings by specifying the scope (all entities in an asset) and the purpose (row-level data access and ETL operations), which is distinct from tools like get_relational_entity_metadata or query_relational_entity.

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 for discovery before querying detailed data, but does not explicitly state when not to use it or mention alternative tools. The context is clear but lacks exclusions or guidance on specific scenarios.

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, description carries full burden. It explains what fields are returned (IDs, names, status, counts) and conditionally owner details. It implies read-only behavior but doesn't explicitly state no side effects. Reasonably transparent for a listing 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?

Well-structured with markdown sections, bullet points, and concise sentences. Every section adds value: purpose, usage conditions, output description, example queries, and next steps. 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 one optional parameter and no output schema, the description is comprehensive. It covers what to expect in results and suggests follow-up actions. Sibling tools are not needed for completeness of this 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 coverage is 100%, so baseline is 3. Description adds value by explaining the parameter's effect (include_details adds owner, dates, connection counts) and default behavior. Goes beyond schema to clarify 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?

Description explicitly states 'List all SAP Datasphere spaces with their status and metadata.' It specifies the resource (spaces), action (list), and output elements (status, metadata). It distinguishes from sibling tools like get_space_info by positioning it as a next step.

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:' section with specific scenarios (e.g., user asks about spaces, starting exploration, checking status). Also includes 'Next steps' suggesting get_space_info for further details. However, does not explicitly state when not to use or compare with other list 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 present, the description carries full responsibility for behavioral disclosure. It provides several non-obvious behavioral details: filtering dimensions is cheaper than filtering measures, federated sources support only eq/and/or/(), values must be single-quoted and are case-sensitive, and a value containing a single quote cannot be filtered on. This goes well beyond the schema and informs the agent of important limitations and performance characteristics.

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