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

Annotations already state destructiveHint=true and readOnlyHint=false, and the description adds useful detail that check mode takes no lock while activate proceeds to activation. It does not contradict the annotations, but it also does not disclose what activation actually changes, whether locks are held during activation, or what side effects might occur.

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 extremely compact, front-loaded, and contains no waste: each clause maps to one mode. It loses the fifth point only because it is slightly too terse to carry the behavioral nuance that this complex tool likely needs.

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 mutation tool with seven parameters, nested objects, a 50-item batch mode, enhancement-spot requirements, transport request handling, and no output schema. A two-clause description leaves out the high-level activation workflow, batch-vs-single-object semantics, and side effects, so an agent must reconstruct most of the tool's operating context from the schema and sibling names.

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

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

Schema description coverage is 100%, so the baseline is 3 without any extra parameter explanation. The description adds some behavioral meaning for mode (no lock versus check-then-activate), but it does not clarify the meaning or usage of type, object, source, affects, corr_nr, or the batch objects array beyond what the schema already states.

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 operation: syntax-check or activate an ABAP object, with mode-specific behavior. It is specific enough to know what the tool does, but it never explicitly names the resource (ABAP development objects) or distinguishes itself from siblings like abap_read/abap_enh, so it stops shy of a perfect score.

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

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

The description provides clear mode-level guidance: check is syntax-check with no lock, activate is check-then-activate. However, it gives no explicit guidance on when to choose this tool over siblings or when activation should be avoided, leaving usage decisions largely 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?

The readOnlyHint annotation already signals safety, and the description aligns with it ('Reads'). It adds real behavioral context beyond the annotation by labeling raw as expensive and by framing check_refs as probing up to max_sites, which warns of potential cost/scope.

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 tight sentence front-loads the core read operation and then uses pipe-separated modes to pack all behavior into a scannable line. Every phrase ('default', 'expensive escape hatch', 'needs object_type', 'default 25') 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 six fully schema-described parameters, the description covers all modes, defaults, and key prerequisites. The only gap is that search/check_refs return shapes are not described and there is no output schema to carry that burden, but invocation decision-making is complete.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds useful semantic color: 'digest' and 'v4 XML' explain what show/raw return, and it restates mode-specific prerequisites and defaults in a compact form. This exceeds the baseline without duplicating every schema detail.

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 opening verb 'Reads' plus the resource 'a BOPF business object's design-time model' makes the action and object precise. Listing the four modes (show/raw/search/check_refs) further distinguishes it from generic siblings like abap_read and abap_search.

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

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

The description gives concrete mode-selection context: show is the default digest, raw is an expensive escape hatch, search requires object_type, and check_refs is capped by max_sites. It does not explicitly state when to choose this over abap_read/abap_search, so it falls short of full exclusion guidance.

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

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

The description adds meaningful behavioral context beyond the annotations: 'One session at a time' reveals a stateful singleton constraint, and 'variables read-only, frames observe-only' clarifies what the driver can and cannot mutate. It does not contradict the readOnlyHint=false or destructiveHint=true annotations because stepping and stopping a debuggee are active operations even though user-visible variables are read-only.

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 filler. The primary verb set is front-loaded, and the second sentence packages three critical constraints compactly. Every clause earns its place.

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

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

This is a complex nine-parameter tool with nested breakpoint objects and no output schema, yet the rich input-schema descriptions cover action requirements, return-referenced fields like stateId and status, and edge cases like force and jumpToLine. The description supplies the high-level orientation and the singleton/read-only constraints, which combined with the schema is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all parameters in detail, including action dependencies, defaults, required fields, and constraints like 'stale id is refused.' The description itself adds little parameter-level meaning beyond orienting the agent to the debugger domain, which matches the baseline-3 case.

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 is an 'ABAP debugger driver' and lists concrete verbs: 'arm breakpoints, run a program, step, inspect the stack.' This makes the core purpose obvious. However, it does not explicitly distinguish itself from sibling tools like abap_debug_vars or abap_debug_value, though 'variables read-only, frames observe-only' hints at the boundary.

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 useful context: 'One session at a time' warns against concurrent sessions, and 'variables read-only, frames observe-only' signals limitations. But it does not name alternative tools or state explicit when-to-use/when-not-to-use conditions, leaving the agent to infer the routing decision.

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 carry readOnlyHint and openWorldHint, lowering the bar for behavioral disclosure. The description adds the row-window behavior for tables and the single-path scope, but does not disclose output shape or how unknown/open-world results are rendered; 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?

