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

Discloses the two-phase async behavior (returns 'pending' with the URL, requires a second call to collect the outcome), explains why it outlasts MCP client timeouts, and notes the side effect of storing a refresh token. This goes well beyond the annotations' bare mutation hints.

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?

A dense four-sentence description with no filler. Purpose, trigger condition, async timeout behavior, and the noBrowser fallback each earn their place without excessive 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?

For a tool with asynchronous side effects and a two-call workflow, the description covers the full invocation contract: when to use, precondition, pending response, repeat-call semantics, and headless fallback. The output schema handles return-value details.

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 already documents all 4 parameters (100% coverage), but the description adds genuine context: ties waitSeconds to the MCP 60s call limit, explains noBrowser for headless machines, and links destination to the serviceKeyPath requirement. This is additive, not redundant.

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?

States a specific verb+resource: opens a browser for the one-time SAP BTP login of a destination and stores the refresh token it returns. It clearly distinguishes itself from sibling list/get/execute tools by focus on authentication and token renewal.

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 says 'Use it when a destination fails with an expired or missing refresh token' and adds a precondition (the destination must carry a serviceKeyPath). It stops short of naming when-not-to-use or alternative sibling tools, so it loses a point for not having 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering basic safety traits. The description adds useful specifics: it creates a manifest-based card with a preview index.html, and fails if the target folder exists, which clarifies the non-overwriting behavior. This goes beyond the annotations and gives the agent clear expectations about 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 a single, information-dense sentence. It front-loads the primary action and resource, lists all valid card types in a compact enumeration, and includes the critical failure condition. Every element 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 description covers the core creation behavior, the supported types, the preview file, and the failure condition. With an output schema present and full parameter coverage in the schema, the description is sufficient for an agent to understand what the tool does and what to expect. It might benefit from mentioning any environment prerequisites (e.g., having a valid session), but given the available structured data, this is a minor gap.

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 parameters are documented in the schema. The description does not add any parameter-specific details beyond what the schema provides; it merely lists card types that are already an enum. With full schema coverage, the baseline of 3 is appropriate, as the description does not need to compensate for missing 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 creates a manifest-based UI Integration Card, enumerates the supported card types, and notes the preview index.html and failure condition. This differentiates it from sibling tools like create_ui5_app or generate_fiori_app_odata, which target different artifacts. The verb 'creates' with a specific resource and explicit scoping makes 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 description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It implies usage for creating Integration Cards, but there is no guidance on when choose this over other generation tools. The failure condition 'Fails if the target folder already exists' provides a practical constraint but does not clarify the appropriate context relative to siblings.

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 provide no hints (all false), so the description carries the burden. It discloses a key behavioral trait: 'Fails if the target folder already exists.' It also details the generated files, giving a clear picture of side effects. However, it does not mention that certain templates require serviceUri or any network/permission dependencies, which is a minor gap but not critical given no annotations.

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 compact sentences: first states purpose and templates with inline explanations, second lists generated files, third states the failure condition. It is front-loaded with the core purpose and template options, and every sentence adds distinct information without redundancy. No filler or unnecessary 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?

The description is complete enough for an agent to decide whether to invoke it: it covers the tool's scope (freestyle apps), lists templates, generated files, and failure behavior. An output schema exists (per signal) for return values. While it does not detail when to choose each template, the schema and inline notes cover parameter needs (e.g., serviceUri's purpose is in schema). Minor gaps remain about prerequisites or environment, but these are not essential for successful 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%, so parameters are documented. The description adds value by explaining template meanings (e.g., 'master-detail' as 'FCL, 2 columns') and noting the failure condition related to targetPath. This enriches the schema's dry descriptions, e.g., clarifying that worklist is OData V2. It does not repeat parameter details but adds contextual 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's purpose: 'Creates a new UI5 freestyle app' and lists specific template types with brief explanations (e.g., 'worklist' as 'searchable table + object page, OData V2'). It also enumerates the generated artifacts (manifest.json, Component.js, etc.), making the scope unambiguous. It distinguishes from sibling generation tools by focusing on freestyle apps, though it does not name alternatives directly.

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 creating freestyle UI5 apps) but does not explicitly state when to use this tool versus siblings like generate_fiori_app_odata or generate_fiori_app_cap. It provides no exclusions or guidance on selecting between templates beyond naming them. The context suggests it is for freestyle apps, but explicit comparisons with alternatives are absent.

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 already disclose the broad safety profile (not read-only, destructive, idempotent). The description adds specific behavioral context: the side effect of writing to localService/metadata.xml or a custom path, automatic auth header handling for BTP destinations, and support for both V2 and V4 services. There is no contradiction with the annotations.

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 earning its place: the first states the core action and output, the second specifies the input modes, and the third describes the return value. It is front-loaded and contains zero filler or 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?

