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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: the response is release-specific help text, and it is worth reading before guessing. This goes beyond the 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 two concise sentences with the core purpose front-loaded. The 'F1 of ADT' analogy is economical and illustrative, and every sentence adds value without padding.

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

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

With no output schema, no parameter descriptions in the schema, and 0% schema coverage, the description carries a heavy burden. It explains the core purpose and release-specific behavior, but it does not define the required parameters or describe the return value shape, leaving an agent to guess how to construct a valid call.

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 0%, so the description must compensate for the five undocumented parameters. It only implies the notion of 'a position in a source' (line/column/body/objectUri) but never explains individual parameters, their formats, or how they relate. This is a significant gap.

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 identifies the tool as returning ABAP keyword/object documentation for a position in source code, reinforced by the analogy 'the F1 of ADT'. This distinguishes it from sibling tools like findDefinition or codeCompletion by naming the specific resource (documentation/help text) and action (answers with help text).

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 contextual guidance: use it to read release-specific help text before guessing at a statement variant. It does not explicitly name alternatives or state when not to use it, but the use case is clear enough for an agent to select 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?

Annotations already state readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety, and it still increases value by revealing non-obvious behavior: the traversal is breadth-first, budget-limited, and entirely based on ADT static data with no ABAP parsing. It explicitly calls out that dynamic CALL METHOD is invisible, a critical blind spot for the agent. These are behaviors not derivable from the annotations or schema, so the description carries its weight.

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

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

Three dense, purposive sentences: what, how, and limitation. Every phrase earns its place—the impactOf comparison is a second reference, and the dynamic-call caveat is a valuable nuance. There is no filler or repetition of schema content, and the most operative detail comes first.

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 9-parameter tool with no output schema, the description covers the core algorithm, traversal budget, data-source purity, and a key missed edge case. It does not explicitly describe the shape of the returned path or result with no path found, but that is a moderate gap given the tool's complexity and absence of an output schema. Overall the description is complete enough for an agent to call it effectively and interpret the main semantics.

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 9-parameter schema has 100% description coverage, giving the baseline of 3. The description adds multi-dimensional context by explaining the budget-driven traversal and the 'same data as impactOf' relationship, which helps verify parameters like maxDepth and maxNodes. But it doesn't enumerate or simplify per-parameter semantics beyond what the schema already provides, so 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 opens with a precise purpose, 'Whether one object's code reaches another, and through what,' which immediately distinguishes reachability analysis from simpler lookup tools. It further clarifies the method by stating it walks usageReferences backward from 'to' through callers, explicitly contrasting it with impactOf's roll-up approach. This leaves no ambiguity about what the tool does or which sibling it relates to.

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 implicitly tells the agent when to use this tool: when you need a specific 'from' to 'to' path through callers, rather than a rolled-up impact analysis. It references impactOf and usageReferences as the underlying data source, giving context, but it does not explicitly name alternatives or provide explicit when-not conditions. The mechanism is clear enough to infer the right call timing.

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 say readOnlyHint=false and destructiveHint=false, which is minimal. The description goes well beyond by disclosing a critical behavioral quirk: the backend may return success:true even when the object remains inactive, and the tool compensates by returning verified/stillInactive and lowering success to false when anything is left inactive. This is exactly the kind of behavioral context an agent needs and that annotations do not provide.

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 compact and front-loaded with the core action, then explains the verification behavior and the alternative. Every sentence earns its place, though the middle sentence is a bit dense with success:true/verified/stillInactive details. Still, it's appropriately sized for the complexity of the tool.

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

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

For a mutation tool with no output schema, the description covers the key behavioral caveat (false success), the verification mechanism, and the recommended alternative. It doesn't describe the exact return shape beyond the mentioned fields, but the description's job is to add value beyond structured fields, and it does so well. The missing return format is a minor gap given the behavioral warning is the critical 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 the schema already documents all four parameters. The description adds context about objectName and objectUrl (the required ones) by tying them to the activation action, but it doesn't add meaning beyond the schema for mainInclude or preauditRequested. Baseline 3 is appropriate since 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?

The description clearly states the tool activates an ABAP object by name and URL, and explicitly distinguishes it from the sibling activateSafe. It names the specific resource (ABAP object) and the action (activate), and even explains the verification step via the inactive list. This is a specific verb+resource with clear differentiation from siblings.

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 vs alternatives: it warns that the backend can answer success:true for objects that stay inactive (e.g., freshly created class), and recommends activateSafe as the better tool for activating exactly the rows inactiveObjects reports. This is explicit when/when-not guidance with a named alternative.

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?

Beyond the annotations, it discloses critical behavioral traits: the call can report success:true while the object remains inactive, and activating only the class row can leave stale method fragments executing. This is exactly the kind of non-obvious behavior an agent 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?

Three sentences, each carrying distinct value: what the tool does, the safety warning and preferred alternative, and an input constraint. It is front-loaded and dense without fluff.

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

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

Given the tool's complexity and absence of an output schema, the description covers input shape, a critical failure mode, and a safer alternative. It does not explain the full return payload, but mentions success:true, and the rest is sufficiently inferable from the 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%, so the baseline is 3. The description adds meaningful context by telling the agent to use rows from inactiveObjects and that adtcore:parentUri must be non-empty and is left empty for programs. It does not discuss preauditRequested, but the schema already covers that.

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 and resource: 'Activate the objects you name' and defines the expected row shape via inactiveObjects. It distinguishes itself from activateSafe but does not explicitly differentiate from the similarly named sibling activateByName.

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 guidance to prefer activateSafe and explains why, covering the main alternative. It lacks a crisp 'use this when...' statement, but the warning context clearly implies this tool is the less-safe variant.

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 discloses a detailed behavioral contract: it reads inactiveObjects, activates exactly those entries, re-reads and fails if anything is still inactive. This goes far beyond the annotations (readOnlyHint=false, destructiveHint=false) and provides crucial safety information about verification and failure handling.

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 long, front-loads the core purpose, and provides both process details and usage guidance without redundancy. 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?

Given the complexity of the tool and the absence of an output schema, the description adequately explains the verification behavior and usage guidance. It does not explicitly cover error scenarios (e.g., lock requirements), but the key behavioral aspects are well covered, making it sufficient for an agent to call 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?

All 5 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The tool description itself does not add parameter-specific meaning beyond what the schema provides, but it does not need to given full schema 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 states a specific verb ('activate') and resource ('object'), and further clarifies what 'activate' means (class plus its method fragments, sections and test include). It explicitly contrasts itself with activateByName, making its unique purpose unmistakable.

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

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

The description explicitly recommends this tool over activateByName, explaining the risk of the alternative returning success without activating. It also implies when to use it (when you need verified activation) by referencing inactiveObjects.

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 indicate readOnlyHint=false and destructiveHint=false, so the agent knows it is a write operation but not destructive. The description adds that it activates by default and that dryRun can preview the diff without writing, which is useful. However, it does not mention locking, transport implications, or failure handling, so transparency is only partial.

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, concisely leading with the action, then covering defaults and special cases. It avoids repetition of schema details and is efficiently structured, though the last sentence about dryRun could be seen as an afterthought rather than front-loaded. Still, it is well-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 tool's complexity (11 params, no output schema), the description covers key constraints: default visibility, requirement of value for constants, readOnly restriction, and dryRun behavior. It does not mention return values or edge cases, but the schema covers parameter syntax. The essential guidance for correct invocation is present.

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 all 11 parameters have descriptions. The description adds some interaction notes (constant needs value, readOnly only on public, dryRun preview), which slightly enriches parameter understanding. Yet it does not dramatically extend beyond the schema, so a 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 adds an attribute or constant to a class, enumerating the kinds (DATA, CLASS-DATA, CONSTANTS) and that it activates. It is specific enough to distinguish from method-related tools, though it does not explicitly name a sibling alternative. The core purpose is 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 gives parameter-level guidance (e.g., constants need a value, READ-ONLY only for public) but does not state when to prefer this tool over alternatives like addMethod, nor any exclusions. There is no explicit 'use this when...' or 'use that instead' guidance, leaving the agent to infer the tool's role from its name.

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?