One front-loaded sentence. 'Tier-2 drill-in' immediately orients the agent, and the row-window clause earns its place as a distinguishing behavior.

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 drill-in with fully documented parameters, the description is nearly sufficient. The main gap is an explicit link to sibling tools and the exact usage moment, but schema descriptions for stateId and path cover invocation mechanics, and no output schema is needed for a render-style result.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only gestures at table row windowing (reinforcing from/count) without adding semantic detail 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 uses a specific verb ('render') and a clear object ('one variable path in detail'), and 'Tier-2 drill-in' signals this is the focused follow-up to broader debug tools. It does not explicitly name a sibling, but the scope 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?

'Tier-2 drill-in' implies the agent should first obtain a stateId/variable list from a tier-1 tool (likely abap_debug_vars), but it never explicitly states when to choose this over abap_debug or abap_debug_vars, and gives no exclusion criteria.

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

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

With readOnlyHint=true and openWorldHint=true, annotations already cover safety. The description adds valuable behavioral context by disclosing that complex values are returned as abap_debug_value stubs rather than fully expanded, which is meaningful for an agent deciding next steps.

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

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

The description is a single sentence with no filler. It front-loads the core function and tacks on the key behavioral caveat about complex-value stubs, earning its place with zero 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 read-only survey tool with one required parameter and a rich schema, the description covers the essential behavior and return-value format. It could mention pagination or ordering, but given the annotations and the sibling abap_debug_value for expansions, it is sufficiently complete.

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

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

Schema coverage is 100%, with all parameters (scope, filter, stateId) already described in the schema. The description adds no additional parameter-level semantics beyond the overall behavior, so the baseline 3 applies.

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

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

The description clearly states the tool surveys every variable in scope at a debugger stop, which is a specific verb-noun pairing. It also hints at differentiation from abap_debug_value by mentioning complex values return as stubs, though it doesn't explicitly name the sibling in the description.

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 'at a debugger stop' gives clear contextual timing for use, and the stub mention implies that abap_debug_value should be used for expanding complex values. However, it does not explicitly state when not to use this tool or name alternatives beyond the subtle stub reference.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful operational transparency beyond those annotations: the dump feed only reaches back 8 days, an empty list is not proof of no failures, show returns only specific chapters unless the operator enabled more, and key values must be copied verbatim because spaces are significant.

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 core purpose, and every sentence adds a distinct operational fact. It packs mode routing, retention semantics, key-handling warnings, and return-content expectations without repetition 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 8 parameters, no output schema, and nuanced list/show behavior, the description covers the essential semantics needed to select modes, interpret empty results, construct keys, and know what show returns. The annotations cover safety and idempotence, and the description covers the behavioral edge cases that could otherwise lead to false conclusions.

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

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

The input schema already documents every parameter (100% coverage), but the description goes beyond it with critical operational details: no page cursor exists and paging is done by setting to to the oldest timestamp seen, keys must not be trimmed or re-encoded, and chapters are selected by untranslated names rather than titles. These details are essential for correct invocation and are not present 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 names a specific action and resource: 'Read ABAP runtime errors (ST22 short dumps) from the system's dump repository'. It also distinguishes itself from a different kind of read ('not the exception text of a run this server just triggered') and enumerates the two modes, list and show, so an agent can tell exactly what the tool does without inspecting 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 clearly describes when to use list vs show, explains the 8-day retention implication for interpreting empty lists, and instructs verbatim key copying. It does not explicitly name a sibling tool or exclusion relative to abap_read/abap_search, but the mode-level guidance and the 'not the exception text' exclusion give solid contextual direction.

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

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false), and the description adds optional activation and the source-body scope limit. However, most behavioral details (create ops always $TMP and activate, delete irreversibility, read-only discovery) live only in the operation schema, not in the description; the description itself does not go much beyond the annotations plus the abap_write warning. No contradiction with annotations.

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

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

Two sentences with no filler: the default operation is front-loaded, the key exception follows immediately, and the pointer to operation is efficient. Every phrase 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?

The schema is rich enough to support correct invocation, and the description covers the default op plus a critical exception. But with 11 operations, nested parameters, and no output schema, a one-sentence summary of the tool's breadth (creating spots/BAdIs, setting filters, hooks, deletion) would help an agent recognize when abap_enh applies. The current description leans heavily on the agent opening the operation enum.

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 of 3 applies; the description's 'root adtcore:description' and 'existing' wording adds only minor context on top of the already-detailed schema. It does not clarify any parameter beyond what the schema states.

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 names the default action (writes the root adtcore:description) and the target object types (ENHO/XH, ENHO/XHH, ENHS/XS), so the primary behavior is clear. It also explicitly distinguishes this tool from abap_write for plug-in source bodies. However, it does not provide a high-level statement of the tool's full 11-operation role, leaving the overall purpose to be inferred from the operation enum in 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?