For a tool with 5 optional parameters and no required ones, the description fully explains the three valid invocation patterns, the default and custom output path, and the summary return. An output schema exists, so return details are covered externally. The only minor inconsistency is 'localService/metadata.xml' vs the schema's '<workspace>/metadata.xml', but this does not compromise 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 description coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema by clarifying that serviceUrl, systemName, and destination are alternative input modes, with servicePath relative to the chosen source. This combination guidance is not evident from the individual parameter descriptions and materially helps an agent construct a valid call.

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 states a highly specific verb and resource: 'Downloads the $metadata EDMX document of an OData service (V2 or V4) and saves it as localService/metadata.xml'. This clearly distinguishes it from sibling tools like get_metadata_summary or query_odata_data, which have different outputs and purposes.

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 second sentence explicitly enumerates the three supported invocation modes: direct serviceUrl, systemName plus servicePath, or BTP destination with optional servicePath. It also references sibling tools list_sap_systems and list_btp_destinations as sources for valid values, giving concrete usage guidance. It does not explicitly compare against alternatives like get_metadata_summary, but the in-tool usage context is very 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the mutation profile is established. The description adds some operation-level context, such as deleting pages and updating manifest.json, which is consistent with the annotations. However, it does not disclose additional behavioral details like filesystem effects, reversibility, or required permissions; with the annotation coverage present, a 3 is appropriate.

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?

A single front-loaded sentence begins with the action and target, then uses a colon-separated list of supported operations. There is no filler or redundant restatement of the tool name. The length is proportionate to 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?

With an output schema, strong annotations, and full schema parameter coverage, the description covers the core operation scope. However, it omits workflow guidance: it never explicitly tells the agent to call get_functionality_details first to resolve params, despite that being a clear dependency for correct invocation. The safety profile is covered by annotations, but the execution workflow is under-specified.

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: appPath and functionalityId are documented and the enum values are explicit. The description paraphrases the functionalityId enum values at a high level, adding slight clarification but no major semantic information beyond the schema. The nested params object is intentionally left to get_functionality_details, which the schema references.

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 states a specific verb and resource: 'Executes a modification on an existing SAP Fiori application' and enumerates the exact supported operations. This clearly differentiates it from read-only siblings like get_functionality_details and list_functionality, as well as creation tools like create_ui5_app. The title's 'step 3/3' adds workflow context, but the description is independently clear.

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 clear context by limiting the tool to existing applications and listing the mutation operations it performs, which routes an agent toward this tool for modification tasks. It does not explicitly name alternatives or state when not to use it, but the 'existing app' qualifier and operation list provide enough placement guidance. The prerequisite of fetching parameters via get_functionality_details is only implied by the schema, not the description.

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 provide no safety hints, so the description carries the burden; it discloses that the tool reads the CDS model, resolves to-many associations, and wires the app to the CAP service. This goes beyond a generic 'generate' statement, though it could still be more explicit about overwrite behavior or exactly which files are modified.

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 tight sentences, with the purpose front-loaded and the behavioral detail in the second sentence. There is no filler or repeated information from the schema.

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 10-parameter code-generation tool, the description provides enough context to invoke it correctly: existing CAP project, app/ folder, CDS entity resolution, and service wiring. The presence of an output schema covers return-value details, and the parameter schema covers individual options; a small gap is the lack of explicit idempotency or overwrite behavior.

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 a clear description. The tool description adds contextual information about CDS-model resolution and service wiring, but no parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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 ('generates'), names the target resource (a SAP Fiori elements app inside an existing CAP project's app/ folder), and specifies the source input (an entity of the project's CDS model). The CAP/CDS focus clearly differentiates it from siblings like generate_fiori_app_odata and create_ui5_app.

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 clearly states the tool is for an existing SAP CAP project and that it uses a CDS entity, which gives an agent enough context to know when this tool applies. It does not explicitly name alternatives or state when not to use it, but the provided context is more than merely 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?

