Server Quality Checklist

Tool Scores

• abap_activateB
  3.3/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness2/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• abap_debugA
  3.5/5.0
  Behavior4/5

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

  The description adds meaningful behavioral context beyond the annotations: the one-session-at-a-time constraint and the read-only/observe-only nature of variables and frames. This helps an agent understand the tool's stateful and non-mutating character. It does not contradict the annotations; while destructiveHint=true, the description does not hide that the tool can stop/force-terminate sessions, and the schema details those operations.

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

  Conciseness5/5

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

  The description is a single, tight sentence that front-loads the tool's purpose and then packs the two most important caveats into the second half. It contains no filler, unnecessary repetition of parameter names, or redundant details already present in the schema.

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

  Completeness3/5

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

  For a complex, stateful, 9-parameter tool with multiple actions and no output schema, the description is quite minimal. It captures the essential high-level purpose and constraints, but it does not convey the action/state model (e.g., start requires breakpoints+run, step needs stateId, responses provide stateId), which an agent must fully learn from the schema. The schema is rich enough to compensate, but the description alone leaves important operational gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already thoroughly documents all parameters, actions, and their dependencies. The description adds global context about single-session and read-only constraints, which is relevant to stateId and frame parameters, but it does not add substantial parameter-level meaning beyond the schema. A baseline score of 3 is appropriate here.

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

  Purpose4/5

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

  The description clearly states it is an 'ABAP debugger driver' and enumerates its core actions: arm breakpoints, run a program, step, inspect the stack. This makes the tool's purpose specific and distinguishable from generic ABAP execution tools. However, it does not explicitly differentiate itself from sibling tools like abap_debug_vars or abap_debug_value, so it stops short of full sibling differentiation.

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

  Usage Guidelines2/5

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

  The description gives important context ('One session at a time; variables read-only, frames observe-only') but does not say when to prefer this tool over alternatives or provide exclusions. It does not mention using abap_debug_vars/abap_debug_value for variable inspection, nor warn against using this tool for non-debug program execution. The usage guidance is therefore mostly implicit and left to inference.

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

• abap_debug_valueA
  3.6/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• abap_enhA
  3.7/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines4/5

  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.

• abap_debug_varsA
  3.8/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• abap_searchA
  4.1/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds meaningful behavioral context beyond those annotations: the 20+ second latency risk on wide fan-in and the availability of wildcard matching. 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.

  Conciseness5/5

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

  A single efficiently structured sentence conveys the two modes, wildcards, and a key performance warning without wasted words. The critical guidance is front-loaded.

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

  Completeness4/5

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

  For a read-only search tool with fully documented schema and helpful annotations, the description covers the main behaviors, modes, and the most important performance caveat. It does not detail return shape, but there is no output schema, and the description already provides enough to invoke the tool correctly.

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

  Parameters4/5

  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 still adds value by introducing wildcard usage and explicitly tying query/type narrowing to performance, which complements the schema's parameter documentation.

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

  Purpose4/5

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

  The description clearly states the tool finds ABAP objects by name pattern or lists consumers in where_used mode, with a specific resource and verbs. It does not explicitly differentiate from sibling tools like abap_read, 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.

  Usage Guidelines4/5

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

  The description gives clear usage context: use mode=objects for name-pattern search and mode=where_used for consumer listing, plus practical guidance to narrow by type/query first due to latency. It does not mention explicit alternatives or when not to use the tool, so not a 5.

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

• abap_readA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds meaningful behavioral context beyond annotations: it returns an etag, output is capped around 15k tokens, and there is a recommended strategy for large objects. This goes beyond what the schema or 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.

  Conciseness5/5

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

  The description is two tight sentences plus an example, with the core purpose first, then key behavioral constraints, then a usage tip. No filler or repetition of schema details.

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

  Completeness4/5

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

  Given the tool's complexity (14 parameters, no output schema), the description covers the essential operational facts: what is read, the etag return, the token cap, and how to handle large objects. It does not detail every parameter or output shape, but those are largely covered by the rich input schema, and the description gives enough for correct selection and initial invocation.

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

  Parameters4/5

  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 value beyond the schema via a concrete example showing how to fill 'object' and 'type' ('ZCL_FOO', 'CLAS/OC'), and it links outline/method/offset to large-object handling. This extra context helps disambiguate parameter usage.

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

  Purpose5/5

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

  The description uses a specific verb ('Read') with a concrete resource ('an ABAP object: source or pseudo-DDL') and gives an example object/type pair. This clearly scopes the tool and distinguishes it from sibling tools like abap_search or abap_debug by identifying it as the read operation for ABAP source-like content.

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

  Usage Guidelines3/5

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

  The description provides useful in-tool guidance ('use outline/method/offset for large objects') and an example, but it never explicitly states when to prefer abap_read over sibling tools, nor does it describe exclusions or alternative options. Usage guidance is implied rather than explicit.

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

• abap_serviceA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• abap_transportA
  4.3/5.0
  Behavior4/5

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

  Annotations already mark the tool as not read-only and destructive. The description adds useful behavior beyond that: reads are always permitted, mutations are gated by write allowlists, and deletion is among the dangerous operations (echoing the request number to arm delete is covered in 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.

  Conciseness5/5

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

  Two compact sentences with the operation list front-loaded and no filler. The write-allowlist constraint and release-tool routing each earn their place and are expressed economically.

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

  Completeness3/5

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

  For an 8-operation tool with no output schema, the description does not say what each operation returns (e.g., whether 'check' returns a boolean, what 'list' returns, or what 'users' shows). It also leaves 'write allowlists' undefined. Parameter mappings are thorough, but response/behavior expectations remain partly implicit.

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

  Parameters4/5

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

  The schema descriptions already cover all parameters in detail, including which operation each parameter is required for. The tool description adds value by enumerating the allowed operation values and disambiguating 'check' as 'does an object need a transport?', which is essential because the shown schema does not define an 'operation' property.

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

  Purpose5/5

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

  The description names a specific verb and resource ('Inspect and manage CTS transport requests') and enumerates the exact operations: list, show, check, users, create, addUser, setOwner, delete. It also clearly routes release work to a separate tool, abap_transport_release, which distinguishes it from a likely sibling.

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

  Usage Guidelines4/5

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

  It gives clear operating context: reads are always allowed, mutating operations obey write allowlists, and release is not part of this tool. It does not exhaustively compare against all sibling tools like abap_read or abap_search, but the transport-request domain plus release exclusion is enough to guide selection in most cases.

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

• abap_bopfA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• abap_open_urlA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• abap_journalA
  4.7/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• abap_dumpsA
  4.8/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.