It explicitly says not to use this tool for ENHO/XHH plug-in source bodies and routes that case to abap_write. The phrase 'See operation for the other ops' directs the agent to the operation enum for the remaining variants. Broader when-to-use-versus-sibling guidance is absent, but the most important exclusion is covered.

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 destructiveHint annotation, the description discloses critical behavioral details: undo refuses on drift, delete-gate, or enhancement objects, and force overwrites other server changes with an explicit 'Read the object first' warning. This is exactly the extra safety context an agent needs for a destructive operation.

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

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

The description is a single dense paragraph that front-loads the core purpose, then uses a compact mode-by-mode breakdown. Every clause adds information, and the pointer to a recovery reference is appropriately brief.

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 seven parameters, no output schema, and only destructiveHint as an annotation, the description carries a large burden—and it succeeds. It explains all three modes, entry requirements, undo safety constraints, the force overwrite risk, and where to find more details. 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?

The input schema already covers all parameters with descriptions, so the baseline is 3. The description adds cross-parameter semantics, especially the meaning of mode values, the relationship between entry/object, and the force behavior. That added context lifts it above baseline.

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: 'History and undo for writes abapsmith made.' It then enumerates three distinct modes (list, show, undo) with concrete purposes, making it clear what the tool does and how it differs from the broader abap_* sibling tools.

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

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

The description gives clear usage context for each mode: list for recent writes, show for a before-image, undo for reverting. It also warns about conditions where undo refuses to run. It does not explicitly name sibling tools as alternatives, so it loses a point, but the mode-based guidance is strong enough for an agent to decide when to invoke 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 mark this as read-only and open-world safe. The description adds useful behavioral context beyond annotations: it will not actually open a browser, and it requires exactly one of the mutually exclusive modes. No contradiction with the annotations exists.

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

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

The description is compact and front-loaded: it states the output, lists the input modes, then gives the two most important caveats in short sentences. Every sentence earns its place and nothing is redundant.

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 URL-generation tool with read-only annotations, the description is mostly sufficient: it defines what the URL is for, which parameter to use, and the key side-effect note. It could go slightly further by specifying the shape of the returned URL or error behavior for invalid combinations, but the title and schema fill in 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 extra meaning by grouping the parameters into ADT source/HTML (object/type/line), keyword doc (keyword), and Web Dynpro URL (webdynpro), and by clarifying that exactly one is required even though the schema lists no required 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?

The description clearly identifies the deliverable as a browser-openable URL and enumerates the three supported input modes (ADT source/HTML, keyword doc, Web Dynpro URL). The explicit note 'Does not open a browser' prevents a likely misinterpretation and distinguishes this tool from read/search-type 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 phrase 'Exactly one required' gives a clear usage constraint, and 'Does not open a browser' tells the agent what the tool will not do. However, it does not explicitly name sibling alternatives or state exactly when to prefer this tool over another, so usage guidance is strong but not fully 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral facts beyond the annotations: it returns an etag, is capped at ~15k tokens, and can return outlines or partial components. This gives the agent useful expectations about output size and response characteristics.

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

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

The description is three sentences with no wasted words. It front-loads the core purpose, then gives the most operationally important constraint (token cap) and a practical example. 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 14 parameters and no output schema, the description does a good job covering the key operational concern — truncation at ~15k tokens — and the workaround for large objects. The schema already documents each parameter thoroughly, so the description doesn't need to repeat them. It could mention diff/history modes or the return format beyond 'etag', but these are secondary given schema coverage.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra semantic value by showing a concrete example ('{"object":"ZCL_FOO","type":"CLAS/OC"}') and by linking outline/method/offset to the token cap. This helps the agent understand how the parameters work together beyond the schema's individual field descriptions.

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

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

The description is explicit: 'Read an ABAP object: source or pseudo-DDL.' It names a specific verb, resource, and scope, and adds distinguishing context like 'Returns an etag' and the large-object strategy. This is enough to tell it apart from sibling tools like abap_search or abap_enh.

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

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

The description gives clear context for when to use the tool: reading ABAP object source or pseudo-DDL. It also provides internal usage guidance for large objects — 'use outline/method/offset' — which helps the agent choose the right parameters. It does not explicitly name alternative siblings or exclusion criteria, but the purpose is clear enough for selection.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description need not repeat safety. It adds meaningful behavioral context by explaining wildcard matching, the where_used fan-in behavior, and the performance warning, which helps an agent anticipate latency and choose narrower queries.

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 packs the core function, mode details, wildcard behavior, and a performance warning without any filler. Information is front-loaded and the sentence is 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?