Annotations only state non-read-only, non-idempotent, non-destructive. The description adds concrete behavioral detail by listing the files it generates (manifest.json, Component.js, etc.), which tells the agent what side effects to expect. It does not mention overwrite behavior or permissions, but the annotations already cover the safety profile.

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 with the main purpose front-loaded, followed by input guidance and output artifacts. The floorplan enumeration partly duplicates schema enum descriptions, but the summary is compact and each sentence carries meaningful 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?

An output schema exists, so return details need not be explained. The description covers the high-level workflow and references a sibling tool, but it does not clarify parameter groups (e.g., serviceUrl vs systemName vs destination/servicePath) and contains the misleading 'metadataXml content' reference. Given 15 parameters, the description is adequate but leaves some gaps filled only by the schema.

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 useful rule about alternative metadata inputs, but it references 'metadataXml content' which is not a parameter in the schema, misleading the agent. The 'or just entitySet' hint is helpful, but the inaccurate reference outweighs that benefit.

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 states a specific verb ('Generates') and resource ('SAP Fiori elements application') with an explicit scope ('OData V2/V4 service... non-CAP'). It distinguishes from the obvious sibling generate_fiori_app_cap via the parenthetical and clearly enumerates the output artifacts, leaving no ambiguity about what the tool does.

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 signals when to use this tool by the 'non-CAP' qualifier, implying CAP projects belong to generate_fiori_app_cap. It also gives workflow guidance by referencing download_odata_service_metadata as the source for metadataXmlPath and hints at fallback input modes ('or just entitySet'). However, it does not explicitly name alternatives like create_ui5_app or state when to avoid this tool.

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 already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations by revealing the source is official TypeScript type definitions and that results are cached locally after first 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?

Two tight sentences: the first states the function and scope, the second adds source and caching behavior. Every sentence carries useful information with no filler or repetition of schema 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?

For a simple read-only, idempotent tool with two well-documented parameters and an output schema, the description is complete. It covers what is fetched, for which kind of input, from where, and the caching behavior, leaving no critical operational gap.

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 both controlName and ui5Version are already documented in the schema. The description adds a concrete controlName example, but does not provide new semantics beyond what the schema already states, matching the baseline 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 uses a specific verb ('Fetches and formats') and names the exact resource ('UI5 API reference' with properties, aggregations, events, methods). It also gives a concrete example control ('sap.m.Table'), which clearly distinguishes this from sibling tools like search_docs or get_cap_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 clearly implies when to use this tool: when an agent needs the full API reference for a specific UI5 control. It does not explicitly name alternatives or provide exclusion guidance, but the context 'for a control such as' establishes the selection criterion clearly enough.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the key behavioral fact that secrets are redacted, which is critical for an agent. It also clarifies that it returns local or BTP Destination Service sources. There is no contradiction with annotations, and the added context goes beyond the structured fields.

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, front-loaded with the primary purpose and returning fields, followed by the redaction note and a usage hint. Every sentence earns its place with no filler, making it efficient and well-structured.

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 output schema is present (as indicated), the return values are defined. The description enumerates the key fields and the redaction behavior, and provides a usage context. For a single-parameter read-only tool, this is complete; nothing an agent needs to call it correctly 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?

Schema description coverage is 100%, so the schema already documents the 'name' parameter with 'Destination name (see list_btp_destinations)'. The description adds no additional semantic detail about the parameter beyond that. Per the baseline, when schema coverage is high, a 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 'Returns' and the resource 'details of one SAP BTP destination', enumerating specific fields (URL, authentication type, sap-client, custom headers, proxy type). It also distinguishes from the sibling list_btp_destinations by specifying 'one' and mentions query_odata_data, so an agent can differentiate without opening schemas.

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 provides a use case: 'Useful to verify a destination before querying it with query_odata_data.' This implies when to use it. It does not explicitly state when not to use it or name alternatives, but the sibling list_btp_destinations is clearly for listing, and the description's mention of 'one' implies selection. The context is clear enough, though not exhaustive.

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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the scope of returned details but doesn't disclose additional behaviors like error handling, permissions, or rate limits.

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?