Despite annotations being minimal (both false), the description discloses the full write sequence: lock/write/unlock/activate. It also warns about duplicate methods being refused with a line numbercars, and that dryRun shows a diff without writing. This is rich, non-obvious behavior that an agent needs to know before invoking, far beyond what annotations provide.

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 fluff. The core purpose and mechanics are front-loaded, the comparison to patchObjectSource is a one-line distinction, and the duplicate-handling and dryRun behaviors are compactly stated. Every sentence carries load.

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 complex token with 14 parameters nested objects and no output schema, the description covers the crucial operational flow (lock/write/unlock/activate), the refusal on duplicates, the dryRun option, and how the generated code is constructed. The parameter schema fills in the rest, so an agent has everything needed to safely call 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% with descriptions for every parameter, so the baseline is 3 per the rubric. The description adds useful semantics by clarifying that the signature is passed as data and the ABAP is built internally, plus noting indentation is preserved. It explains how parameters like importing/exporting/changing relate to the generated code, which adds 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 opens with a specific verb and resource ('Add a method to a class') and immediately details what that entails (declaration into visibility section, implementation before ENDCLASS). It explicitly differentiates itself from the generic patchObjectSource route, which is a sibling tool, so an agent can select it correctly without 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 description explains that this tool replaces two patchObjectSource edits, making the use case clear. It also mentions the dryRun option to preview without writing Poisson. However, it does not explicitly state when not to use it (e.g., for deleting methods, which has a dedicated sibling deleteMethod), though the comparison to patchObjectSource gives solid 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=true and destructiveHint=false, so the description doesn't need to repeat that. It adds the diagnostic purpose and the fact it's about protocol versions, which is useful. However, it doesn't describe the output format or whether any parameters are needed (though there are none). The description adds context beyond annotations but could be richer.

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 conveys the purpose and usage context without any fluff. It is front-loaded with the main purpose and then clarifies the use case. Every word earns its place.

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

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

Given the tool's simplicity (zero parameters, no output schema, read-only annotations), the description is adequate for an agent to know when to invoke it)Skip. It tells the agent the trigger (unsupported version call) and what it provides (compatibility graph). Could perhaps mention that it requires no input, but that's inferable from 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?

The tool has zero parameters, so the description doesn't need to explain any. The 'Diagnostic' qualifier adds context about what the tool returns (diagnostic info), which is helpful. Since there are no parameters, the description fully covers any semantic need.

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: it provides the ADT compatibility graph of protocol versions for collections. It is specific about the resource (ADT compatibility graph) and the diagnostic context (for a call refused as unsupported version). This distinguishes it from siblings, though it doesn't explicitly name alternatives.

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 specifies when to use this tool: when a call is refused due to an unsupported version. This gives the agent a concrete trigger condition. It does not explicitly mention not using it in other scenarios, but the diagnostic 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with these (a read-only discovery document). It adds a small behavioral hint that this is a lightweight connection-proving call, but does not enrich beyond that; 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 a single, efficient sentence that front-loads the core fact that this is the core discovery document. The trailing clause about healthcheck is slightly redundant but the overall length is appropriate and free of 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 zero-parameter tool with no output schema, the description conveys the resource and its connection-verification purpose, which is adequate. However, it leaves ambiguity about what the agent does with the returned document and how it differs from the adtDiscovery sibling, so completeness is moderate.

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 is empty with 100% coverage trivially satisfied, so the description carries no burden to document parameters. Per the baseline for zero-parameter tools, a 4 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 identifies a specific resource (the ADT discovery document) and notes it's used for connection verification. However, the phrasing 'what healthcheck calls to prove the connection is alive' muddles whether this is a tool for the agent to use directly or an internal mechanism, and it does not differentiate from the closely named sibling adtDiscovery.

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 used for proving a connection is alive, giving some context for when to call it. But it offers no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as adtDiscovery or the healthcheck sibling, so the agent is left to infer the intended invocation scenario.

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 destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it returns the service document with collections, URLs, and object types, which is useful context. However, it doesn't disclose details like whether the response is large, whether it requires authentication, or how the document is structured beyond the basics.

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 waste. The core purpose is front-loaded, and the practical use case ('where the address of an unfamiliar collection comes from') is stated efficiently.

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 discovery tool, the description is largely complete. It explains what the tool returns and why an agent would use it. The only minor gap is not clarifying the relationship to adtCoreDiscovery, but the description is otherwise sufficient 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 tool has zero parameters, so there is no parameter semantics burden on the description. The schema is trivially complete (100% coverage with an empty object), and the description correctly implies no inputs are needed. Baseline 4 is appropriate for a zero-parameter tool.

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 identifies the tool as the ADT service document, explaining that it lists every collection with its URL and object types. This is a specific resource and purpose, though it doesn't explicitly distinguish itself from the sibling adtCoreDiscovery, which likely serves a similar discovery role.

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 the address of an unfamiliar collection, this is where it comes from. However, it doesn't explicitly state when to use this tool versus adtCoreDiscovery or other discovery-related siblings, nor does it mention any alternatives or 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 and destructiveHint=false. The description adds useful context that these definitions are what activation refuses against, but it does not disclose return structure, pagination, or other behavioral traits. 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?

A single well-structured sentence that front-loads the resource and then explains its role in activation. 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 parameter-free read-only tool, the description communicates what the tool returns (CDS annotations and value ranges) and why it matters. It stops short of describing the exact return format or data structure, but this is a minor gap given the tool's simplicity and the absence of an output 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?

The tool has 0 parameters against an empty schema (100% coverage), so the baseline is 4. The description has no parameter details to add, and none are needed.

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

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

The description clearly identifies the resource ('CDS annotations this system defines') and conveys the tool's purpose: returning supported annotation value ranges. It is not a tautology and avoids ambiguity, but it does not explicitly distinguish itself from sibling tools like syntaxCheckCdsUrl or codeCompletion.

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 clause 'what may be written in a DDLS source before an activation refuses it' implies the tool is relevant when authoring or validating DDLS source, giving a clear context of use. However, it does not state when to use this tool versus an alternative, nor does it provide 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 indicate readOnlyHint=false and destructiveHint=false, so the tool is known to mutate but not destroy. The description adds context by explaining the specific effect (moves the finding to another worklist). It does not disclose permission requirements, reversibility, or what happens to the old worklist beyond the move. This is a moderate disclosure beyond 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?

A single sentence that is front-loaded with the core action ('Change who is responsible') followed by a clarifying clause ('moves the finding into another worklist'). Every word earns its place; there is 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 mutation with two parameters and no output schema, the description explains the action and its primary effect. It does not mention the response format or potential errors, but these are less critical for a straightforward reassignment. The description is sufficient for an agent to know what the tool does and what inputs are needed, given the schema already documents parameter meanings.

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 provides descriptions for both parameters: userId (The ID of the user) and itemUri (The URI of the item). The tool description adds meaning by clarifying that itemUri refers to an ATC finding and that changing responsibility implies userId is the new responsible user. This goes beyond the schema's generic labels, enriching 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?

States a specific verb (Change), resource (who is responsible for an ATC finding), and clarifies the effect (moves the finding into another worklist). This clearly distinguishes it from siblings like atcContactUri (likely retrieves contact info) and atcWorklists (lists worklists). The action and outcome are 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 implies usage: when you need to reassign an ATC finding to a different user. However, it provides no explicit when-not-to-use guidance or references to alternative tools. It is not misleading, but the guidance is only implicit and lacks exclusions or sibling differentiation.

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 declare readOnlyHint=true and destructiveHint=false, and the description adds value by explaining the execution flow (variant, worklist, run, readback) and the risk of misuse (500 error). It also describes output ordering ('findings are ordered by priority, 1 being the worst'), which is behavioral context beyond the safety 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 moderately long but every sentence carries necessary information. It front-loads the core purpose, clarifies the internal workflow, and includes a practical warning. No redundancy or filler; it earns its length.

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

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

Given 9 parameters and no output schema, the description covers key aspects: what the tool does, the expected output content, ordering, severity semantics, and a known failure mode. It does not detail exact return structure (no schema exists), but it provides enough for an agent to invoke correctly. The only minor gap is absence of explicit mention of authentication or rate limits, which are not indicated in annotations either.

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 context: explains the variant default ('Defaults to the system check variant from atcCustomizing'), the cap semantics ('maxResults' and 'maxFindings' with counts always for everything found), minPriority severity ordering, and the escape-hatch purpose of objectUrl. This enhances 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?

States a specific verb and resource ('Run the ATC checks') with explicit scope ('over an object or a whole package') and detailed description of the output (findings with priority, check, message, source line). Clearly distinguishes itself from sibling tools by positioning as the whole sequence in one call, not requiring separate steps like variant selection or worklist creation.

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

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

Provides clear context on when to use the tool ('the whole sequence in one call') and warns about a specific pitfall ('getting it wrong is what made a run answer 500 (the run needs a worklist id where the library asks for a variant)'). It implicitly differentiates from component tools but does not explicitly name alternatives or state when not to use, hence not 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?

Beyond the readOnlyHint and destructiveHint annotations, it discloses that the tool reads nothing about the variant and only returns a worklist id. It also surfaces the 500 failure mode. It does not describe the exact response shape, but that is a minor gap for a read-only one-parameter 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?