The tool has four parameters, all documented in the schema, and annotations cover the read-only and open-world nature. The description fills in the remaining operational knowledge: mode semantics, wildcard usage, and latency expectations. No output schema exists, so the description's current scope is sufficient for safe and effective invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the meaning of the two modes and giving concrete performance guidance on narrowing by type/query, which adds practical parameter semantics not present in 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?

The description opens with a specific verb and resource: 'Find objects by name pattern' and 'list consumers', directly tied to the repository search context. The two modes are explicitly named with their parameters, and the mention of wildcards makes the tool's behavior distinct from sibling read/debug/activate 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 gives clear context for when to use each mode and adds an important practical guideline: '20+ seconds on wide fan-in — narrow by type/query first.' It does not explicitly contrast with sibling tools, but the mode-specific behavior effectively conveys appropriate 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond this: it only exposes contract metadata, never entity data; it detects V2/V4; and unpublished bindings are labeled as such. This gives the agent a clear model of what the tool will and will not do.

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 every sentence earns its place: the first defines the contract contents, the second states the hard limitation, and the third handles the unpublished-binding edge case. The most important scoping constraint, 'contract only,' is front-loaded near the beginning.

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, the description explains what the return concept covers: entity sets, keys, fields, navigation, CRUD/search/page permissions, and V2/V4 detection. It also flags the key limitation and an edge case. Minor gaps like exact response structure or how modes map to output shapes are left to the schema, but the description is sufficient for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the input schema already documents binding, mode, and entity. The description adds context about the contract contents and V2/V4 detection, but it does not substantially expand the meaning of individual parameters beyond what the schema already provides. A baseline of 3 is appropriate since the schema carries the parameter-semantics 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 identifies the tool as returning the OData contract a RAP SRVB publishes, including entity sets, keys, fields, navigation, and permissions. It explicitly distinguishes itself from data-reading tools by stating 'Cannot read entity data — contract only.' The resource and scope are specific enough that an agent can tell this apart from siblings like abap_read or abap_search.

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

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

The description provides a clear when-not-to-use signal by stating 'Cannot read entity data — contract only,' which tells the agent this is for contract metadata, not entity data retrieval. It also notes unpublished bindings are named as such, which helps set expectations. However, it does not explicitly name an alternative tool or state 'use X instead,' so it falls short of a 5.

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

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

Annotations only flag destructiveHint=true, but the description goes well beyond that: it discloses auth requirements (ABAP_MODE=edit/admin, legacy ABAP_ALLOW_WRITE, admin-only transport-delete ceiling with 'no legacy flag grants it'), the side effects of removeObject (drops one E071 entry and its CTS lock; 'if the object still exists, its lock goes too'), and the failure mode where CTS refuses removal, 'leaving the request undeletable.' This is precisely the behavioral context the rubric rewards beyond what annotations convey.

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

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

The description is front-loaded with the verb+resource and operation list, with the release routing placed at the end. However, the removeObject caveat appears both in the description and nearly verbatim in the operation parameter description, a redundancy that costs density; the length is largely justified by nine operations and a complex permission matrix.

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 multi-operation tool with no output schema, the description covers required arguments per operation, permission ceilings, and the removeObject failure mode thoroughly. The main gap is that return values for list/show/users are never hinted at, and there is no guidance on edge states like deleting a request that still has tasks, which an agent would need to predict outcomes.

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, and the parameter descriptions are already rich (per-operation required args, confirm echo semantics, A4HK900123 example). The description adds meaning beyond the schema by defining what operations do — check = 'does an object need a transport?' and the full removeObject workflow — helping an agent map parameters to intent rather than just parameter names.

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

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

Opens with a specific verb+resource: 'Inspect and manage CTS transport requests' and enumerates all nine operations (list, show, check, users, create, addUser, setOwner, delete, removeObject). It differentiates from its closest sibling by name ('Release is a separate tool, abap_transport_release') and defines ambiguous operations such as check ('does an object need a transport?').

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 routes the release use case away ('Release is a separate tool, abap_transport_release') and states the permission model: 'Reads are always allowed; mutating operations obey the write allowlists.' The operation parameter description further specifies per-operation prerequisites (admin-only transport-delete ceiling, confirm echo, required args per operation), leaving no ambiguity about when each operation is permitted.

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