A single sentence that is front-loaded with the main purpose and then lists the specific content areas. Every word earns its place; no fluff or repetition.

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 an output schema present and annotations covering the read-only nature, the description is largely sufficient. It could mention behavior when a definition is not found, but that is minor given the other structured signals.

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 fully documents the two parameters. The description adds no additional parameter semantics, keeping it at the baseline 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 uses a specific verb ('Returns') and resource ('full details of one CDS definition') and enumerates the exact contents (elements, associations, actions/functions, projections, includes). This clearly distinguishes it from sibling tools like get_functionality_details or search_model.

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 (e.g., search_model, get_api_reference). The description only states what it does, not the conditions under which an agent should choose it, nor any 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds workflow-relevant behavioral context by disclosing that the tool returns the 'required parameters' needed for a subsequent execution step. This adds value beyond the annotations and does not contradict them.

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?

A single ~14-word sentence that front-loads the verb and resource and carries no filler, redundancy, or repetition of annotation content. 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?

For a simple read-only lookup with two fully documented parameters, an enum, a comprehensive output schema, and a complete annotation set, nothing an agent needs to invoke it correctly is missing. Workflow context is carried by the title ('step 2/3') and schema hint (functionalityId 'from list_functionality').

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 both parameters carry meaningful descriptions; functionalityId even documents that its values come from list_functionality. The tool description itself adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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 'Gets' with a concrete resource ('required parameters and detailed information for a specific functionality'), and the phrase 'before executing it' distinguishes it from the sibling execute_functionality. The title's 'step 2/3' further reinforces its distinct role in a prepare-then-execute workflow.

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 frames usage contextually — 'before executing it' tells the agent this is a prerequisite step to execution, and the title marks it as step 2/3 in a sequence. It doesn't explicitly name alternatives or exclusions, but the workflow position is clear enough that an agent will know to call it between list_functionality and execute_functionality.

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 already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds the useful signal that the content is 'curated' best practices rather than raw search results or exhaustive documentation, but it does not disclose other behavioral traits such as return shape or fallback 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 a single focused sentence that front-loads the action and resource, then immediately lists all supported topics. Every word earns its place, and there is 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?