Three sentences, with the main purpose front-loaded and every subsequent sentence adding useful caveats or routing information. There is 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?

For a simple one-parameter tool with no output schema, the description covers what it returns, why it is needed, and the critical failure mode. It could clarify whether the worklist is newly created or must already exist, but the core calling contract is clear.

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 single 'variant' parameter is already fully documented in the schema with 100% coverage. The description reinforces that it expects a variant name rather than a worklist id, but adds no format or constraint details 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?

States a specific action ('Opens a worklist'), a target resource (ATC check variant worklist), and a return value (its id). It also explicitly contrasts with atcCheck, making the tool's standalone role 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?

Explicitly tells when to use this tool: when you need a worklistId for createAtcRun. It warns that passing the variant name to createAtcRun causes a 500 and names atcCheck as the combined alternative, so an agent can route correctly.

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 annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the tool retrieves the responsible party's contact URI, which is useful context. However, it doesn't disclose behavior on invalid input or what happens when no contact exists, which would be valuable given no 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 a single, focused phrase with no redundant words. It front-loads the key concept (contact URI) and adds the responsibility context. It's efficient and avoids repetition of the parameter details already present in 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 simple one-parameter, read-only accessor, the description is mostly adequate. It explains the conceptual meaning of the result and the parameter is fully documented. However, with no output schema, it would be helpful to at least imply the response format (e.g., a URI string) or note possible empty results, which 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 input schema provides 100% coverage for findingUri with a clear description ('The URI of the ATC finding'). The tool description does not add further semantics about the parameter—it only implies the relationship to the result. Since the schema already handles the parameter, a 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 resource (ATC finding) and the attribute being accessed (contact URI), plus the semantic meaning ('who is responsible for it'). It distinguishes itself from siblings like atcChangeContact which imply a mutation. The only minor weakness is that it's phrased as a noun phrase rather than an explicit verb, but the intent is 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?

No explicit usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it state any exclusions or prerequisites. While it's a simple accessor, the absence of any context about when to invoke it leaves the agent to infer from the name and 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?

Annotations declare readOnlyHint=true and destructiveHint=false, and the description is fully consistent with them. The description adds that it describes 'how ATC is set up', which is useful context but does not provide return format or further behavioral details. Since annotations already cover the safety profile, the description adds only marginal value.

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 redundant words. It immediately states the subject and the key content, making it efficient and easy to parse.

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

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

For a parameterless, read-only query tool with no output schema, the description provides the essential content: check variants and their priorities, and the default behavior of atcCheck. It is sufficient for an agent to understand what the tool returns. It could be more precise about the output format, but given the simplicity, it is reasonably 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 zero parameters, so the baseline is 4. The description does not add parameter-related information, but none is needed since there are no parameters to clarify.

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 resource (ATC configuration) and the specific aspect (check variants and their priorities, what atcCheck runs against by default). It does not use an imperative verb like 'get' or 'retrieve', but the purpose is unambiguous. It hints at differentiation from atcCheck and atcCheckVariant by focusing on system-wide defaults, though it does not explicitly name alternatives.

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?

There is no explicit guidance on when to use this tool versus siblings such as atcCheckVariant or atcCheck. The phrase 'what atcCheck runs against by default' implies a specific use case, but it does not state 'use this when you need the default configuration' or mention alternative tools. Given the large number of ATC-related siblings, this is a significant gap.

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 destructiveHint=false, so the safety profile is covered. The description adds useful context by stating the response is HTML as it comes from the backend and explaining the semantic content of the finding, but it does not disclose error behavior or other edge cases.

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 wasted words. The purpose is front-loaded, and each clause serves a distinct function: clarifying what the documentation contains, where the input comes from, and what the output looks like.

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 one-parameter, read-only tool with no output schema, the description gives the essential workflow: URI origin, the action performed, and the response format. Minor omissions like error handling or URI validation are acceptable given the tool's simplicity.

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 describes docUri fully with 100% coverage, so the baseline is 3. The description repeats that the URI comes from atcWorklists, which reinforces the schema, but it does not add substantive parameter semantics beyond what the schema already provides.

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

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

The description clearly states the operation: it takes a documentation URI and returns the documentation of one ATC finding as HTML. It also distinguishes itself from atcWorklists by explicitly referencing it as the source of the URI, so an agent can tell them apart.

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

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

The phrase 'Takes the documentation URI that atcWorklists reports for a finding' gives clear context for when to use this tool, tying it to a prior workflow step. It does not explicitly discuss alternatives or situations where this tool should not be used, but the workflow implication 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=true and destructiveHint=false, so the safety profile is covered. The description adds semantic context by indicating this is a proposal and not the actual request, which is helpful. It does not disclose error cases, permissions, or response format, but given the lightweight annotations and simple read-only nature, this is acceptable.

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

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

The description is a single, compact sentence that front-loads the core concept and immediately clarifies the tool's purpose. There is no redundant wording 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 single-parameter read-only preview tool with annotations and full schema coverage, the description provides enough context. It could mention what the returned proposal contains or how it relates to atcRequestExemption, but the core usage is understandable and nothing critical is missing for invoking 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 schema has 100% description coverage for markerId with a clear explanation ('The ID of the marker.'), so the schema carries the parameter semantics. The description does not add any meaning about how markerId is used or why it is needed, but it does not need to due to full schema coverage.

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

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

The description names a specific resource (exemption proposal for an ATC finding) and clarifies its role as a pre-request preview. It is not a tautology, but it lacks a clear verb like 'get' or 'preview', so the action is implied rather than stated. It distinguishes itself from a real exemption request by saying 'before requesting it', though it does not explicitly name the sibling.

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

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

The phrase 'before requesting it' gives an implied usage context: call this to preview before submitting an actual exemption request. However, it does not explicitly name the alternative tool (e.g., atcRequestExemption) or state when not to use this tool. The guidance is useful but not explicit.

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 adds behavioral context beyond the annotations: it reveals that the action is asynchronous and routed to an approver, with no immediate grant. This is valuable because readOnlyHint=false and destructiveHint=false alone do not convey that this is a request/approval handoff rather than a direct state change.

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 front-loads the primary action, then immediately clarifies the workflow and the non-granting nature. Every clause earns its place, 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?

For a simple single-parameter tool, purpose and workflow are covered well. However, the nested proposal object is left structurally undefined, and there is no output schema to clarify what the caller should expect after the request is submitted. This leaves an agent needing to guess at the proposal shape despite the 100% schema coverage being only a superficial label.

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 small hint that the proposal must include a reason, but it does not explain the structure of the nested 'proposal' object or how to identify the ATC finding. It provides only marginal 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 uses a specific verb ('Ask') and a clear resource ('ATC finding') with a purpose ('to be exempted') and a key qualifier ('with a reason'). The phrase 'it goes to an approver, it is not granted here' sharply distinguishes it from any approval/granting tool, making its role unmistakable.

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

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

The description clearly indicates this is for requesting an exemption rather than granting one, and the workflow context ('goes to an approver') makes the use case obvious. It does not explicitly name neighboring sibling tools like atcExemptProposal, but its usage context is strong and unambiguous.

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 destructiveHint=false, so the description does not need to restate the safety profile. It adds context that these are the known exemption approvers and that unfiltered searches can be large, but it does not disclose additional response behavior or auth requirements; the annotations carry part of that burden.

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, purpose-first, and contains no schema repetition or filler. The added advisory about using a filter earns its place, making this well-structured and easy to parse.

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 read-only tool with two optional, fully documented parameters and read-only annotations, so the description does not need extensive extra context. The approver-related purpose and the filter advice are enough for an agent to invoke it correctly, although a true output schema is also absent.

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, explaining limit's default/count behavior and filter's case-insensitive substring matching over user id and name. The description adds only a general reason to filter, so it aligns with the baseline rather than meaningfully enriching the 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 first sentence identifies the tool as the users ATC knows for exemption approval, specifically who can be named as an approver. This is a clear resource-and-purpose match, but it does not explicitly differentiate it from siblings such as systemUsers, so it stops short of a 5.

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 a clear use context, exemption approval, and explicitly advises searching with a filter rather than pulling back the whole address book. This is concrete enough for an agent to know when and how to use it, though it does not name alternative tools or exclusion criteria.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by emphasizing the worklist is 'existing' and by contrasting with atcCheck, making clear this tool does not run checks and only returns findings already held by the worklist.

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 short sentences deliver the core purpose and the routing guidance without redundancy. The most important scoping fact, that this is an existing worklist lookup, is front-loaded, and the sibling preference is stated efficiently.

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 read-only retrieval tool, the description covers what it returns, the key identifier concept, and the preferred alternative. Optional parameters are fully documented in the schema, so 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?

Schema description coverage is 100%, so all four parameters are already documented in the input schema. The description only clarifies the core lookup concept ('by id'), which mostly aligns with the schema's own 'ID of the ATC run result' description, adding no substantial new parameter 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 identifies the resource as an existing ATC worklist and says it contains the findings it holds, which is specific enough to understand the tool's function. It lacks an explicit verb like 'retrieves' or 'returns,' so it stops just short of a 5, but it does distinguish itself from atcCheck by naming that sibling.

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 directs the agent to prefer atcCheck, which 'opens a worklist, runs the checks and reports them in one call.' This clearly implies atcWorklists is for retrieving an existing worklist without running checks, giving both an alternative and the condition for choosing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds context about the content returned (services, versions, entities) but does not disclose additional behavioral traits such as potential side effects, auth requirements, or rate limits. Since annotations carry the safety burden, the description's added value is moderate, aligning with the baseline for annotated read-only tools.

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. The core purpose is front-loaded ('What a service binding exposes'), followed by the usage caveat ('read before publishing or unpublishing one'). There is zero fluff or redundancy, and every word contributes to understanding the tool.

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

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

Given the tool's simplicity (2 params, 1 required, no output schema) and the annotations covering safety, the description is largely complete. It states the purpose and the usage context. The only minor gap is the exact structure of the return data, but since there is no output schema and the description hints at the content, it is adequate for an agent to correctly 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 both parameters are already documented in the input schema (index and binding). The description does not add any additional meaning or usage hints for these parameters, and given the baseline of 3 for full schema coverage, no extra points are warranted.

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

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

The description clearly states the tool's function: revealing what a service binding exposes (services, versions, entities). It uses a specific noun ('service binding') and a distinct purpose, differentiating it from sibling tools like publishServiceBinding and unPublishServiceBinding without needing 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?

Explicit usage guidance is provided: 'read before publishing or unpublishing one.' This tells an agent exactly when to invoke this tool (as a prerequisite to mutation) and by implication when not to (when intending to publish/unpublish directly). It also establishes it as a read-only inspection step.

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 goes well beyond the annotations (readOnlyHint=false, destructiveHint=false) by detailing side effects: it executes on the target system as the connected user, rolls back changes unless commit is set, warns that modules with internal commits cannot be rolled back, and states it is a writing tool refused in read-only mode. It also discloses input validation behavior and output structure, providing rich behavioral context 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 lengthy but well-structured, starting with a clear purpose, then mechanics, output details, validation, and finally safety. Every sentence adds useful information for a complex tool with 8 parameters. While it could be trimmed, the density of technical details is appropriate for a low-level function module caller in an ABAP environment.

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 critical aspects an agent needs to invoke the tool correctly: how to specify the module (name), what happens with signature validation, output format (exporting/changing/tables, exceptions, row counts), side effects (rollback, commit, internal commits), and the restriction to read-only mode. Combined with a fully described input schema)Skiping nothing major is missing. The lack of an output schema is compensated by a detailed description of the return value 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?

Schema description coverage is 100%, so the baseline for parameter semantics is 3. However, the description adds meaningful context that goes beyond the schema: it explains the role of commit (default rollback, override to keep changes) and clarifies that values are validated against the signature before sending. While dryRun, maxRows, keepClass, and snippetClass are not elaborated in the description, the schema descriptions for those parameters are already sufficient, so the description still adds value for the core 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 opens with a clear, specific statement: 'Call a function module with values and get what it returned, as data.' It identifies the exact resource (function module) and differentiates from sibling tools like callMethod by naming the resource type. The subsequent details about looking up the function group and generating the call reinforce the purpose.

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

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

The description explains what the tool does but never states when to use it over alternatives. It does not mention any exclusions, prerequisites, or comparisons to sibling tools such as callMethod, runClass, or runSnippet. The only contextual clue is the function module emphasis, which implies a use case but is not explicit.

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 readOnlyHint=false and destructiveHint=false. The description goes much further: it discloses that execution happens as the connected user, that changes are rolled back unless commit is set, and that the tool counts as a writing tool. This is critical behavioral context an agent needs, and 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 well-structured and front-loaded: purpose first, then mechanics, then constraints, then the IMPORTANT caveat. Every sentence adds value—no redundancy or fluff. It is longer than average but justified by the complexity of the operation.

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 what is returned (returning, exporting, changing parameters, and exception text). It covers rollback/commit behavior, static-only limitation, and read-only refusal. The remaining details (maxRows, dryRun, snippetClass) are sufficiently described in the schema, so nothing essential 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 coverage is 100%, so each parameter is already documented. The description adds minimal parameter-specific meaning beyond what the schema provides; the note about 'values' referencing callFunction shapes is helpful but not essential. The baseline of 3 applies because the schema does the heavy lifting.

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

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

The description opens with a specific verb and resource: 'Call a static method of a class with values and get what it returned, as data.' It distinguishes itself from siblings by explicitly noting static-only scope and pointing to runSnippet for instance methods. The mention that the signature is read from class source because classComponents lacks parameters adds useful context and separates it from related 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?

It gives explicit usage guidance: 'Static methods only: an instance method needs a constructor call, and runSnippet is the way to do that.' This names the alternative and the condition that selects it. It also warns that the tool is refused in read-only mode, clarifying when it cannot be used.

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 destructiveHint=false, so the description goes beyond by explaining the nature of the preview: it does not execute the move, and why (no evaluate step, payload must be assembled and cannot be run unverified). This adds context beyond the annotation, making the tool's behavior fully transparent. No 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 structured with a first sentence stating the purpose, and subsequent sentences explaining limitations and next steps. It is front-loaded with the core purpose and uses only three sentences. It is slightly longer than necessary but every sentence adds value, so it earns a 4 rather than 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?

For a preview tool with read-only annotations and no output schema, the description is quite complete. It explains what the preview shows, that it does not execute, and where to perform the actual move. It lacks details about the exact response structure, but that is implied by 'what moving an object... would involve'. Overall, it covers the essential context an agent needs to use the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds a high-level context that the preview includes old and new package and transport, but it does not provide per-parameter details beyond what the schema already states. It does not compensate for any coverage gaps because there are none, so a baseline of 3 is appropriate.

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

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

The description clearly states that the tool provides a preview of what moving an object to another package would involve, including the proposed refactoring, old/new package, and transport. It explicitly distinguishes itself from an actual move by saying 'Preview only' and 'this server does not execute the move', which separates it from sibling tools like renamePreview or extractMethodPreview. The verb 'preview' and resource 'package move' 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 gives explicit when-to-use guidance: to see the refactoring proposal without executing. It also gives when-not-to-use: 'Do the move itself in ADT or SE80 once the preview looks right.' This clearly routes the agent to external tools for the actual move, and explains why the server cannot execute it. This is a strong usage guideline with explicit 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful behavioral context: it reports what would change and whether local changes block the pull. However, it doesn't disclose details like whether it performs a fetch, how it handles authentication, or what the output format looks like. With annotations covering the safety profile, 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?

One sentence, zero waste, and the core purpose is front-loaded. It states the action, the resource, and the two key outputs (what would change, local obstacles) in a compact form.

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 read-only check tool with annotations covering safety and a 100% schema coverage, the description is nearly complete. It tells the agent what the tool does and what it reports. The only minor gap is that it doesn't describe the output structure, but since there is no output schema and the tool is a check/preview, the description's summary of outputs ('what would change' and 'whether anything local stands in the way') is sufficient for an agent 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 description coverage is 100%, so the schema already documents all three parameters (repo, user, password). The description doesn't add parameter-specific meaning beyond the schema, but it does imply that repo is the target and user/password are likely for authentication. Baseline 3 is correct when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: checking an abapGit repository before pulling, specifically what would change and whether local changes stand in the way. It uses a specific verb ('check') and resource ('abapGit repository'), and the pre-pull context distinguishes it from generic repository tools. However, it doesn't explicitly name sibling tools like gitPullRepo or stageRepo, so differentiation is implied rather than explicit.

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 a clear usage context: use this before pulling to preview changes and detect local obstacles. It doesn't explicitly state when not to use it or name alternatives, but the pre-pull framing and the mention of 'what would change' and 'local stands in the way' give an agent enough context to select it over gitPullRepo or gitRepos. The lack of explicit exclusions or alternative names keeps it from 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond annotations: it reads from class metadata rather than source ('read from the class rather than from its source') and characterizes the operation as 'cheap', implying lightweight execution. It doesn't divulge error behavior, but given annotation coverage, this is solid.

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 compact sentences with zero redundancy. The core purpose is front-loaded, and the alternative guidance is placed in the second sentence without clutter. 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 read-only tool with one well-documented parameter and no output schema, the description fully covers what the agent needs: what is returned, the lightweight nature, and how to get the actual source. No critical gap remains.

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 for the single 'url' parameter ('The URL of the class'). The description adds no additional meaning about the parameter or its format, so it rests at 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 clearly states the verb ('read') and resource ('class') and enumerates the exact contents returned: methods with visibility, attributes, types, and interfaces. It explicitly distinguishes itself from source-reading tools like getObjectSource and fragmentMappings, making its purpose unmistakable.

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

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