This is a simple tool with one optional parameter, a full enum in the schema, and an output schema available. The description plus schema fully cover what the agent needs to select and invoke the tool correctly; no critical context 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 schema covers the single parameter fully (topic with enum, default, and description), so the baseline is 3. The description repeats the enum values from the schema without adding additional meaning such as expected formatting, typical use cases, or interaction between topics.

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 states a specific verb ('Returns'), a clear resource (curated UI5 development best practices), and enumerates the exact topics covered (general, views, bindings, routing, i18n, performance, security, testing). This clearly distinguishes it from specialized siblings like get_typescript_conversion_guidelines and get_integration_cards_guidelines, which are narrower in 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 implies usage by listing the topics covered, and the sibling names suggest it for general UI5 guidance rather than specialized conversion or integration-card guidance. However, there is no explicit when-to-use statement, no mention of alternatives, and no exclusions, so the agent must infer the appropriate 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to repeat those. The description adds useful context about what the returned content is (best practices for a specific card type), but does not disclose any additional behavioral traits beyond the annotations.

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, front-loaded sentence with no filler. Every word adds meaning, specifying both the general purpose and the specific technology 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 zero-parameter, read-only tool with an output schema present, the description is fully sufficient. It tells the agent exactly what the tool returns and in what domain, leaving no necessary information 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 already fully covers this dimension. A baseline score of 4 is appropriate; there is no parameter semantic gap for the description to fill.

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 ('Returns') and names an exact resource ('best practices for developing SAP UI Integration Cards'), explicitly tying it to manifest-driven cards for SAP Build Work Zone. This clearly differentiates it from the generic sibling get_guidelines and from create_integration_card.

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: this tool is for obtaining best practices when developing SAP UI Integration Cards. It does not explicitly name alternatives or list exclusions, but the domain is specific enough that an agent can infer when it is appropriate.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the local-file input context and the summary output items, but it does not discuss failure behavior for invalid XML or missing files. This is adequate but not strongly additive beyond the annotations and output schema.

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 one sentence with no filler. It front-loads the key scoping term 'local' and the result list, and every word contributes to understanding what the tool does.

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 single-parameter, read-only tool with a rich output schema and safety annotations, the description is complete enough for correct invocation. It specifies the local file input and summarizes what will be returned; no additional context is needed.

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%: the single parameter metadataXmlPath is already documented as 'Path to the metadata.xml file'. The tool description adds no additional parameter semantics such as absolute/relative path requirements or file format constraints, so the baseline 3 applies.

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 states a specific verb ('parses'), a specific resource ('local EDMX metadata.xml'), and enumerates the returned artifact types (entity sets, entity types, keys, associations, annotation targets). This clearly distinguishes it from sibling tools such as download_odata_service_metadata or query_odata_data.

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 word 'local' establishes the main intended scenario: analyzing a metadata.xml file that already exists locally, which implicitly excludes remote OData service discovery. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusion 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces this by framing the operation as extraction of metadata and configuration, and it adds useful scope details (UI5/CAP project, listed artifact types). No contradiction 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 a single sentence that leads with the core action and resource, then packs a precise enumeration of extracted items. Every part earns its place and no filler is present.

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 an output schema present, a fully documented optional parameter, and strong annotations covering safety, the description plus schema is sufficient for an agent to invoke the tool correctly. No critical usage or behavior information is missing for this read-only info-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% for the only parameter, projectPath, which already documents the default workspace root. The description adds no independent parameter-level detail, but the schema fully carries that burden, so the 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 states a specific verb ('Extracts') and a specific resource ('UI5 or CAP project'), then enumerates the concrete metadata categories returned (app ids, framework version, libraries, views, controllers, models, routing, data sources, package scripts). This is sufficiently precise to distinguish it from most sibling tools.

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 limiting the tool to UI5/CAP projects, but it gives no explicit guidance about when to choose this over alternatives such as get_cap_details, get_metadata_summary, or get_version_info. No exclusions or alternative routing are 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the output content type (step-by-step guideline) but does not disclose any additional behavioral traits such as output format, caching, or rate limits. With annotations carrying the safety burden, this is adequate but not enriching.

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 sentence with no filler or redundant words. Every phrase ('step-by-step', 'UI5 applications and controllers', 'JavaScript to TypeScript') contributes meaning. It is front-loaded with the action verb and resource.

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 read-only tool with an output schema and comprehensive annotations, the description is complete. An agent can safely invoke it with no further clarification about inputs, side effects, or return handling, since the output schema covers the return structure.

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%, so the schema fully documents that no input is required. The description's mention of conversion scope is informational rather than parameter-related, and with no params the baseline of 4 applies.

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 ('Returns'), a concrete resource ('step-by-step guideline'), and an explicit scope ('converting UI5 applications and controllers from JavaScript to TypeScript'), which clearly distinguishes it from siblings like get_guidelines or get_integration_cards_guidelines. An agent can tell exactly what this tool does without opening the 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 clearly implies the usage context (when a UI5 JS→TS conversion guideline is needed) through its explicit scope and title. However, it does not explicitly name alternative tools or provide when-not guidance, such as pointing to generic get_guidelines for other guideline needs. This is a small gap, 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about the specific data sources (CDN sap-ui-version.json and local project configuration), which is useful beyond the annotations. No contradictions found.

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, efficient sentence that front-loads the main purpose and includes the two key sources. There is no extraneous information; every word contributes to understanding the tool's function.

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 simplicity (one optional parameter, read-only, output schema present), the description provides sufficient context about what the tool retrieves. The output schema covers return value structure, and the description clarifies the data sources. The only gap is usage guidance, which is not critical for a simple read 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 parameter projectPath is fully documented in the schema. The description reiterates the local project aspect but does not add significant new meaning beyond the schema's description. The baseline of 3 applies since the schema carries the semantic load.

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 'Retrieves' and the resource 'UI5 framework version information', specifying the two sources (CDN and local project). This distinguishes it from siblings like get_project_info or get_guidelines, which serve different purposes.

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 does not provide any guidance on when to use this tool versus alternatives such as get_project_info or get_guidelines. There is no mention of exclusions, prerequisites, or conditions that would lead an agent to choose this tool over others.

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 already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral detail beyond the annotations: secrets are redacted, destinations can come from local environment variables or the cloud Destination Service, and cloud fetching is conditional on configuration.

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 dense but purposeful sentences. The first sentence states the core behavior and scope, and the second gives actionable follow-up guidance. No filler or redundant restatement of the tool name or schema properties.

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 an output schema present and annotations covering safety and side-effect hints, the description supplies the remaining essential context: the sources of destinations, redaction of secrets, and how the returned names should be used. An agent has enough information to 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 description coverage is 100%, so the includeDestinationService parameter is already documented in the schema, including its default and network implication. The description does not repeat or add meaningful parameter semantics beyond what the schema provides, so the baseline 3 applies.

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 ('Lists') with a clear resource ('SAP BTP destinations') and immediately distinguishes the tool from related OData tools by framing destinations as inputs to query_odata_data and download_odata_service_metadata. It also clarifies the scope: local destinations and optionally cloud destinations.

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 explicit downstream usage: 'Use the returned destination names with query_odata_data and download_odata_service_metadata.' This tells an agent what to do with the results, though it does not explicitly state when not to use this tool versus the sibling get_btp_destination.

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?