The description provides explicit guidance on when to use this tool: 'the cheap answer to what can this class do', and directs to alternatives for source retrieval ('fragmentMappings or read whole with getObjectSource'). This is concrete, actionable routing.

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 destructiveHint=false, covering the safety profile. The description adds that URLs are returned for each include and explains the separation of test classes, which provides some behavioral context. It does not describe response format or other traits, and there is 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 a single run-on sentence that is grammatically awkward and hard to parse. It packs multiple ideas without clear structure, making it less concise and more confusing than it should be.

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

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

With no output schema, the description should clearly specify the return format. It mentions URLs but does not indicate whether the result is a list, array, or object structure. It also lacks any prerequisites or additional context needed for correct usage, leaving the tool under-described 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?

The schema fully documents the single parameter 'clas' with 'The class name', achieving 100% coverage. The description does not add any additional meaning about the parameter, 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 states that the tool returns the includes of a class (definitions, implementations, macros, test classes) with their URLs, which conveys the core purpose. However, it lacks a clear verb (e.g., 'list' or 'retrieve') and the phrasing is convoluted. It hints at a connection to revisions and getTextElements but does not explicitly differentiate from siblings.

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 mentions that this is how test classes are read/written separately and that include names are used by revisions and getTextElements, giving some contextual guidance. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, leaving the guidance implicit rather than prescriptive.

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 destructiveHint=false, so the safety profile is established. The description adds that the tool 'needs the source and the position, exactly like the editor,' which clarifies the stateless, read-only nature and input prerequisites. But it does not disclose potential failure modes, rate limits, or what happens on invalid input, so the added behavior context is moderate.

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 with no filler. The core purpose is front-loaded, and the sibling comparisons are placed after the main definition. Slightly run-on but still concise and well-organized for the amount of context it conveys.

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 purpose and input relationship to the editor, and differentiates siblings, which is helpful. But with no output schema and 0% schema coverage, it fails to specify the return shape or how results are represented, and leaves the sourceUrl parameter semantically dark. This is adequate for deciding when to call it, but not complete for reliably invoking it with full understanding.

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?

With schema description coverage at 0%, the description must compensate for the undocumented parameters. It maps 'source' and 'position' to source, line, and column, and 'exactly like the editor' gives some context for line/column indexing. However, sourceUrl is left unexplained, and the description does not clarify the units or whether line/column are zero-based. Thus compensation is partial at best.

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 what the tool does: 'Completion proposals for a cursor position: what may be written at line/column of this source.' It names the resource (source code) and the specific operation (completion proposal). It also distinguishes itself from siblings by explicitly contrasting with codeCompletionFull (adds insert text) and codeCompletionElement (details of one proposal), so an agent can tell them apart.

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

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

The description gives context for when this tool is valuable: 'worth having when composing a call against an unfamiliar interface.' It also implies selection guidance by noting what the siblings add, which helps an agent choose between this and codeCompletionFull/codeCompletionElement. However, it does not explicitly state conditions for preferring the alternatives or 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 and destructiveHint=false, so the description does not need to restate safety. The description adds that the tool returns details such as type, documentation, and source, and implies a dependency on a prior codeCompletion response. It does not disclose any further behavioral traits such as failure modes or prerequisites beyond the input parameters.

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 short sentences with no filler. It front-loads the tool's purpose and then gives the usage context. Every sentence contributes meaning.

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's role as a follow-up detail lookup for codeCompletion is clear, and the annotations cover its read-only safety profile. However, with four required parameters, zero schema-level descriptions, and no output schema, the description should explain parameter roles more fully. It is minimally adequate but leaves meaningful gaps for an agent trying 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 description coverage is 0%, and the description does not explain any of the four required parameters: sourceUrl, source, line, and column. 'Where it comes from' vaguely hints at source/sourceUrl, but the coordinates and their relationship to a completion entry are undocumented. This forces the agent to guess parameter semantics from names 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 identifies the tool as providing details for a single code completion proposal: its type, documentation, and origin. It also ties itself to codeCompletion, which helps an agent understand its role in the completion workflow. However, it lacks a strong imperative verb and does not explicitly distinguish itself from the codeCompletionFull sibling.

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

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

The phrase 'Follows codeCompletion for the entry you want to know more about' gives explicit contextual guidance on when to invoke this tool. It tells the agent this is a follow-up detail lookup after a codeCompletion call. It does not mention when not to use it or compare against similar siblings like codeCompletionFull, but the core usage condition 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 and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that the tool returns both the text to insert and the insertion position, which is useful behavioral context. However, it does not disclose details like whether the completion is context-sensitive, how the position is represented, or any rate-limit/performance traits.

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 core purpose is front-loaded and the sibling distinction is included. It is appropriately concise, though it could have used the second sentence to explain parameters instead of only naming the sibling.

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 required parameters, no output schema, and 0% schema description coverage, the description is too thin. It does not explain the meaning of sourceUrl or patternKey, nor what the completion response structure looks like. The sibling distinction helps, but an agent would still be guessing about critical inputs.

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 0%, so the description carries the full burden of explaining the 5 required parameters. The description only mentions 'cursor position in a source' and 'text to insert', which maps to line/column/source but leaves sourceUrl and patternKey unexplained. With zero schema descriptions and no parameter details in the description, an agent cannot confidently determine what patternKey or sourceUrl mean.

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: it provides completion proposals with the text to insert and the position to insert it at, for a cursor position in a source. It also distinguishes itself from the sibling codeCompletion by calling itself 'the fuller form of codeCompletion', which helps an agent differentiate the two.

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 (cursor position in a source) and names the sibling codeCompletion as the alternative, but it does not explicitly state when to use this tool versus codeCompletion or codeCompletionElement. The phrase 'fuller form' gives some guidance but leaves the selection criteria to inference.

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?

Because annotations already mark the tool readOnlyHint=true and destructiveHint=false, the description does not need to re-state safety. It adds value beyond annotations by disclosing what the operation exposes: capabilities, supported types, and versions. This is useful context given there is no output schema declared.

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 wasted words and front-loads the main subject (collection) and the key return contents. However, the wording 'What one collection ... offers' is slightly unusual for a command-oriented tool; a clearer phrasing such as 'Retrieve the details of a single collection...' would be more direct.

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 low parameter count, the explicit annotation of a safe read-only operation, and the absence of an output schema, the description covers the basics well. It states what a caller will get (capabilities, types, versions) and the resource domain (discovery document). It could mention how to obtain the URL (e.g., via a discovery endpoint), but the parameter schema already describes the URL input.

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 only parameter, url, already has a clear schema description. The tool description mentions 'collection' and 'discovery document', which loosely relates to the url parameter, but it does not add meaningful detail about the URL format or how the URL identifies the collection. Therefore it sits at 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 identifies a specific resource (a collection in the discovery document) and its content (capabilities, supported types, versions), but it never states an explicit verb such as 'retrieve' or 'get.' It reads more like a statement about the resource than a clear operation description. It does not explicitly distinguish itself from the closely named sibling featureDetails.

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

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

The phrase 'what one collection of the discovery document offers' implies the intended use is to fetch details for a single collection, but it gives no explicit guidance about when to choose this over featureDetails or findCollectionByUrl. There is no when-not-to-use direction or mention of alternatives, so the guidance is only implicit.

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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is already covered. The description adds valuable behavioral detail beyond that: the default behavior when neither side is given, the meaning of 'active' and 'inactive' (what the system executes vs the working version), and the diff anchoring rule that avoids treating an inserted method as two rewritten methods. This goes well beyond a simple 'compares versions' statement.

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 moderately long but every sentence carries unique information: purpose, side specifiers, defaults and a special case, and diff anchoring behavior. It is front-loaded with the core purpose and then layers on usage detail. No filler or repetition; the structure flows logically from what to how.

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 8 parameters and no output schema, the description covers the essential operational context: what the tool does, how to specify sides, defaults, and diff quality. It does not detail the output format beyond 'unified diff', but that is a well-known standard. The standard ADT addressing parameters (objectUrl, objectName, objectType) are self-explanatory from the schema. The description is sufficient for an agent to call it correctly 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 parameter descriptions already list the allowed forms for 'from' and 'to'. The tool description enriches these by explaining the semantics of each side specifier: 'active' means what the system executes, 'inactive' is the working version, and 'latest' is the newest in history. It also clarifies the defaults for both parameters (newest and second newest). This adds meaning beyond the schema's terse enum-like lists.

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

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

The description opens with a clear verb+resource: 'What changed between two versions of one object, as a unified diff.' It explicitly names the operation (compare) and the resource (object), and distinguishes itself from sibling tools like 'revisions' (which lists versions) by focusing on the diff. The specific side-naming forms (revision, transport request, active, inactive, latest) make its purpose unmistakable.

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

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

The description explains several concrete use scenarios: comparing the two newest versions to answer 'what did the last change do', and comparing 'active' against 'inactive' to see an unactivated edit. It gives clear context for when to invoke the tool, though it does not explicitly name alternative tools or state when not to use it. The guidance is implicit in the scenarios but not exclusionary.

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 goes well beyond annotations by disclosing the internal sequence (validate, create, lock, write, unlock, activate with verification), the non-rollback behavior ('Nothing is rolled back on failure'), and the empty-shell consequence of creating without source. It also clarifies language default behavior, which is important for object creation. Annotations only indicate not read-only and not destructive, so the description adds substantial behavioral context.

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

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

Three sentences that are dense with information: the main purpose is front-loaded, followed by the reason for combining steps, a special case, and failure behavior. No wasted words; every sentence 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 the complexity (12 params, 5 required) and no output schema, the description covers the process, failure handling, and key parameter interactions (mainProgram, language, transport). It does not describe the success response format, but it does say the answer indicates the failing step on failure. For a complex tool, this is fairly complete, though the exact response structure remains undocumented.

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 all parameters have descriptions. The tool description adds context beyond the schema: it explains mainProgram's role for PROG/I, the language default logic, and that transport is not needed in $TMP. This enhances understanding of how parameters interact, though the schema already carries the basic 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 the tool's purpose: 'Create an object and put its source in it, in one call' and outlines the steps (validate, create, lock, write, unlock, activate). It distinguishes from siblings by noting that 'Creating and writing are separate calls in ADT' and that this combines them, differentiating it from createObject, setObjectSource, and similar 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 explains the tool is for creating an object with source in one step, and mentions when to use it (e.g., for PROG/I with mainProgram) and the failure behavior. However, it doesn't explicitly name alternatives like createObject + setObjectSource as the alternative for separate calls, so while usage context is clear, exclusions are only 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 already mark the tool as non-read-only and non-destructive, and the description adds useful behavioral context by warning about the 500 error for a variant name. It could go further into side effects or what starting the run entails, but with annotations present the bar is lower and this description clears it.

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

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

Three sentences with the essential caveat front-loaded and no real filler. The 'whatever your are still calling it' wording is slightly informal and 'first parameter' could be tighter, but 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?

For a 3-parameter tool with no output schema, it covers the key workflow: use atcCheckVariant to get the worklist id, call this tool, or switch to the atcCheck sequence. It leaves mainUrl and maxResults semantics to the schema and does not fully describe the result of launching the run, which 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 coverage is 100%, so the baseline is already adequate. The description reinforces the critical variant semantics, tells the agent to get the id from atcCheckVariant, and rejects the variant-name alternative; it does not need to add much for mainUrl or maxResults given the schema already describes them.

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 action ('Starts an ATC run' over one object) and differentiates it from nearby siblings it mentions: atcCheckVariant produces the id and atcCheck does the whole sequence. An agent can tell this tool is the single-step launcher versus the alternatives without opening their 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 is explicitly stated that the first parameter must be a worklist id, not a check variant name, and it even names the failure mode: the backend answers 500 for a variant name. It also provides concrete routing rules: get the id from atcCheckVariant, or use atcCheck when the whole sequence is wanted.

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 declare readOnlyHint=false and destructiveHint=false, so the description carries the full burden. It discloses meaningful behavioral traits: nothing is rolled back if a step fails, the answer reports each step, labels are cut to SAP's per-label length limits, and the language defaults to the logon language rather than EN (which would hide labels from developers in other languages). This is rich context well 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?

Front-loaded with the core purpose and pipeline; the most important behavioral caveats (no rollback, createObject alternative) come early. It is moderately long but every sentence carries information, and none of it repeats 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 21-parameter creation tool with no output schema, the description covers the workflow, the type exclusivity rule, rollback behavior, label truncation, and the language default. The schema itself is rich at 100% coverage, so the description need not repeat parameter definitions. Slightly more detail on the return/report structure would push it higher, but it is substantially 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 the schema already documents every parameter individually. The description adds workflow-level meaning (the domain/dataType mutual exclusivity, the label-filling behavior) but does not add per-parameter detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Create a DDIC data element') and enumerates the full pipeline it performs (validate, create, lock, write type and four labels, unlock, activate). It explicitly distinguishes itself from the sibling createObject by noting that createObject leaves an element with no type that cannot be activated, so an agent can tell them apart.

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?

Names the alternative (createObject) and the exact condition that selects it — createDataElement gives the type and definition in one call, createObject leaves the element typeless. Also states that type is either a domain or a built-in ABAP type, not both, which routes correct parameter choice.

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?

Beyond the minimal annotations (readOnlyHint=false, destructiveHint=false), the description discloses the critical non-atomicity: 'Nothing is rolled back if a step fails - the answer reports each step, and a domain that was created but not written is still there to correct or delete.' This partial-failure behavior is exactly the kind of context an agent needs and is not derivable from the schema. 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?

Three dense sentences with no filler. Purpose is front-loaded, differentiation comes second, and failure behavior is last. Each sentence earns its place. It is slightly dense but appropriate for the complexity of a 19-parameter mutation tool.

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

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

Given 19 parameters, minimal annotations, and no output schema, the description carries a heavy burden. It covers the pipeline, the createObject pitfall, and the partial-failure/return-reporting behavior ('the answer reports each step'). It could mention transport handling or when to use setDomainProperties for modifications, but for a creation tool the coverage is strong.

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 19 parameters are already documented in the schema. The description adds marginal value by mapping the pipeline to parameter groups ('write the type and output format (and value table or fixed values)' → datatype, outputLength, valueTable, fixValues), but this is redundant with the schema's per-parameter descriptions. 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?

States a specific verb+resource+scope: 'Create a DDIC domain and give it its definition, in one call.' It enumerates the exact pipeline (validate, create, lock, write, unlock, activate) and explicitly differentiates from the sibling createObject, which 'alone leaves a domain with no definition, which cannot be activated.' An agent can clearly tell what this does and how it differs from nearby 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 explicitly tells the agent when NOT to use the sibling createObject and implies this tool is the correct choice for a fully-defined domain. It does not enumerate every alternative (e.g., setDomainProperties for editing an existing domain, getDomainProperties for reading), but the primary routing decision is handled clearly. Strong guidance with minor gaps.

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 readOnlyHint=false and destructiveHint=false, annotations indicate a write operation but don't detail side effects. The description compensates by stating it creates, writes, activates, and verifies, and explains why the interface is built from data (ADT keeps it in source text). It also discloses the transport request requirement. This adds meaningful context beyond the 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?

Two dense sentences with zero waste. The primary purpose is front-loaded, followed by the two critical constraints (group existence and transport requirement). Every clause earns its place, and it's concise for a tool with 11 parameters.

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 write operation with complex parameters, the description covers the essential workflow (create/write/activate/verify) and prerequisites. The schema fully documents all parameters, and the description adds the mechanism and constraints. It doesn't describe return values, but there's no output schema, and the behavior is well covered. A complete guide for calling 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 each parameter is already documented. The description adds a high-level explanation that the signature is passed as data and the ABAP interface is built here, helping the agent understand how the parameter arrays map to the source. While it doesn't enumerate parameters, it adds conceptual value beyond the schema, justifying a score above 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 clearly states the tool creates a function module in an existing group, combining signature and body in one call (create, write, activate, verify). It differentiates from sibling createAndWrite by explicitly referencing it for group creation, so an agent can distinguish the two operations.

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 prerequisites: the group must exist, and a group outside $TMP requires a transport request. It names createAndWrite as the alternative for creating groups, giving context for when to use this tool vs. another. However, it doesn't list other alternatives (e.g., getFunctionModule) or explicit 'when not to use' conditions, so it falls slightly short of a 5.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false, which is minimal. The description adds meaningful behavioral context: it explains the failure mode of the alternative (createObject), the backend rejection, and the fact that this tool posts the include document together with its context reference. It doesn't fully disclose response behavior or side effects, but it goes 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?