The description aligns with the readOnlyHint, idempotentHint, and destructiveHint annotations and adds useful context: it scans a directory, identifies modifiable apps, and returns specific metadata fields. It does not discuss failure or permission behavior, but annotations already carry the safety profile.

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 no filler: the action is front-loaded, the return content is summarized, and the usage instruction is placed at the end. Every sentence 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?

With two fully documented optional parameters, a rich output schema, and safety annotations already present, the description covers what the tool does, what it returns, and when to call it. Nothing essential is missing for an agent to 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?

The input schema already describes both parameters fully, including defaults and bounds, so the description adds no parameter-level value. Baseline 3 is appropriate when schema coverage is 100%.

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 names a specific verb and resource ('Scans a directory for existing SAP Fiori applications'), enumerates the app types covered, and lists the exact return fields. This clearly differentiates it from the many create/generate siblings in the tool 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?

It gives explicit timing guidance ('Call this before modifying an app') and scopes the tool to existing modifiable apps. It does not name sibling alternatives or state when not to use it, but the usage context is clear enough.

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 already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by naming the concrete set of modification functionalities and by framing this as the entry point of a three-step workflow, which helps the agent understand the tool's role and output domain.

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 dense sentences with no filler. The first sentence front-loads the action, target, and result set; the second gives the workflow context in one compact line. Every element 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?

This is a low-complexity, read-only list operation with one documented parameter, a rich set of annotations, and an output schema. The description provides the purpose, the exact list domain, and the follow-up workflow, leaving no crucial gap for an agent to 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 description coverage is 100%, and the single appPath parameter is already fully documented as 'Absolute path to the app folder'. The description adds no parameter-specific meaning, but it reinforces that the tool operates on an existing Fiori app. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 uses a specific verb and resource: 'Gets the list of supported modification functionalities for an existing SAP Fiori application' and enumerates the exact functionality names returned. The title's 'step 1/3' and the workflow line clearly distinguish it from get_functionality_details and execute_functionality.

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 explicit workflow 'list_functionality → get_functionality_details → execute_functionality' tells the agent this is the first step and names the relevant sibling tools. It does not explicitly state when not to use it versus list_fiori_apps or other listing tools, but the sequencing guidance is strong.

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 already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful context by naming the configuration sources (env vars and a JSON file), which goes beyond the structured annotations and helps the agent understand the data origin without contradiction.

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 the core purpose front-loaded and the usage tip immediately after. 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?

For a simple list tool with no parameters and an existing output schema (which presumably describes the returned system names), the description covers purpose, sources, and how to use the result. There is no missing information an agent needs to call 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?