Three sentences with zero waste. The core purpose is front-loaded, the alternative is named, and the technical reason is given in one clause. 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 creation tool with no output schema, the description covers the key context: what it creates, why it exists, and how it differs from the sibling. It doesn't describe the response format or error cases, but the annotations already indicate it's not read-only and not destructive, and the schema covers all parameters. The main gap is the lack of return-value information, but that's minor given the tool's simplicity.

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 7 parameters. The description adds context for mainProgram ('This is the reference createObject fails to send'), which is valuable, but it doesn't add meaning for the other parameters. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description states a specific verb ('Create'), a specific resource ('report include (PROG/I)'), and explicitly distinguishes it from createObject. It also explains the underlying reason (abap-adt-api builds the creation body without the main program reference, causing backend rejection). This is a clear, specific purpose that an agent can act on.

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 instead of createObject for includes' and explains why createObject fails (400/500 regardless of parameters). This is a direct when-to-use and when-not-to-use instruction with a named alternative. It also notes that the tool posts the include document with its context reference, which clarifies the correct usage path.

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?

It adds meaningful behavioral detail beyond the annotations: no activation, no rollback, partial state on failure, and transport requirements. The description explains what happens when a step fails, which is critical for an agent to reason about consequences.

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

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

Three dense, purposeful sentences with no filler. The action is front-loaded, and every sentence adds operational or behavioral 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 7-parameter, no-output-schema tool, it explains the key behavioral risks, the execution sequence, and the transport constraint. It could be slightly more explicit about required-parameter relationships, but the schema fills most gaps.

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 little semantic glue, such as 'validate the name' and 'write the messages', but most parameter meaning is already supplied in 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 uses a specific verb and resource: 'create a message class and fill in its messages in one call'. It clearly distinguishes this from single-step create or message-writing tools by emphasizing the combined workflow and the 'no activation' behavior.

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 practical context such as transport requirements and the non-transactional execution, which helps an agent decide where this tool fits. However, it does not explicitly state when to prefer this over related siblings like setMessages or createObject.

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

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries more weight. It reveals an important behavior: it refuses report include objects and points to createInclude, which is beyond what annotations provide. However, it doesn't disclose other behavioral traits like authorization requirements, error handling, or side effects, so it only moderately covers behavioral 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, no redundancy. The core action is front-loaded, and the key exclusion is communicated clearly with a direct pointer to the alternative tool. Every sentence contributes value.

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

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

The tool is complex with 7 parameters (5 required) and no output schema, yet the description only notes the include exception. It does not explain what ABAP object types are supported by applicable parameter values, parent/name semantics, or typical object creation workflow. This is seriously under-specified for an action with so many input fields and a broad domain.

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 0%, meaning the input schema has no descriptions for any of the 7 parameters, and the description itself also gives no meaning for objtype, parentName, transport, parentPath, description, or responsible. The agent has nothing to infer the required format, constraints, or relationships between 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 a specific action 'Create a new ABAP object' and explicitly calls out the one type it cannot create, thereby distinguishing itself from sibling tools like createInclude. This is a clear verb+resource statement with practical evidence of differentiation.

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

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

It provides an explicit when-not and an alternative: report includes (PROG/I) are refused, and createInclude is pointed to. However, it doesn't give any broader guidance about when to prefer this tool over other create siblings such as createDomain or createStructure, so it's not fully complete 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?

The description discloses several critical behaviors beyond annotations: it is non-atomic ('Nothing is rolled back'), it reports the step where failure occurred and the resulting state, and it constructs the DDL internally (including opening keyword differences). It also explains the activation requirement for unit/currency fields and the platform restriction for TABL/DT. These are substantial behavioral details not captured in the annotations (which only indicate non-read-only and non-destructive - actually destructiveHint false is a bit ambiguous, but the description overrides with clear non-rollback).

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 moderately long but every sentence adds essential information. It front-loads the primary purpose and step sequence, then covers critical requirements (units, TABL/DT), and ends with a crucial caveat about rollback. There is no fluff; each sentence serves a distinct purpose.

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

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

Despite no output schema, the description fully covers the lifecycle of the creation: what happens, what can go wrong, what the response includes (step stopped and state), and how to avoid pitfalls (dryRun, units, language). With 9 parameters, the description provides enough guidance to call correctly, even without an output schema. The note about getStructureSource covers future inspection, and the warning about language helps avoid misuse.

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

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

Schema coverage is 100%, so the schema already documents parameters well. However, the description adds significant semantic value beyond the schema: it explains the purpose of fields (passed as data to build the DDL), clarifies the unitField/currencyField requirement for activation, and warns about the interaction between packageName and transport. It also explains the opening keyword difference across releases, which is not in the schema. Thus, the description substantially enhances understanding of the 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 that it creates a structure (TABL/DS) and gives it fields in one call, listing the steps (validate, create, write, syntax check, activate, verify). This differentiates it from siblings like createDataElement, createDomain, and createObject, which create different object types. The specific verb 'create' and the resource 'structure' are 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 explicitly explains when to use this tool: to create a new structure with fields in one callvon ABAP. It contrasts with getStructureSource for details on transparent tables over ADT, and it mentions the alternative of using dryRun for validation without creation. It also notes prerequisites like passing unitField/currencyField for quantity/currency fields and clarifies that the DDL is built here, implying that this tool is the primary creation path.

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 indicate readOnlyHint=false and destructiveHint=false, meaning the tool is a non-destructive write operation. The description adds meaningful behavior beyond this: it writes an empty include and clarifies that runTests executes its contents. This provides insight into the tool's effect and expected usage, complementing the annotation profile 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 no redundancy. The primary purpose is front-loaded ('Create the test include of a class'), and the second sentence adds essential behavioral detail about the empty include and the runTests relationship. Every word earns its place, making it exceptionally concise and clear.

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

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

For a simple creation tool with no output schema, the description covers the core behavior: creating an empty test include and its subsequent use with runTests. It does not mention prerequisites like the class existing or locking, but those are implied or covered by the schema parameters. The description is complete enough for an agent to understand the tool's role, though it could be more explicit about side effects or error conditions.

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

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

All parameters are documented in the input schema (100% coverage). The description does not add any parameter-specific information, but the schema already provides clear explanations for 'clas', 'transport', and 'lockHandle'. Since the schema fully covers parameter semantics, the description does not need to repeat them, so a 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 and resource: 'Create the test include of a class'. It clearly differentiates this from a generic include by specifying 'test include' and explains why it is needed ('which a new class does not have'). However, it does not explicitly distinguish from sibling tools like createInclude, relying on the 'test' qualifier rather than naming alternatives. Thus, it is clear but lacks direct sibling differentiation.

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 when to use the tool: to create a test include for a class that lacks one. It also mentions 'runTests' as the follow-up action, giving context. However, it provides no explicit guidance on when not to use it or alternatives such as createInclude for other include types. The usage context is implied but not formally contrasted with other 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?

The annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the behavioral disclosure burden. It explains ownership, open persistence until release, team visibility, and manual deletion, which are exactly the side effects an agent must understand before calling this 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?

The description is compact, front-loaded with the primary action, and every sentence contributes either lifecycle, usage, or cautionary guidance. There is no filler or irrelevant detail.

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 and absence of an output schema, the description covers purpose, lifecycle, and usage well. The only notable gap is that it signals the request number can be reused without explicitly stating what the tool returns, which would make the contract even clearer.

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 parameters are already documented at a basic level. The description adds some workflow context about reusing the resulting request number, but it does not add deeper meaning about how the fields relate or their expected formats.

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-resource pair: 'Create a workbench request' and adds lifecycle details ('becomes yours and stays open until it is released'). It is clear enough to distinguish from most siblings, though it does not explicitly contrast with createTransportsConfig.

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 guidance: create one per piece of work, reuse the number for related writes, and ask the user first if a request already exists. It also warns about the consequence of unwanted requests, which strongly helps an agent decide correctly.

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 create nature directly matches annotations (not read-only, not destructive), so no contradiction. However, beyond 'shared setup', the description does not disclose side effects, overwrite/idempotency behavior, or prerequisites; the behavioral burden is mostly carried by 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?

Two compact sentences with no filler; the main action is front-loaded and the alternative is delivered in the second sentence. 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 parameterless create operation with no output schema, the description covers what is created, for whom, and when the simpler alternative is preferred. It could still say whether the operation is idempotent or what the success response is, but those are minor for such a simple 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?