The tool has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameters, and it doesn't. It correctly focuses on the tool's purpose and output usage, making the parameter semantics effectively handled by the absence of 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 lists SAP system connections for OData calls, specifying the exact resource and its purpose. It also names a consuming tool (download_odata_service_metadata), making the tool's role unambiguous and distinguishing it from sibling listing tools like list_btp_destinations.

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 clear usage context: it tells the agent to use the returned system name with download_odata_service_metadata, implying this is a prerequisite step. It does not explicitly state when NOT to use it or list alternatives, so it falls short of a full 5, but the guidance is specific and actionable.

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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds operational context (CSV files, CAP conventions, filter syntax) but does not disclose error behavior, pagination details beyond limits, or what happens if the entity is not found. Given the annotation coverage, this 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 two sentences plus a concise example, with the core purpose front-loaded and no redundant filler. Every sentence earns its place—first establishes the resource, then enumerates capabilities, and finally gives a concrete filter example.

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 an output schema, the description covers the essential query capabilities and the filter syntax. It does not explain the output shape, but the output schema handles that. Missing details like default behavior when projectPath is omitted are present in the schema. Overall, it's complete enough for successful 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 description coverage is 100%, so the schema documents all parameters. The description adds valuable syntax guidance for the filter parameter ('and/or, eq/ne/gt/ge/lt/le, contains' and an example), which is essential for constructing valid queries. It also clarifies that the data follows CAP conventions, which helps set expectations for projectPath and entityName.

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 a specific verb ('Executes a CQN-like query') and a specific resource ('CAP sample data (CSV files in db/data following CAP conventions)'). It lists the supported operations (projection, filter, order, skip/limit) and distinguishes this tool from siblings like query_odata_data by explicitly targeting local CSV mock data.

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 querying CAP sample CSV data, which implies usage for local/testing scenarios. It does not explicitly mention when not to use it (e.g., against OData services) or name alternatives, but the context is strong enough for an agent to infer the primary use case.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral details beyond annotations: supported OData query options ($filter, $top, $skip, etc.), the maxRows safety limit, and the odataVersion fallback (V4 tried first, V2 retried automatically if rejected). These disclose runtime behaviors not captured in annotations. No contradiction with annotations.

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 zero waste. The first sentence states the primary action and output. The second sentence efficiently covers three meaningful pieces of information: targeting modes, supported OData clauses, and the relationship to a sibling tool. All content earns its place; no filler or repetition.

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 the tool's complexity (14 parameters, multiple targeting modes, OData version handling), the description covers the essential decision points: how to choose among destination/system/URL, which query options are supported, the count behavior across versions, and the safety limit. The presence of an output schema covers return format details, so no additional information on that front is needed. Nothing critical for correct invocation 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?

Schema description coverage is 100% – every parameter includes a description in the schema. The tool description does add context about how the three targeting parameters (destination, systemName, serviceUrl) relate and that servicePath is optional for destination/system, but these are minor enhancements over the schema descriptions. Since the schema already documents each parameter thoroughly, the baseline of 3 applies; the description does not add significant semantic value 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 states a clear verb+resource: 'Executes an OData query (V2 or V4) against an entity set and returns the rows as JSON.' It also specifies three targeting modes (destination, system, URL) and explicitly distinguishes itself from the sibling 'query_cap_data' as its remote counterpart, making the purpose unambiguous and well-differentiated.

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 concrete guidance on when to use each targeting mode (BTP destination, configured SAP system, or full serviceUrl) and references sibling tools like list_sap_systems and list_btp_destinations. It also explains the odataVersion fallback behavior. It does not explicitly list when not to use this tool versus query_cap_data, but the 'remote counterpart' phrasing implies a clear context. Minor gap: no explicit exclusions or alternatives besides this reference, so not a perfect 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?

Annotations already establish the operation as read-only and idempotent. The description adds meaningful behavioral context by listing exactly what gets checked, including files-on-disk validation for views and i18n resources. This goes beyond the structured annotations without contradicting them.

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 focused sentence that front-loads the core purpose ('Validates the manifest against UI5 rules') and then efficiently lists the validation categories. Every part adds useful information with no 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?