There are 0 parameters demonstrated by the schema, so the baseline is 4; no parameter-specific description is required. The description adds no param detail, which is fine because the schema already provides full 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 uses a specific verb-resource pair ('Create a transport configuration') and narrows scope to 'the organizer' / 'shared setup'. It also differentiates from the sibling `createTransport` by noting most work needs only that tool, so an agent can tell them apart.

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 states this is for 'shared setup' and adds 'most work needs only createTransport', giving both a when-to-use signal and a named alternative. This is sufficient for tool selection even though it does not enumerate every transport-related sibling.

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 destructiveHint=false, covering the safety profile. The description adds scope context (which element types it covers) but does not detail return format, pagination, or error behavior. This is acceptable given the read-only annotation, but it does not go beyond the basics.

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. The core purpose is front-loaded, and the alternative tool is mentioned concisely. 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 tool with fully documented parameters, the description is complete enough. It clarifies scope and points to the right alternative. It could mention return structure, but without an output schema it is not strictly required.

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

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

Schema description coverage is 100%, so all four parameters are already well documented. The description adds no parameter-specific detail beyond what the schema provides, which is acceptable per the baseline of 3 when schema carries the 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 tool retrieves a dictionary element (data element, domain, or type) with its properties. It explicitly names the types covered and distinguishes from getStructureSource for tables/structures, so an agent can tell them apart without inspecting 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 provides a clear alternative for a different case (tables/structures should use getStructureSource), which implicitly tells the agent when to use this tool. However, it does not enumerate all other scenarios or exclusions, but the guidance is sufficient for common use.

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 provide readOnlyHint=true and destructiveHint=false, and the description is consistent with them. It adds a small behavioral nuance by saying the metadata is exposed 'as the dictionary itself sees them,' but it does not disclose response shape, path semantics, or any special behavior beyond that.

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 with no filler. It front-loads the action and resource, then adds a clarifying qualifier about the dictionary's own perspective.

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 one-parameter read tool with read-only annotations, the description is mostly adequate, but it leaves the expected path format and the distinction from sibling DDIC tools unstated. The lack of an output schema makes the vague return scope slightly more noticeable.

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% coverage: the single 'path' parameter is described as 'The path to the DDIC element.' The description adds only a slight clarification that the element is dictionary metadata, so it does not meaningfully go 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 uses a specific verb ('Read') and resource ('dictionary metadata' via the DDIC repository access endpoint), and names the relevant content: types, fields, and domains. It is clear on its face, though it does not explicitly contrast with sibling tools like ddicElement or getDomainProperties.

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?

There is no guidance on when to use this tool instead of the many related DDIC read tools in the sibling list. The description implies a read-only metadata use case but does not state conditions, exclusions, or 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?

Beyond annotations, it discloses that attachment holds the process and that abandoning it can leave a work process frozen. It gives concrete cleanup paths (debuggerStep terminate or listener deletion).

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 compact sentences, direct start with the action and immediate caveat. No filler; the cleanup warning is necessary 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 tool with no output schema and simple parameters, the description supplies the missing lifecycle context: attach after listen, read state after attach, and release via step/terminate or listener delete. Enough 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?

Input schema covers all 4 parameters (100%), so the baseline is 3. Description doesn't add parameter-specific detail beyond the schema fields.

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 names a specific verb, attach, and resource, the process stopped at a breakpoint reported by debuggerListen. It distinguishes itself from sibling debugger tools by explicitly referencing the listener and later stack/variable reads.

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 tells exactly when to use: after debuggerListen, before stack/variables are meaningful. It also says when serving as cleanup alternative: use debuggerStep with terminate or delete the listener.

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 destructiveHint=false, covering the safety profile. The description adds that it opens composite variables, but does not explain behavior like what happens if the variable has no parts, or whether it returns the parts or just expands them. Since annotations handle the main behavioral trait, the description provides modest additional context.

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

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

The description is two sentences, concise and front-loaded with the main purpose. It wastes no words and is easy to scan. It could be slightly more structured (e.g., bullet points) but is effective.

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 is relatively simple, but the description lacks details on the return value or output format (no output schema). The parameter ambiguity (array vs single id) and lack of explanation about what 'parts' means or how the tool behaves for different variable types leave an agent with insufficient information to call it reliably. Given the debugger context, more context is expected.

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 describes the parameter 'parent' as an array of 'The parent variable name', while the description says 'Takes the variable id from debuggerVariables' – a mismatch in terminology (name vs id) and no clarity on how the array is used. With 100% schema coverage, the baseline is 3, but the description introduces confusion about the parameter's meaning, so it actually detracts from clarity. The array type is also unexplained, suggesting possible multiple parents but not elaborated.

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 opens a variable that has components (structure fields, internal table rows, reference targets). This is a specific verb and resource. However, it does not explicitly distinguish itself from the sibling debuggerVariables, which might also list variables, so it does not fully differentiate from likely alternatives.

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 should be used after obtaining a variable id from debuggerVariables, giving a prerequisite context. However, it does not explicitly say when to use this tool versus other debugger tools (e.g., debuggerStep) or when not to use it. The guidance is implicit rather than explicit.

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 mark this as destructive, and the description adds meaningful context by explaining the real-world consequence of not cleaning up breakpoints. It also links this tool to the lifecycle of debuggerSetBreakpoints, which is useful behavioral information.

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 core action is stated first, then the source of ids, then a practical motivational note. Everything 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 destructive cleanup operation with no output schema, the description explains what it does and why it matters. It does not specify return values or exact breakpoint object shape, but given the simple deletion action and the cross-reference to the setter, this is adequate.

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 generic parameter descriptions already exist. The main added value is clarifying that breakpoint ids come from debuggerSetBreakpoints, which helps understand the 'breakpoint' parameter, but no additional detail is given for the other 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 uses a specific verb and resource ('Remove breakpoints') and clearly states where the ids come from ('debuggerSetBreakpoints'). This distinguishes it from related sibling tools like debuggerSetBreakpoints and debuggerDeleteListener.

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 practical context: cleanup is worthwhile even after a failed session to avoid forgotten breakpoints interfering later. It does not explicitly list when-not-to-use cases or alternatives, but the use case is precise 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 signal a destructive operation (destructiveHint=true), and the description adds concrete behavioral context: it frees the session and warns that a stale listener can block future sessions for the same user. This goes beyond the structured annotations and helps the agent understand 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 two tight sentences with no filler. The action is front-loaded, and the timing/consequence are stated in the second sentence. 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 simple cleanup operation with four parameters and no output schema, the description gives enough context: what the tool does and when it is needed. Missing return-value or error behavior is minor for this kind of action, and the annotations already cover the destructive profile.

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 four parameters at a basic level. The description adds no per-parameter detail beyond the schema, so the baseline of 3 applies here.

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 action ('Stop listening for breakpoints and free the session') and clearly ties it to the tool's resource and lifecycle role. It also distinguishes this tool from sibling debugger tools like debuggerListen and debuggerDeleteBreakpoints by focusing on session cleanup rather than breakpoint manipulation.

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 the tool ('when a debug session is over or abandoned') and gives the consequence of not using it ('a listener left behind blocks the next one for the same user'). It does not explicitly name sibling alternatives, but the usage context is clear enough for an agent to decide correctly.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description clarifies a key behavioral nuance: this changes only the viewed frame, not the suspension point. This prevents a common misconception and adds real value about the tool's effect.

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 short sentences, tightly written. The primary purpose is front-loadedeb8 and the clarifying contrast ('changes the view, not the position') is concise and valuable. 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 tool with one well-documented parameter and no output schema, the description fully covers the behavioral essentials. It explains the purpose, the effect on debuggerVariables, and what it does not do, which is sufficient 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 schema already covers the single parameter with 100% coverage, describing it as 'The URL or position of the stack entry.' The description adds that it refers to a stack frame but does not provide additional format or resolution details. With full schema coverage, the baseline of 3 is appropriate.

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

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

States a specific verb ('Move') and resource ('the debugger view to another frame of the stack') and clearly connects it to the observable effect on debuggerVariables. It also distinguishes the operation from changing the program position, which separates it from debuggerStep and similar 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 clearly implies when to use it: when a user wants debuggerVariables to reflect another stack frame. It also implicitly warns against expecting the program position to change impossible in a debugger context. However, it does not explicitly name sibling alternatives or state when not to use it, so it stops short of a 5.

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

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

Annotations only say readOnlyHint=false and destructiveHint=false, which is minimal. The description adds significant behavioral context: the call blocks/waits, it occupies the session, and the listener should be deleted when done. It does not mention timeout specifics or what happens on timeout, but the core blocking behavior is clearly 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 a single paragraph that front-loads the most important behavior (blocking wait) and then explains the workflow and caveats. It is slightly longer than necessary but every sentence adds value: the blocking nature, the workflow, the external-trigger limitation, and the session-occupancy warning.

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