Given the single parameter, full schema coverage, rich annotations, and presence of an output schema, the description is sufficiently complete. An agent can correctly infer what the tool checks and how to invoke it without missing critical 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?

Schema coverage is 100% and the only parameter, appPath, has a clear schema description. The tool description does not add parameter-level detail beyond the schema, so the 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 validates a UI5 manifest.json and enumerates specific rule categories (sap.app id pattern, dataSources, model references, routing targets, view/i18n files, card structure). This is a specific verb+resource and helps differentiate from generic siblings, though it does not explicitly contrast with run_ui5_linter.

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 the tool is for manifest validation but provides no explicit guidance on when to use it versus alternatives like run_ui5_linter or when not to use it. There are no stated prerequisites, exclusions, or sibling comparisons.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which establishes the safety profile. The description adds useful detail about the analysis scope, such as deprecated APIs and missing controllers, but does not disclose additional behavioral traits like output format or runtime side effects. It does not contradict the annotations.

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 sentence with no filler. It front-loads the main action ('Analyzes JS/XML code') and then provides a concrete list of issue categories that justify 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?

For a two-parameter, read-only linter with an output schema and full parameter documentation, the description provides enough context for invocation. It clearly states what the tool checks, and the schema covers path and file details. It does not offer guidance on choosing this over run_manifest_validation, but that gap is accounted for under usage guidelines.

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 both projectPath and files fully documented in the input schema. The description adds no parameter-specific meaning, such as path conventions or how file filtering behaves, so the schema carries the full burden. 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: 'Analyzes JS/XML code of a UI5 app for common issues.' It enumerates concrete categories like deprecated APIs, removed libraries, missing controllers, and missing i18n keys, which makes it clearly distinguishable from sibling run_manifest_validation and other app-generation tools.

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 intended use is implied by the name and the phrase 'Analyzes JS/XML code of a UI5 app,' but the description never explicitly states when to use this tool versus alternatives such as run_manifest_validation. There is no when-not-to-use guidance or exclusions, so an agent must infer the selection 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?

Annotations already declare read-only, idempotent, non-destructive behaviorikuha. The description adds useful context beyond annotations: the docs are bundled/local and require no network, and searches are meant to ground answers in current best practices. No contradiction with annotations.

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 concise sentences with no redundant words. The front-loaded list of topics gives immediate clarity, followed by a usage directive and a key behavioral constraint. Every sentence 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?

For a search tool with full parameter descriptions, an output schema, and safety annotations, the description covers what the tool searches, when to use it, and important constraints. Nothing critical is missing 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 description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics beyond the schema's own descriptions, though the enumerated corpus topics roughly map to possible scope values. It provides no extra meaning for query, limit, offset, or scope.

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 a specific verb ('Searches') and resource ('bundled documentation corpora'), and enumerates the exact documentation topics covered. This distinguishes it from sibling guideline-getters and code-generation tools without needing to inspect schemas.

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 tells the agent when to use the tool: 'before generating or modifying apps' to ground answers in current best practices. It does not explicitly mention when not to use it or name alternative tools, but the use case is clear and actionable.

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 already declare readOnlyHint and idempotentHint, and the description adds context that the search is fuzzy and operates on a compiled unified model including relationships and annotations. This adds value without contradicting annotations, though no further behavioral details like pagination or auth are disclosed.

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 only two sentences, front-loads the core action and scope, includes a helpful example, and contains no filler or 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?

Given 100% schema coverage, an output schema, and annotations covering read-only/idempotent behavior, the description is complete for a search tool. It explains what is searched, enumerates kinds, and gives an example, so an agent has what it needs to call 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 a concrete example (searchModel(projectPath, 'Books', 'entity')) and enumerates the kind values, giving extra 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?

The description states a specific verb ('Performs fuzzy searches') and a specific resource ('names of definitions from the compiled CDS model'), and it enumerates the definition kinds covered. This clearly distinguishes it from sibling tools like search_docs and query_cap_data by 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 implies usage for searching CDS model definitions and provides an example, but it does not explicitly mention when to use this tool versus alternatives such as search_docs or query_cap_data. No exclusions or when-not-to-use guidance is given.

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