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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description adds meaningful behavioral context beyond that: release-specific content matching this system, fixed EN language, HTML-to-text formatting approximation, and the hit-list behavior for broad queries. 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 well-structured with Args, Returns, Examples, and Notes. The opening sentence immediately communicates the tool's purpose, and every section provides useful operational detail without 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?

There is no output schema, so the description compensates by explicitly listing the return shape and fields. It also covers the two-step navigation pattern, broad-query behavior, language constraint, release correctness, and text-format limitations, giving an agent enough context to invoke the tool and interpret results correctly.

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

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

Schema coverage is 100%, so the schema already documents all four parameters. The description adds extra semantics by explaining the query-vs-uri relationship, giving concrete example values like 'LOOP AT GROUP BY' and 'ABAPSELECT', and advising to follow links for depth instead of raising max_chars. This goes beyond the schema's field-level 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 first sentence states a specific verb and resource: look up the system's own ABAP keyword documentation (F1 help, release-correct for this system). It clearly distinguishes this from generic web documentation or other ABAP tools by emphasizing the system-local, release-correct scope.

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

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

The description gives a clear workflow: query for a keyword, then follow a returned link's uri to navigate to sub-topics. It also advises not to raise max_chars too far and instead follow links, and it explains that broad keywords return hit lists. It does not explicitly contrast with sibling tools, but the usage context is concrete and actionable.

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

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

Annotations already mark this as destructive and non-read-only, and the description reinforces this by explicitly saying it MODIFIES the SAP system. It adds valuable behavioral detail: activating related objects together resolves cross-dependencies, errors are returned as messages with type 'E', and 'activated' is true only when no error messages exist. This exceeds the minimal annotation signal without contradicting 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?

The description is well-structured with clear sections for arguments, return values, examples, and error handling. Each section is concise and earns its place, and the most important warning about modifying the system is front-loaded in the first line.

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 appropriately documents the JSON return structure, error semantics, and an example. The only minor gap is a slight ambiguity between 'Returns (json)' and the default response_format of 'markdown', which could confuse an agent about the default response shape. Overall, the tool is callable with the information provided.

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 value beyond the schema by explaining that activating related objects together resolves cross-dependencies, providing a natural-language-to-object mapping example, and clarifying the semantic meaning of response_format. This is meaningful supplementary guidance rather than repetition.

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: 'Activate one or more inactive ABAP objects.' It further clarifies the operational effect by stating 'This MODIFIES the SAP system (makes the working version live),' which clearly distinguishes it from read-only sibling tools like sap_get_source or sap_search_objects.

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

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

The intended use case is implied through 'inactive ABAP objects' and the example, but the description does not explicitly say when to prefer this tool over alternatives such as sap_syntax_check, sap_create_object, or sap_list_inactive. No exclusions or alternative routing are provided, so the guidance is adequate 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses a non-obvious server-side side effect: each run records an ATC worklist that is harmless and reused per check variant. It also warns that large objects can exceed SAP_TIMEOUT_MS and recommends checking one object at a time, which is valuable behavioral context not available from 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 front-loaded with the purpose, then organized into input options, return format, examples, and notes. It is long but justified by seven parameters and no output schema; however, a few 'Args' lines repeat schema information, preventing a perfect conciseness score.

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 present, the description fully documents the JSON return shape, priority semantics, worklist side effect, timeout behavior, response_format options, and example parameter mappings. An agent has everything needed to select inputs and interpret results 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 baseline is 3. The description adds helpful examples and the either/or grouping of object_uri vs object_type+object_name, but it largely restates the schema's existing parameter descriptions, defaults, and preconditions rather than contributing substantial new parameter-level 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 opens with a specific verb and resource: 'Run an ATC (ABAP Test Cockpit) check on an ABAP object and return the findings...' and ties it to the workflow trigger 'before releasing a transport.' This clearly distinguishes it from sibling tools like sap_syntax_check, sap_run_unit_tests, and sap_release_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?

It gives explicit context for when to use the tool: before releasing a transport, and it explains the two input modes (object_uri vs object_type + object_name) with examples. It does not explicitly name when not to use it or point to a specific alternative tool, so it stops short of full exclusion guidance.

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

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

Annotations already mark destructiveHint=true and readOnlyHint=false, and the description adds autocommit/rollback behavior, ABAP error-type handling, and a warning about creating/changing/deleting business objects. No contradiction exists; the description significantly enriches the annotation profile.

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

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

The description is well-structured with the warning first, followed by args, return format, and an example. Each section contributes, though the Args section partially duplicates schema parameter descriptions. Overall it is efficient and front-loaded.

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

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

For a complex mutation tool with no output schema, the description explains the return JSON structure including the committed flag, RETURN table entries, and transaction outcomes. It is sufficiently complete for an agent to invoke the tool correctly and understand side effects.

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 the constraint that bapi_name must be RFC-enabled and provides a concrete example mapping 'Create a purchase order' to BAPI_PO_CREATE1, which adds practical guidance 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 specifies the verb 'Call' and resource 'BAPI function module', and clearly highlights commit/rollback semantics. It does not explicitly distinguish from sibling sap_rfc_call, but the BAPI-specific transaction handling makes the purpose unambiguous.

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

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

The description includes a warning to use only in development/sandbox unless certain of the effect, which is useful context. However, it does not state when to choose this tool over alternatives like sap_rfc_call or sap_read_table, nor does it provide any when-not conditions.

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 it read-only, idempotent, and non-destructive; the description adds behavior beyond that by specifying the JSON response shape and node type taxonomy. There is no contradiction with the annotations, and the examples reinforce safe 'browse' usage.

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 purpose, then compactly covers inputs, return shape, and examples. The Args section is somewhat redundant with the schema, but the overall length is justified by the useful return-shape and type details.

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

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

With no output schema, the description compensates by documenting the returned object and node list. The only ambiguity is that it says 'Returns (json)' while response_format can default to markdown, but the examples and return structure still give an agent enough to call it correctly.

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

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

Schema coverage is 100%, so the schema already documents both parameters with examples and defaults. The description's Args list and examples add little beyond the schema, meeting the baseline but not exceeding it.

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

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

The description opens with a specific verb and resource: 'List the repository objects and sub-packages inside an ABAP package.' This clearly identifies the tool's scope and differentiates it from global search or source-retrieval siblings like sap_search_objects and sap_get_source.

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 states when to use the tool: 'exploring what's in a package before making changes or doing an audit.' It does not explicitly name alternatives or exclusion conditions, so it stops short of the strongest guidance, but the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description adds valuable behavioral detail beyond those: it performs a handshake, reads the discovery document, and maps errors (401, 404, TLS) to config problems. This gives an agent a clear model of what happens when the tool is called.

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

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

The description is well-organized with clear sections for purpose, arguments, return value, usage, and error handling. It is thorough but not verbose, and the core purpose is front-loaded.

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

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

For a simple one-optional-parameter tool with rich annotations, the description covers invocation, return shape, usage timing, and error interpretation. Without an output schema, documenting the JSON return structure is especially helpful and makes the description 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% and the single parameter already has a clear enum and default in the schema. The description repeats the response_format options without adding new semantic meaning, so 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?

The description states a specific verb ('Verify connectivity and authentication') and a specific resource ('configured SAP S/4HANA system via ADT'). It also describes the mechanism (CSRF/session handshake, ADT discovery document), which makes the tool's role clear and distinguishable from sibling SAP 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 says to use this tool first to confirm environment configuration and ICF service availability, and gives a natural-language trigger ('Can you connect to SAP?'). It does not explicitly contrast it with related siblings like sap_rfc_ping, so it earns a 4 rather than 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 indicate this is not read-only and not idempotent, and the description adds concrete behavioral detail: the object must not already exist, it is empty and inactive after creation, and function modules cannot be created directly. This is meaningful 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 well-structured with Overview, Args, Returns, Examples, and Notes, and it is front-loaded with the key purpose and workflow. It is slightly long because the Args block duplicates schema details, but each section still contributes.

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 6 parameters and no output schema, the description includes the return shape, default and required parameter rules, examples, and important workflow caveats. An agent has enough information to call the tool correctly without needing extra documentation.

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 description is not required to compensate for missing parameter docs. It adds value with natural-language examples, the package/transport conditional, and the '$TMP' vs Z-package distinction, though some of this restates schema descriptions.

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

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

The description states a specific verb ('Create') and resource ('ABAP repository object'), lists the allowed object types, and clarifies it is the creation step separate from sap_write_source and sap_activate. This clearly distinguishes the tool from its siblings without opening the schema.

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

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

The description explicitly explains the workflow: the object must not already exist, then sap_write_source adds source, and sap_activate makes it live. It also handles the function-module edge case by directing users to create a function_group first, so an agent knows exactly when and how to use the tool versus 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 (readOnlyHint=false, idempotentHint=false) correctly imply a mutating, non-idempotent operation. The description adds behavioral context: the description parameter is 'shown in SE09/SE10', the return value is a JSON object with specific fields, and the returned number is expected to be passed to downstream tools. This goes beyond 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 well-structured into purpose, arguments, return value, and examples. Every sentence provides useful information without redundancy, and the practical usage example is front-loaded near the end for quick comprehension.

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

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

With no output schema, the description clearly documents the return JSON structure and how to use the returned transport number. It also explains where the description parameter appears (SE09/SE10). This is sufficient for correct invocation, though it does not cover potential error conditions or prerequisite permissions.

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 all parameters with full coverage, including enums, defaults, and descriptions. The tool description adds only an illustrative example (natural-language request to description string) and repeats the downstream usage, which is helpful but not necessary.

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 new workbench or customizing transport request.' It also distinguishes this from sibling tools by specifying the return value used in sap_write_source, sap_create_object, or sap_delete_object, making its purpose unambiguous.

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

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

The description gives clear context: create a transport request, then use the returned number as the transport parameter for subsequent write/create/delete operations. It also provides a natural-language example, but it does not explicitly state when not to use this tool (e.g., when listing or releasing transports with sibling tools).

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

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

Annotations are minimal (readOnly=false, idempotent=false, destructive=false), so the description carries the disclosure burden — and delivers. It flags a protocol change ('the old attach to a terminal/session id had no counterpart in the ADT protocol'), explains the trap-and-freeze side effect on the user's work process, notes sessionId is a server-local handle that 'does not survive a server restart,' and documents 409 conflict behavior including automatic clearing of crashed listeners. Nothing contradicts the annotations; the destructive take_over path is explicitly 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?

Well-structured with labeled sections (workflow, args, returns, error handling) and the core purpose front-loaded in the first sentence. The workflow and error-handling sections earn their length for a multi-step lifecycle tool, though the Args section partially duplicates a schema that already covers all parameters at 100%.

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 documents the return shape explicitly — '{ sessionId, state: LISTENING, user, mode, message }' — and explains sessionId semantics. It covers both error paths (409 conflict with take_over recovery; single-session constraint), the mandatory detach step, and the prerequisite of running code as the target user before sap_debug_wait. Nothing essential is missing for a tool with this complexity.

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

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

Schema coverage is 100% and the schema descriptions are already rich — mode's 'reference-only, not verified on this system' caveat and user's 'freezes THEIR session — only do it with their knowledge' warning are in the schema itself. The description's Args section mostly echoes this, adding only the historical context that 'terminal_id' is gone and restating defaults. Baseline 3 is correct 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?

First sentence uses a specific verb and resource: 'Open a debug session handle and confirm this server may listen for a user's execution.' It explicitly differentiates from the nearest sibling — 'sap_debug_wait is what actually registers the listener and blocks' — and the numbered workflow positions this call as step 1 of a 6-step debug lifecycle. An agent can distinguish it from sap_debug_wait, sap_debug_detach, and the other debug-family tools 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?

Provides an explicit numbered workflow (attach → set breakpoint → execute as user → wait → inspect → detach) that states exactly when this call runs and in what order. It names the alternative explicitly, gives conditional guidance for conflicts ('Re-run with take_over=true to seize it'), and warns 'One debug session at a time: detach the current one first.' Usage context and exclusions are both 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 goes well beyond the annotations, disclosing the exact ordered cleanup steps, best-effort semantics, individual reporting, the fallback of dropping an ABAP session, and the meaning of verified=false. It also reinforces the idempotentHint annotation with concrete detail about repeated failed calls.

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 detailed but well-organized: leading warning, numbered cleanup steps, argument list, return summary, and idempotence note. Every sentence earns its place, and critical information is front-loaded in the first line.

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 cleanup tool with no output schema, the description fully explains return fields, failure semantics, retry behavior, and side effects. It even covers the preconditions implicitly by referencing the session_id from sap_debug_attach and the stateful debug connection.

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 fully documents both session_id and response_format. The description's Args list adds little beyond what the schema provides, though it does reinforce the required nature of session_id and the output format choices.

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: 'End a debug session and leave nothing behind on SAP.' It clearly distinguishes the tool from its debug siblings by focusing exclusively on teardown and cleanup, and the detailed cleanup list removes any ambiguity about what detach does.

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

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

It explicitly states 'ALWAYS call this when done,' giving an unambiguous trigger condition, and explains the real-world harm of not calling it. It also provides idempotence guidance, saying it is safe to call twice and safe on an already-ended session, which covers the main edge cases for usage.

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

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

Annotations already mark the tool read-only and idempotent; the description adds important behavioral context: variable IDs are resolved, not expressions, and scope determines visibility. It also documents the response shape. The only minor weakness is that 'Returns (json)' is not fully reconciled with the response_format parameter, but this does not undermine the behavioral disclosure.

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 action, followed by a high-value limitation note, compact arg summary, return shape, and targeted error handling. Every sentence earns its place; no fluff or duplication beyond the concise Args list.

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 supplies the return shape, error behavior, and a route to the correct sibling. The dependency on a previous sap_debug_attach session is covered by the schema's session_id description. The slight return-format ambiguity is a minor issue against an otherwise complete definition.

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 parameter meaning is mostly carried by the schema. The description adds value by clarifying that expression means an ABAP variable ID rather than a computed expression and by giving concrete examples, slightly exceeding the schema's 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?

States a specific action ('Read one variable at the current stop point') and distinguishes itself from the sibling sap_debug_variables by noting it does not list all locals. It also clarifies that the tool resolves variable IDs, not computed expressions, despite the title's word 'Evaluate'.

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?

Gives clear when and when-not guidance: use for one specific variable at the current stop point; explicitly advises using sap_debug_variables when a variable is not in scope. Also warns against computed expressions because no evaluate-expression service exists.

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 readOnly/idempotent annotations, the description explains state semantics (LISTENING, STOPPED, RUNNING, TIMEOUT, etc.) and discloses the key behavioral detail that only a STOPPED debuggee triggers an SAP call, otherwise the response is served locally. This materially helps an agent anticipate tool behavior.

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

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

The description is compact, front-loaded with the core purpose, and structured clearly: purpose, args, return shape, states, and server-behavior note. Every sentence adds necessary information 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?

With no output schema, the description compensates by fully specifying the JSON return shape, the required session context, and the meaning of every possible state. An agent has enough information to invoke this tool correctly for state inspection and interpret the 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 coverage is 100%, with both parameters already documented in the input schema, including the session_id provenance and response_format enum/default. The description only repeats the parameter names and adds no additional meaning, so it holds at the 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 clearly states a specific verb and resource: 'Report the state of a debug session, plus a fresh call stack when a debuggee is stopped.' This distinguishes it from sibling debug tools like sap_debug_step or sap_debug_wait by focusing on observation rather than 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 gives useful context like 'Only STOPPED calls SAP; the other states are answered from this server,' which helps an agent understand the cost/behavior of the call. However, it never explicitly says when to prefer this tool over alternatives such as sap_debug_wait or sap_debug_step, so the selection guidance is more implied 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?

The description goes well beyond the annotations by disclosing blocking behavior, the dedicated step timeout versus the global timeout, the fact that 'continue' can block for minutes, and the debuggee state transitions (STOPPED, ENDED, RUNNING). It also notes that the listener stays armed after ENDED, which is important hidden behavior.

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

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

The description is long but every sentence earns its place: preconditions, timeout behavior, argument summary, and return-state semantics. The most important operational information is front-loaded, and the return-state explanation is clearly structured.

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

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

There is no output schema, so the description's detailed explanation of the returned JSON and state values is essential and sufficient. It explains all possible states, the timeout scenario, and follow-up actions, making the tool safely callable even though it is asynchronous and potentially long-running.

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 every parameter including the command enum meanings, session_id provenance, and response_format default. The description mostly restates parameter names without adding significant semantic value beyond what the schema provides.

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

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

The description uses a specific verb and resource: 'Move the stopped debuggee' with an explicit enumerated command list. It clearly distinguishes this tool from siblings like sap_debug_wait, sap_debug_state, and sap_debug_detach by the action it performs.

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 states a hard precondition ('Requires state='STOPPED'') and explains how to proceed in each resulting state, including concrete alternatives such as sap_debug_wait to catch the next trap, sap_debug_state to check a running debuggee, and sap_debug_detach to finish. This gives the agent clear routing guidance.

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

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

Annotations already mark it read-only/idempotent/non-destructive, and the description adds concrete behavior: returns the JSON shape, variable kind enum, truncation marker, tableLines reporting, and the 'No debuggee attached' error path. This materially enriches the annotation-only picture.

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?

Purpose, prerequisite, args, return format, and error handling are each in clearly tagged sections with no filler. Front-loads the intent in the first sentence.

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 supplies a return contract including variable fields and kind values, plus the common failure mode. This is sufficient for an agent to invoke it and interpret the 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 coverage is 100%, so the parameters are fully documented structurally; the description mostly restates them. It does add the '@ROOT' hierarchy detail for omitted names, but otherwise adds little 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: 'Read ABAP variable values at the current stop point.' This clearly identifies it as a read-only inspection tool among the debug family, though it does not explicitly contrast itself with sap_debug_eval's expression evaluation.

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 states the precondition: 'Requires state='STOPPED' (a debuggee attached by sap_debug_wait).' Error handling reinforces when it is valid ('run the code and call sap_debug_wait first'). It gives clear context but no explicit when-not-to-use or sibling 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 the sparse annotations, the description candidly discloses side effects and hazards: registration persists as a side effect, the listener remains armed on SAP across timeouts until sap_debug_detach deletes it, the call performs the attach itself, and a STOPPED debuggee is a real frozen user session that SAP may kill. It also documents the server-side long-poll behavior and conflict error. 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 organized with a crisp opening, a behavior-change note, structured Args and Returns sections, state-by-state guidance, and an error-handling note. Every block adds operational value; the length is justified by the tool's stateful, side-effecting 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 stateful long-poll with no output schema, the description covers return fields, all three states, cleanup via sap_debug_detach, and conflict handling. The only notable gap is that it says 'Returns (json)' while response_format defaults to markdown in the schema, leaving how the markdown output is shaped slightly unclear.

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 meaning by explaining session_id origin, timeout as a client-side cap with post-timeout behavior, and poll_interval_ms as ignored compatibility. It does not repeat in depth what response_format does, but that is already fully covered by 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 leads with a specific verb and resource: 'Register the debug listener and block until the watched user's code traps on a breakpoint — then attach to it and return the stop position and call stack.' It clearly differentiates this from other debugger tools by describing a blocking long-poll and its attach/return behavior, and it names sap_debug_detach as the complementary cleanup call.

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 operational context: block until a breakpoint traps, handle TIMEOUT by calling again, handle CANCELLED by re-attaching, and release STOPPED debuggees promptly. It does not explicitly distinguish when to use this wait tool versus alternatives such as sap_debug_state, but the context is sufficient for most selections.

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 reveals important behavioral details: the no-ids path sends an 'empty full-set sync' that clears server-side breakpoints even if this server no longer remembers them, and 'deleted' counts only what this server knew about. This significantly helps an agent predict side effects and interpret results.

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

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

The description is well-structured with a lead sentence, labeled args, return shape, examples, and notes. Every section adds operational value, and the most important behavioral caveat about the full-set sync is highlighted with a concrete example.

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

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

There is no output schema, but the description provides the return shape '{ deleted, message }' and explains the semantics of 'deleted'. It covers both invocation modes, the side-effect difference between them, and practical guidance for reliable cleanup, so an agent has enough context 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 coverage is 100%, so the baseline is 3. The description adds meaning by explaining that ids are 'structured ids from sap_list_breakpoints / sap_set_breakpoint' and by giving a concrete example id format. It also reinforces the omitting behavior, making the parameter semantics easier to apply correctly.

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

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

The description states a specific verb and resource: 'Delete specific external breakpoints, or clear the whole external breakpoint set.' It clearly covers both modes of the tool and distinguishes it from related breakpoint tools by focusing on deletion rather than listing or setting.

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 examples provide clear usage scenarios: 'Clear all my breakpoints' maps to omitting ids, and 'Delete that breakpoint' maps to providing a structured id. It also explains when the no-ids path is preferable for a complete cleanup. It does not explicitly contrast with sap_set_breakpoint or sap_list_breakpoints as alternatives, but the intended usage 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 flag destructiveHint=true, and the description expands this with concrete behaviors: the tool locks and deletes the object, records it in a transport when provided, cannot be undone except via restore, and deleting a function group removes all function modules. This is exactly the side-effect disclosure 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?

The description is front-loaded with the permanent-destruction warning, then organized into Args, Returns, Examples, and Notes. Every section contributes essential behavioral or invocation information without repetition.

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

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

For a destructive mutation tool with no output schema, the description is unusually complete: it states return fields, side effects, transport requirements, preconditions, and examples. An agent can safely determine when and how to invoke it.

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 base expectation is 3. The description adds value with natural-language examples mapping phrases to object_type/object_name/transport, and it restates the non-local transport requirement. The only minor weakness is that 'Returns (json)' is slightly ambiguous given response_format defaults to markdown.

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: 'Delete an ABAP repository object. This PERMANENTLY REMOVES the object from SAP.' This unambiguously distinguishes the tool from siblings such as sap_create_object, sap_write_source, and sap_activate.

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 practical usage context: transport is required for non-local objects, sap_where_used should be run first, and function-group deletion has cascade effects. It does not explicitly name when-not-to-use alternatives, but the destructive operation and prerequisites make the intended use 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 readOnly/openWorld/idempotent/non-destructive, so the bar is lower, but the description adds substantial value beyond them: the underlying resource, on-premise upgrade-stability semantics, and — most importantly — which outcomes are expected rather than failures (releasable=false for programs/includes, NOT_RELEASED on Z objects as the normal state). The return JSON shape and the full state enum are enumerated, giving the agent a complete behavioral model.

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

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

Well organized with clear sections (purpose, supply modes, args, returns, examples, notes) and front-loaded with the core purpose and distinguishing behavior. There is mild redundancy — the C1 contract is explained twice and the Args block restates the either/or rule — but the length is largely justified by the tool's conceptual nuance and the absence of an output 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?

Since no output schema exists, the description fully carries the return-value documentation, including the JSON shape and every state enum value. It covers both input modes, the response_format switch, edge-case semantics for non-releasable types, and points to the sibling alternative for the same data. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds a real layer on top by grouping the five parameters into two mutually exclusive supply modes (object_uri OR object_type+object_name with conditional function_group), noting the URI provenance from sap_search_objects, and mapping natural-language queries to concrete parameter values in the examples. It complements rather than repeats 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 ('Check whether an ABAP object is a released API') against a concrete resource (the ADT apireleases resource), and explains the C1 compatibility contract in the opening sentence. It differentiates from siblings by noting the endpoint resolves object URIs and non-releasable types itself, unlike sap_read_table on ARS_W_API_STATE. An agent can separate this from its 48 siblings without opening the schema.

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

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

Provides concrete usage triggers via three natural-language examples ('Is IF_OO_ADT_CLASSRUN a released API?', 'Can I use CL_GUI_ALV_GRID in cloud development?'), which helps an agent recognize when the tool applies. It explicitly names the alternative (sap_read_table on ARS_W_API_STATE) and states when this endpoint is preferred, plus gives the decision rule between object_uri and object_type+object_name. It also sets expectations on which outcomes are normal rather than errors.

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 it as read-only and idempotent, and the description adds meaningful behavioral detail: it reads only the definition, not where checks occur; the activity catalog is global and fetched separately; partial failures surface as activitiesError; the 'raw' field signals unexpected release-specific structures.

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 organized into clear sections (Args, Returns, Examples, Notes) and is well front-loaded with purpose. It is somewhat long and partly duplicates schema parameter descriptions, but every section contributes meaningful context not found elsewhere.

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?

Without an output schema, the description compensates by documenting the return structure, optional activities/activitiesError keys, the raw field caveat, and guidance for combining with other tools. This is complete enough for an agent to call the tool correctly and interpret unusual results.

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 all three parameters at 100%, but the description adds value with usage examples that tie user intents to parameter settings, such as include_activities=true for interpreting ACTVT values. It also clarifies the large size and global nature of the activity catalog.

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 ('Read') and resource (authorization object definition via SU21/ADT) and names the concrete outputs: description, object class, and fields. This clearly distinguishes it from sibling tools like sap_sql_query or sap_get_transaction.

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

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

Explicitly says when to use it for authorization audits and names companion tools (sap_get_transaction, sap_sql_query) for complementary lookup scenarios. The examples also map natural-language questions to concrete parameter choices.

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, idempotentHint=true, and destructiveHint=false, which the description complements. It adds behavioral context beyond annotations: the output may fall back to raw when parsing yields nothing, and the tool is open-world (try spot name). No contradictions.

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 organized clearly: a one-sentence purpose, Args, Returns, Examples, then Notes. It is front-loaded with the core action and distinguishes from siblings early. Every sentence adds value—no repetition or filler—and the structure makes it easy to scan.

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 fully equips an agent to call the tool correctly: it defines return shape (even without a formal output schema), provides examples, notes the raw fallback, and directs to sap_get_source for source code. Given the read-only metadata nature and 100% parameter schema coverage, nothing important is missing.

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

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

The schema covers both parameters with descriptions and examples (100% coverage), giving a baseline of 3. The description adds realistic example values in the Examples section and clarifies that response_format defaults to markdown in the schema, but the description does not restate the parameter details. These real-world examples help an agent pick appropriate values, so a 4 is 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?

States a specific verb ('read') and resource ('BAdI definition') and enumerates the contents (interface, active implementations). The examples clarify real use cases and the name distinguishes it from sap_get_source, which reads implementation source. The purpose is unambiguous and well-defined.

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

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

Explicitly says 'This reads definition metadata only. Use sap_get_source to read the actual implementation class source,' naming the alternative and the condition. Also advises trying the spot name if the BAdI name isn't found. This is clear, actionable guidance on when to use and when not to use this tool.

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

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

Beyond the annotations, the description adds meaningful behavioral details: it is read-only, release-independent, accesses DDIC repository tables, and behaves differently by object type. It also discloses error handling, such as empty fields indicating a non-existent or inactive object, which exceeds what annotations alone 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 well-structured with clear headers, concise bullet points, and an immediately useful summary sentence up front. Each section—types, args, returns, examples, error handling—earns its place without redundant 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?

With no output schema, the description compensates by fully specifying the return shape: { objectType, objectName, detail, rawSource? }. It covers all object types, all parameters, examples, and error scenarios. An agent has enough information to select and invoke this tool correctly in the vast majority of cases.

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 all parameters at 100%, so the baseline is 3. The description adds value by enumerating what each object type returns, providing concrete examples mapping to values, and clarifying result details. This goes beyond simply restating the schema but does not dramatically deepen parameter understanding.

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

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

The description opens with a specific verb and resource: 'Inspect a Data Dictionary object's definition.' It then details distinct behaviors for table, structure, dataelement, domain, and cds, making it unambiguous what this tool does and effectively distinguishing it from sibling tools like sap_get_source or sap_read_table.

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: any time a DDIC object's definition or metadata is needed. It includes natural-language examples that map user requests to parameters. It does not explicitly state when not to use it or name alternatives, 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 already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond that: it documents the full returned JSON structure, explains that 'text' is the complete ST22 report, and discloses the 404 housekeeping/reorganization failure mode. There is no contradiction between the description and 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 compact and well-structured with separate sections for summary, args, returns, examples, and error handling. Everything included earns its place, and the purpose is front-loaded in the first sentence.

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?

There is no output schema, so the description compensates by explicitly listing the JSON return fields and describing the content of 'text'. It also explains how to obtain dump_uri and how to handle a 404, giving an agent enough context to invoke the tool correctly even without prior knowledge.

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 both parameters fully, including the dump_uri prefix, the encoded-space caution, and the response_format enum with default. The description mostly repeats the pass-through/verbatim idea and merely names response_format, so it adds little semantic value beyond the schema.

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

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

The description states a specific verb ('Read') and resource ('one ABAP runtime error (short dump) in full'), and distinguishes itself from the sibling sap_list_dumps by focusing on a single dump. It also anchors the workflow by saying the dump_uri comes from sap_list_dumps, so an agent can tell exactly what this tool does.

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

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

The description gives a clear usage pattern: call sap_list_dumps first, then sap_get_dump with the returned URI. The example and 404 recovery guidance reinforce when and how to use it. It does not explicitly state when not to use it, but the prerequisite and workflow make the intended usage 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, idempotentHint, openWorldHint, and non-destructive. The description adds a concrete return shape with optional fields (description?, language?, selfExplanatory?) and an example of how to locate a message by id. It does not mention error behavior or pagination, but the core read-only nature is clear. 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 compact and well-organized into summary, args, returns, and examples. It is under 150 words and every section adds value. The only minor repetition is the response_format name without a type, but the schema covers it.

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?

Though there is no output schema, the description provides a clear return shape and examples. It leaves open how the default 'markdown' response_format renders (the return shape is shown as json only) and does not address large message sets or not-found cases. Given the tool's simplicity and annotations, this is adequate but not fully 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% and both parameters are documented. The description adds example name values ('ZFI_MSGS', 'VR') and clarifies post-processing ('look for id='001''). It does not significantly expand on the response_format semantics, 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?

States it reads all messages in an ABAP message class (T100 content + metadata). The verb 'read' and resource 'ABAP message class' are specific and distinct from sibling tools like sap_get_text_elements. Examples clarify the exact object ('ZFI_MSGS').

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 shows example queries and how to map them to the 'name' parameter, which implies when to use it. However, it never explicitly contrasts this tool with alternatives or lists conditions where another sibling (e.g., sap_get_text_elements, sap_read_table) would be preferred. So usage guidance remains 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?

Beyond the readOnly/idempotent annotations, the description adds valuable behavioral detail: version records exist only when SAP created them, fresh $TMP objects may have none, and an unknown version returns the list of available numbers. This prevents misleading expectations without contradicting 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 with clear sections: Args, Returns, Examples, and Notes. The main purpose is front-loaded, and every section earns its place without redundant 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?

For a tool with no output schema, the description fully compensates by specifying the JSON return shape, covering both operation modes, providing examples, and documenting edge cases. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the dual-mode behavior of the version parameter ('omit to list revisions; supply to read that revision's source') and gives natural-language examples that map intents to parameter values.

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 starts with a specific verb+resource: 'List the version history (revisions) of an ABAP object, or fetch the source of a specific old version.' This clearly distinguishes sap_get_revisions from sap_get_source by emphasizing historical revisions versus current source, 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 concrete usage patterns with examples: when to omit version, when to supply it, and how to compare with sap_get_source. It does not formally state 'do not use for current source,' but the examples and notes make the intended use clear enough.

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

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

Annotations already declare read-only and idempotent behavior. The description adds meaningful limitations: it returns only flow logic, not the layout, and notes that 404 means the screen doesn't exist. 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 well-structured and information-dense. The core purpose is front-loaded, followed by concise parameter explanations, a useful example, and only two highly relevant notes. No sentence is wasted.

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?

Even without an output schema, the description specifies the exact return shape. It covers parameter usage, an example, a scope limitation, and an error condition. The tool is simple enough that this is a complete picture 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?

The input schema already describes all parameters with 100% coverage, including types, constraints, and examples. The description adds minimal extra meaning beyond restating the same information, so 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?

The description clearly states the tool reads the PBO/PAI flow logic source of a dynpro/screen, and explicitly distinguishes this from program source and the element list. This level of specificity makes the tool's purpose unambiguous and differentiates it from siblings like sap_get_source.

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 screens are separate from program source and that this tool returns screen ABAP, not the element list. This gives clear context for when to use it, though it does not explicitly name alternative tools such as sap_get_source.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond that: it specifies the JSON return shape, mentions the etag for concurrency-safe writes, and documents 404 error cases. This is meaningful transparency without contradicting 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 with Args, Returns, Examples, and Error Handling sections. It is front-loaded with the core purpose, and every section earns its place without redundant filler.

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

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

Given the absence of an output schema, the description fully compensates by defining the return object, explaining etag semantics, and documenting error conditions. Combined with strong annotations and full parameter schema coverage, nothing critical is missing for an agent to call this tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value with natural-language examples mapping 'Show me class CL_FOO' to parameters, clarifies that function_group is only required for object_type='function', and explains response_format choices. This goes slightly beyond the schema's own descriptions.

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

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

The description uses a specific verb and resource: 'Read the ABAP source code of a program, include, class, interface, or function module.' It clearly identifies the object types and the read-only nature, and the title 'Read ABAP Source' differentiates it from sibling tools like sap_write_source or sap_get_screen_source.

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 read-operation context with examples and error handling, so an agent can infer when to use it. It does not explicitly name alternatives or state when not to use it, but the read-only framing and sibling names make the intended usage obvious.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: texts come from the original master language pool (often German), unused kinds return empty lists, ddicReference indicates inherited selection texts, and the exact JSON return shape is documented.

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 Args, Returns, Examples, and Notes sections, each earning its place. It is longer than minimal, but every section conveys non-obvious information needed for correct use, and the core purpose is front-loaded.

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

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

Given there is no output schema, the description fully compensates by documenting the return shape, ID semantics, edge cases, language-pool behavior, and examples. An agent has enough information to call the tool correctly and interpret the result accurately.

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 all four parameters with 100% coverage, including enums, defaults, and illustrative object names. The description's Args section mostly restates the schema; the examples and notes add usage context but little new parameter-level 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 states a specific verb ('Read') and resource ('program's / class's / function group's text elements'), and enumerates the exact kinds of text elements returned. It is immediately distinguishable from sibling tools like sap_get_source and sap_set_text_elements.

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 examples mapping user questions to the right object_type and kind values, notes that unused kinds return empty lists rather than errors, and explicitly refers to sap_set_text_elements for writing texts back. This gives an agent clear routing guidance without relying on 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds substantial behavioral detail beyond that: CINFO is a bit field so multiple flags can coexist, 'program' is legitimately empty for parameter/OO transactions, authChecks are limited to TSTCA start checks, and short text is English-only returning no description if absent. These clarify real edge cases without contradicting 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 front-loaded with a precise summary, then organized into Args, Returns, Examples, and Notes. Each note addresses a non-obvious behavior or output nuance, and there is no filler or repetition beyond the minimal, useful Args line.

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?

There is no output schema, so the description carries the full burden of documenting return values, and it does so comprehensively: the full JSON shape, the transactionType enum, nested authChecks structure, and edge-case behaviors are all covered. With annotations covering safety/idempotency, nothing essential is missing for an agent to call this tool correctly.

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

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

The input schema has 100% description coverage, including tcode examples and case-insensitive behavior, and response_format's enum/default. The description's 'Args' section only restates the parameter names and terse meanings without adding anything beyond the schema, so the baseline of 3 applies; no additional parameter-level insight is contributed.

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: 'Read a transaction code's SE93 definition', and enumerates exactly what is returned (program/screen, transaction type, TSTCA checks, SM01 lock). It also distinguishes itself as the 'Core tool for authorization audits' and later contrasts code-level checks with sap_get_source and sap_where_used, so an agent can tell it apart from 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 explicit when-to-use context ('Core tool for authorization audits') and clear exclusions: authChecks are only SE93-maintained TSTCA start-of-transaction checks, not full program-level authority checks, and for those the agent is directed to 'use sap_get_source or sap_where_used'. Examples also demonstrate query intent with tcode='SE38' and tcode='VA01'.

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 flag destructiveHint=true, and the description adds specific behavioral context: immediate=true immediately starts an ABAP program, and jobCount/jobName can be used for SM37 monitoring. This goes beyond the structured annotation by explaining the side-effect timing and safe-use boundary, though it does not detail error or authorization behavior.

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

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

The description is front-loaded with the action and warning, followed by a compact arg list, return shape, and two examples. The only rough edge is the bare 'response_format.' line in the Args list, which adds some noise but no significant bulk.

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 five parameters and no output schema, the description covers the operation, side effects, safety warning, return JSON shape, and monitoring instructions. The schema fills in types, defaults, and constraints. It does not explain the immediate=false path in the description, but the schema's default documentation covers that, so nothing critical 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?

All five parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds value by explaining the role of job_name (visible in SM37), clarifying variant as optional, and giving concrete natural-language-to-parameter mappings in the examples, exceeding the schema's basic 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 first sentence, 'Create and schedule an ABAP background job via JOB_OPEN + JOB_SUBMIT + JOB_CLOSE,' names a specific verb, resource, and underlying SAP function modules. This clearly distinguishes it from siblings like sap_run_report (foreground execution) and sap_run_console.

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 an explicit when-not restriction: 'Only use in development/sandbox or when you are certain of the effect.' It also includes natural-language examples like 'Schedule ZMONTHLY_CLOSE now' to illustrate typical user inputs. It does not explicitly name alternative sibling tools, but the background-job semantics plus safety warning make the appropriate context 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?

The description discloses important behavioral traits beyond the readOnly/idempotent annotations: the list is client-side, SAP's own endpoint returns an empty body, Eclipse behaves the same way, and restart clears the server's local knowledge. It also explains the returned structure and gives a concrete cross-check method, providing rich 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?

The description is front-loaded with the core purpose and the critical 'IMPORTANT' caveat, then gives a compact return schema and a concrete example. Every paragraph earns its place, including the HTTP endpoint detail that supports the client-side claim. The structure is well organized and not 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?

Despite having no output schema, the description fully documents the return shape, field meanings, the special 'id' field used by sap_delete_breakpoints, and the limitation regarding restart and Eclipse-set breakpoints. For a read-only list tool with this complexity, nothing an agent needs to invoke it correctly or interpret its output is missing.

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

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

Schema description coverage is 100%, with the single optional response_format parameter clearly documented in the schema. The description adds an example of calling with no arguments and shows the JSON return shape, but it does not need to further explain the parameter semantics because the schema already fully covers them. 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 a specific verb ('List') and resource ('external (ADT) breakpoints set through this MCP server'), which distinguishes it from related tools like sap_set_breakpoint and sap_delete_breakpoints. It also clarifies the scope as client-side and server-local, leaving no ambiguity about what is being listed.

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 is explicit about when this tool is appropriate: it lists only breakpoints set by this server since startup, not Eclipse breakpoints or pre-restart breakpoints. It even gives an alternative approach (sap_sql_query on ABDBG_EXTDBPS) for cross-checking the server side, making the usage boundaries very clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower, but the description adds substantial behavioral context beyond that: the server returns a fixed page regardless of max_items, user filtering and max_items are applied to that page locally, and housekeeping jobs eventually remove old dumps. This is exactly the kind of non-obvious behavior an agent needs to know before calling.

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 organized into Args, Returns, Examples, and Notes, with the core purpose stated first. Every section adds distinct value: format defaults, return shape, concrete examples, and important behavioral caveats. It is longer than average but avoids redundancy and front-loads the most actionable details.

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

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

Even though there is no output schema, the description fully specifies the return JSON shape with field names and optional markers. It also covers pagination behavior, data retention, date format, default/max values, and how to chain into sap_get_dump. An agent has everything needed to decide when to call it and how to interpret the results.

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% for all five parameters, so the schema already documents formats and defaults. The description adds meaningful semantics on top: it clarifies that from_date/to_date are server-side filters while max_items and user are applied to the returned page, and that the URI may contain encoded characters and should be passed verbatim. This goes beyond what the schema descriptions state.

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?

Describes the exact operation: listing recent ABAP runtime errors (ST22 short dumps), including the fields returned (error ID, program, user, time, and URI). The title and description align, and the resource is unambiguous. It also distinguishes itself from sap_get_dump by pointing out that the URI is meant to be passed to that sibling tool, so an agent can tell listing from fetching.

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 usage context: examples show when to use date filters, max_items, and user filtering. The Notes explicitly explain that from_date/to_date are the only server-side filters and that max_items/user filtering happen client-side, which clarifies when to use which parameter. It doesn't explicitly say 'use sap_get_dump instead when you have a URI', but the return-URI note strongly implies the workflow.

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, so the description does not need to repeat those. It adds useful behavioral context beyond annotations: the user filter is applied client-side, and the return shape included fields such as uri, type, name, and transport.

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?

Description is well-structured with Args, Returns, Examples, and Notes, keeping each section to one or two lines. The first sentence immediately states the core purpose, and every sentence adds information without redundancy.

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

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

Since there is no output schema, the description supplies a JSON return contract with count and objects. It covers purpose, usage scenarios, examples, filter behavior, and the next step (sap_activate). For a tool with only two optional parameters, this is sufficiently complete.

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

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

Schema description coverage is 100%, so the schema already documents both user and response_format. The description adds meaningful nuance by explaining the user filter is client-side and by showing a concrete example (user='DEVELOPER') and a no-argument usage. Response_format is only name-dropped, but its enum and default in the schema cover it.

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

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

Description states 'List all inactive ABAP objects for the system (objects edited but not yet activated), with owner and transport.' This is a specific verb and resource with clear scope and definition. It also distinguishes itself from sibling tools like sap_list_transports and sap_activate by focusing on inactive objects awaiting activation.

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 provides when to use: 'Use to find leftovers before activating or transporting.' The description also points to sap_activate as the follow-up action. It does not explicitly rule out alternatives, but the purpose is specific enough that this is a minor 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?

The description goes well beyond the annotations by explaining response shape, status code meanings ('D'/'L' = modifiable, 'O'/'R' = released), parameter defaults, and a fallback behavior ('raw' XML returned when structured parsing yields nothing). This is valuable behavioral context that annotations alone 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 well-structured with clear sections (Args, Returns, Examples, Error Handling), and every sentence adds relevant information. The purpose is front-loaded in the first sentence, and the additional details are organized and scannable.

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

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

The description is complete for a read-only listing tool with no output schema: it explains return shape, status codes, defaults, an example invocation, and error-handling fallback. It also connects to a downstream tool (sap_write_source), giving the agent enough context to use the result 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?

Input schema coverage is 100%, and schema descriptions already document both 'user' and 'response_format' with defaults. The description mostly restates this information, though it adds a small amount of context through examples and the note about defaulting to SAP_USER. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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

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

The description states a specific verb ('List'), a specific resource ('workbench/customizing transport requests (and their tasks) owned by a user'), and the service used ('via the CTS ADT service'). It clearly distinguishes this from sibling tools like sap_create_transport and sap_release_transport by focusing on listing existing transports.

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 usage context with the example 'What transports do I have open?' and notes that the returned request number can be used as 'transport' for sap_write_source. It does not explicitly name alternative tools or state when not to use it, but the listing intent is clear enough for an agent to 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?

Annotations already mark this readOnly/idempotent/non-destructive, and the description adds meaningful behavioral context: feed_path must start with /sap/bc/adt/, max_items is enforced client-side because some feeds ignore the server limit, and summary is a best-effort 500-character plain-text rendering of potentially escaped HTML. 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 organized into intro, args, returns, examples, and notes, with the most important purpose and sibling distinction front-loaded. Each note covers an edge case or constraint that matters for correct invocation, and there is no filler or redundant restating beyond what is useful for quick reference.

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?

Because there is no output schema, the description fills the gap by specifying the JSON return shapes for both listing and reading modes. It also covers response format semantics, path constraints, limit behavior, and alternatives, making it complete enough for an agent to invoke the tool correctly in both modes.

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 all three parameters with types, defaults, and constraints, so the baseline is 3. The description adds value by clarifying that feed_path must be an ADT href, that max_items applies only when reading and is enforced locally, and that response_format='json' yields the full structure. This extra nuance justifies a 4 rather than a 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 opens with a specific verb+resource: 'List the ADT feeds available on this system... or read one feed's entries.' It also distinguishes itself from a sibling by directing short dumps to sap_list_dumps. The dual-mode behavior is stated upfront, so an agent knows exactly what this tool does.

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

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

The description gives explicit when-to-use guidance: omit feed_path to list feeds, pass an href to read one, and prefer sap_list_dumps or sap_get_dump for ABAP runtime errors. It also states the tool is not a general HTTP proxy and clarifies the path prefix requirement, leaving little 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?

Annotations already indicate read-only/idempotent behavior, and the description adds meaningful behavioral details beyond them: authorization is enforced by SAP (S_TABU_*), 403 means missing display authorization, and large tables should be queried with fields/where/max_rows. This is exactly the kind of context that helps an agent invoke the tool safely.

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 organized into clear sections (Args, Returns, Examples, Notes & Error Handling) and front-loads the core purpose. Every section earns its place: examples clarify usage, the returns block compensates for the missing output schema, and the notes handle real failure modes without excessive verbosity.

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 table-reading tool with no output schema, the description is remarkably complete: it explains return structure, authorization behavior, error meaning, large-result handling, parameter options, and provides concrete examples. An agent has everything needed to select and call this tool correctly.

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

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

The input schema already covers all parameters at 100% with descriptions, so the baseline is 3. The description adds value through concrete examples (e.g., 'T001', 'BKPF', where-clause patterns), the single-quote literal rule, and the max_rows range reminder, which go beyond the schema's dry parameter 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 states a specific verb and resource: reading the contents of any authorized table or view via ADT SQL Data Preview. It clearly identifies itself as the primary tool for reading customizing tables and business data, though it does not explicitly name or contrast a sibling like sap_sql_query.

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: it is the primary reader for table contents and business data, with examples mapping natural language requests to concrete table/where-clause combinations. It lacks explicit exclusions or named alternatives, but the intended use cases are well conveyed.

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 warning that releasing is IRREVERSIBLE and that the request becomes read-only provides concrete behavioral consequences beyond the destructiveHint annotation. It also discloses that the operation starts a transport release job and that the response may include a jobId, which is meaningful context for an agent.

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 well organized: purpose, warning, args, returns, and example. The irreversible warning is front-loaded, and every sentence adds value without unnecessary repetition.

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

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

With no output schema, the description provides a JSON return shape, covers the irreversible side effect, explains where the transport number comes from, and includes an example. It could go slightly further on what `jobId?` implies for tracking, but the description is still sufficient for safe 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?

The input schema already documents both parameters (100% coverage), and the description adds useful provenance for the `number` parameter by pointing to sap_list_transports or sap_create_transport. The example phrase maps natural language to the field, while `response_format` is only named but fully covered by the enum schema.

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

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

The description states a specific action, 'Release (export) a transport request', on a clear resource. It also anchors the input provenance to sap_list_transports or sap_create_transport, which differentiates this from create/list/activation 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 gives clear usage context: use after obtaining a transport from sap_list_transports or sap_create_transport, and after ensuring all objects are correct and activated. It does not explicitly name exclusions or alternative tools, but the sequencing and warning are strong enough for an agent to select it appropriately.

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 beyond the annotations by explicitly warning that the tool 'can execute arbitrary function modules including write operations' and that authorization should be confirmed in production. This aligns with destructiveHint=true and readOnlyHint=false and gives the agent crucial safety 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 well-structured and front-loaded: purpose, prerequisite, warning, argument summary, return format, and examples. Every sentence contributes operational value; the warning is prominent without bloating the text.

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

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

For an open-world, arbitrary-execution tool with no output schema, the description covers the essential return shape, the need for discovery via sap_rfc_describe, and the write-risk warning. Minor gaps like error behavior and table parameter handling are not fully explained, but the schema and examples cover most practical invocation needs.

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

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

Input schema already covers all three parameters with 100% description coverage. The description adds value through concrete examples (BAPI_MATERIAL_GET_DETAIL and RFC_READ_TABLE) and clarifies that params contain import/changing parameters with default {}. This is a meaningful supplement, not just a schema repeat.

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 any RFC-enabled function module and return all exported parameters.' This clearly distinguishes the tool from siblings like sap_bapi_call (BAPI-specific) and sap_read_table by emphasizing arbitrary RFC function modules.

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 instructs to 'Use sap_rfc_describe first to discover parameters', which routes the agent to the correct discovery predecessor. It also advises confirming authorization before writing in production. It does not explicitly name alternatives like sap_bapi_call, but the guidance is sufficient for typical invocation.

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. The description adds useful behavioral detail by specifying the return structure, direction codes, and optional metadata fields, which 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?

The description is compact, front-loaded, and well organized into Args, Returns, direction legend, and Example. Every section adds useful information without redundancy.

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

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

The tool is simple with two parameters and no output schema, so the description appropriately carries the burden of explaining the return format. It fully covers what an agent needs to invoke the tool and interpret the 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 coverage is 100%, so the input schema fully documents function_name and response_format. The description adds a concrete example value and clarifies via context that function_name is the module to inspect, but it does not materially extend the schema semantics.

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

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

The description opens with a specific action and resource: "Get the parameter list (import, export, changing, table) of any RFC-enabled function module." This clearly distinguishes the tool from sibling call/inspection tools like sap_rfc_call, sap_rfc_system_info, or sap_get_ddic.

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 example question, "What parameters does BAPI_SALESORDER_CREATEFROMDAT2 take?", gives a clear usage context. It does not explicitly name alternatives or when-not-to-use cases, but the intended lookup scenario is 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?

The description adds substantial behavioral context beyond the annotations: it discloses the dependency on node-rfc and the SAP NW RFC SDK, explains what happens if the SDK is missing, describes the JSON return shape, and clarifies that credentials are reused from environment variables. This gives an agent a realistic picture of the tool's runtime behavior and requirements.

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

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

The description is concise and well-structured: purpose first, then dependencies, configuration, return shape, and bulleted notes. Every sentence adds relevant information with no fluff or repetition of schema or annotations.

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 ping tool with one optional parameter and no output schema, the description is complete. It covers what the tool does, how to configure it, what it returns, credential handling, and the failure mode when the SDK is 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?

Schema description coverage is 100%, and the single parameter response_format already has a full description and enum in the schema. The tool description adds no additional meaning to parameters, though it does mention a JSON return shape that is slightly inconsistent with the markdown/json response_format choice.

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 action ('Test the RFC connection to SAP') and the specific function module used (STFC_CONNECTION), making the tool's purpose unambiguous. However, it does not explicitly distinguish itself from the sibling tool 'sap_connection_test', which appears to serve a similar connectivity-checking 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 provides configuration prerequisites (direct vs. load-balanced connections) and notes about SDK installation, but it gives no guidance on when to use this tool versus alternative siblings like sap_connection_test or sap_rfc_system_info. There are no explicit exclusions or conditions for choosing this tool over others.

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

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

The description adds useful context beyond annotations by naming the specific RFC function and detailing the response structure with optional fields. However, it says 'Returns (json)' while the response_format parameter defaults to 'markdown', creating ambiguity about the actual output format. This is a transparency gap, though it does not contradict the read-only/idempotent 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 concise, with two sentences that deliver the core purpose and return structure without fluff. The 'Returns (json)' phrase is slightly misleading but the overall structure is efficient and front-loaded with the primary action.

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 one well-documented parameter, the description provides sufficient context: it explains the metadata retrieved and the exact response fields, compensating for the lack of an output schema. The only minor gap is the output format ambiguity, which is covered by the parameter schema.

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

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

Schema coverage is 100% and the single response_format parameter is fully documented with enum values, default, and a clear description. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate because the schema carries the 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 a specific verb and resource: 'Call RFC_SYSTEM_INFO to retrieve SAP system metadata (SID, host, release)'. It also lists the exact metadata fields returned, which differentiates it from sibling tools like sap_connection_test or sap_rfc_ping that concern connectivity rather than system metadata.

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 SAP system metadata is needed, but it does not explicitly compare to alternatives or state when not to use this tool. There is no mention of sibling tools or exclusions, so guidance is only implicit through the stated 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 already indicate destructiveHint=true, and the description confirms this by stating the tool 'creates/activates a temp class' and requires S_DEVELOP. It adds important behavioral context: environment restriction, commit requirement for data-changing BAPIs, and temp-class lifecycle.

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 Args, Examples, and Notes sections, front-loading the core purpose and then providing actionable usage details. Every section earns its place without redundant 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?

Despite having no output schema, the description explicitly documents the return shape as { className, activated, output, message }. It also covers auth requirements, environmental constraints, examples, and sibling alternatives, making it fully actionable for an agent.

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

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

Schema coverage is 100%, so the schema carries most parameter meaning. The description adds value beyond the schema with concrete examples for abap_code, including a full CALL FUNCTION pattern and inline output formatting, which clarify exactly how the parameter should be used.

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 ('Execute an ABAP snippet server-side') and resource ('ADT class-run endpoint'), and explicitly distinguishes itself as the SDK-free substitute for the sap_rfc_* tools. The scope is clear and differentiated 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?

Explicitly says to prefer sap_read_table / sap_sql_query for plain data reads, identifies itself as the RFC substitute, and warns it is dev/sandbox only, not production. This gives clear when-to-use and when-not-to-use guidance.

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

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

Annotations already mark destructiveHint=true, but the description goes far beyond that: real side effects, no dry run, HTTP 200 not implying success, timeout not cancelling the report, RESULT_TEXT not being cleared, and only classic list output being captured. This fully discloses the behavioral risks and 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?

The description is long but dense, organized into labeled sections with no filler. Every paragraph addresses a distinct concern: core behavior, arguments, return shape, examples, selection-screen limitation, RESULT_TEXT usage, and operational caveats. For a high-risk tool with this much behavioral nuance, the length is appropriate.

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?

There is no output schema, but the description fully documents the JSON return fields and stresses that ok=false must always be checked. It also covers auth, empty-output ambiguity, server-side execution after timeout, and the correct alternative for background execution. Nothing critical is missing for an agent to call this safely.

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 nuance beyond the schema, especially that namespaced programs like /ABC/ count as non-custom and require confirm_non_custom, and it clarifies max_chars defaults and caps. Some parameter explanation duplicates the schema, but the edge-case clarity justifies a 4.

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 ('EXECUTES an ABAP report'), the resource, and the return value ('list output as text'). It clearly distinguishes this from siblings like sap_syntax_check or sap_run_unit_tests by focusing on executing a report program, and explicitly notes it is not a preview.

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

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

Provides explicit when-to-use guidance and names the alternative: use sap_job_schedule for reports needing selection parameters or long-running work. It also tells the agent when confirm_non_custom is required and warns that standard reports may have side effects, so the agent can decide before calling.

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 meaningful behavioral context beyond that: it runs all test classes (FOR TESTING), returns total=0 when no tests exist, requires S_DEVELOP authorization, and provides the exact JSON return structure. No contradiction with 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 well-structured and front-loaded: a one-sentence summary, a short context paragraph, then compact Args/Returns/Examples/Notes sections. Each section earns its place and there is no fluff or tautological repetition.

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

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

For a tool with no output schema, the description provides the full JSON return structure, covers the required parameters, notes the conditional function_group parameter, clarifies response_format behavior, states authorization requirements, and handles the no-test-classes edge case. This is complete enough 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 the schema already documents all parameters. The description adds some value by giving concrete examples ('Run tests for ZCL_FOO' -> object_type='class', object_name='ZCL_FOO') and noting the function_group conditional requirement, but it does not substantially augment 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 starts with a specific action and resource: 'Execute ABAP Unit tests for an object and return pass/fail results per test method.' It clearly distinguishes this tool from static checks like sap_syntax_check or sap_atc_run because it is explicitly about running ABAP Unit tests and reporting test outcomes per method.

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 when-to-use guidance: 'Useful for verifying changes before activating or releasing' and includes a natural-language example ('Did my last edit break anything?'). It also notes the key prerequisite that the object must have test classes. It does not explicitly name an alternative tool, but the use context is strongly implied and sufficient.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description goes further by documenting wildcard syntax, the JSON return shape, ADT type codes, and the empty-result behavior, which are not inferable from 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 organized with clear sections (intro, Args, Returns, Examples, Error Handling) and front-loads the purpose. The Args block is somewhat redundant with the 100%-covered schema, but it is compact and every other section earns its place.

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

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

For a search tool with no output schema, the description supplies the return shape, type-code mapping, bounds, examples, error behavior, and exclusions, making it actionable without needing hidden context. The markdown output format is not detailed, but the json option is fully defined and annotations cover safety.

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 coverage is 100%, and the description largely restates the schema's parameter descriptions (query wildcard, max_results bounds, response_format enum). It adds examples, but these are illustrative rather than new parameter semantics, so 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?

The description opens with a specific verb and resource: 'Quick-search the ABAP repository for objects ... by name pattern,' listing concrete object kinds. It also disambiguates itself from related siblings by saying not to use it to read source or table data, so an agent can distinguish it from sap_get_source and sap_read_table.

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 names when not to use the tool ('Don't use to read source...' and '...or table data') and gives the alternative tools. The example prompts ('Find custom FI programs' -> query 'ZFI*') also demonstrate when the tool should be chosen.

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 provide hints (readOnly=false, openWorld=true, etc.), so the description carries the burden of behavioral disclosure. It delivers extensive context: the FULL-SET SYNC write semantics and restart consequence, best-effort condition handling, the generated-include line mapping, the persistence table, and the requirement for an armed listener. This goes far beyond what the 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 core purpose, then organized into Args, Returns, Examples, and Notes. Every sentence serves a purpose — behavioral caveats, workflow prerequisites, and parameter mapping — with no filler or repetition. Length is justified by the tool's complexity.

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

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

Given the absence of an output schema, the description explains the JSON return shape and the important line-number mapping caveat. It also covers persistence, session requirements, and user keying. For a setter tool with subtle side effects, nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by correlating natural-language examples ('Break on ZTEST line 42') to concrete parameter assignments and by explaining the function_group requirement and the condition caveat. This is meaningful enrichment over the structured 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-resource pair ('Set an external (ADT) breakpoint at a line in an ABAP object') and adds the user-scoping qualifier, which distinguishes it from sibling breakpoint tools like sap_list_breakpoints and sap_delete_breakpoints. The sentence about trapping execution only while a listener is armed further clarifies its distinct 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 gives clear operational context: breakpoints persist but only trap when a listener is armed, and it explicitly instructs to call sap_debug_attach then sap_debug_wait. It also explains the user-keying prerequisite for trapping another user's execution. It doesn't explicitly name alternatives for when to use a different tool, but the workflow guidance is sufficient for correct 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?

Thoroughly discloses merge semantics (PUT replaces pool section, omitted ids preserved), known limitation for selections with verified=false and notPersisted, master-language behavior, activation behavior, and read-back verification. Far exceeds what annotations alone 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 long but every section earns its place: Args, Returns, Examples, Validation, Notes. Structured for scannability with front-loaded purpose and critical limitation clearly flagged.

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 write tool with 7 parameters, 3 kinds, transport requirements, and a known server-side limitation, the description covers everything needed to call it correctly. It even documents return fields, compensating for the absent 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?

Schema description coverage is 100%, so the schema already explains every parameter. The description adds value by clarifying merge behavior and validation constraints (3-char symbols, heading id rules, max_length), but it doesn't need to compensate for schema gaps.

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 ('Write') and exact resource types (text symbols, selection texts, list headings). It clearly distinguishes itself as the write counterpart to the sibling sap_get_text_elements.

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

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

Provides explicit examples, validation rules checked before calling SAP, a known limitation with a workaround (SE38), and follow-up guidance to read results back with sap_get_text_elements.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds useful behavioral details beyond those: execution via ADT Data Preview, rejection of anything that is not a SELECT, and propagation of SAP syntax error messages. This gives an agent a clearer picture of how the tool behaves at runtime, though it doesn't discuss edge cases like timeouts or very broad 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?

The description is well-organized into Args, Returns, Examples, and Error Handling sections. The first sentence front-loads the purpose and usage condition, and each section earns its place. The long example SQL is justified because it illustrates exactly the complexity this tool is meant to handle.

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, freestyle SQL tool with no output schema, the description covers the essential needs: purpose, usage guidance, parameters, an example, output shape via 'same shape as sap_read_table', and error behavior. Combined with full schema coverage and safety annotations, it is nearly complete; minor missing details such as response size limits or authorization requirements are not critical given the read-only constraint.

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 three parameters at 100%, so the baseline is 3. The description adds plain-language restatements plus a concrete SQL example for the 'sql' parameter, demonstrating join syntax, aliases, and table references—value beyond the schema's property 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 opens with a clear, specific verb and resource: 'Run a freestyle, read-only ABAP-SQL SELECT (including joins) via the ADT Data Preview.' It also explicitly contrasts with a sibling tool, saying to use this when 'sap_read_table is not expressive enough', which makes the tool's distinct role obvious.

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 states exactly when to choose this tool over the most relevant alternative: 'Use this when sap_read_table is not expressive enough.' It reinforces the boundary by emphasizing 'read-only' and 'Only SELECT is permitted,' signaling it is not for writes or arbitrary commands.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate safety. The description adds useful details: it returns error/warning/info messages, and 404 indicates object/version not found. However, it doesn't disclose details like response size limits, whether markdown is formatted for chat, or what the URI in messages refers to.

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: the first sentence states the core purpose, followed by args, return format, example, and error handling. The structured layout helps parsing. It could be slightly tighter, but there is no fluff.

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

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

For a read-only check tool with 100% param coverage and a return schema embedded in the description, this is complete enough. The output structure is spelled out. Minor gaps: no mention of how markdown output looks, no pagination/limit behavior, and no explicit note about requiring an active SAP connection, though siblings imply that.

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. The description adds the function_group requirement and the version='inactive' validation scenario, but doesn't add much beyond the schema's own descriptions.

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

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

The description clearly states that the tool runs an ABAP syntax check against an object and returns errors, warnings, and info messages. The list of object types and the example use case (validating inactive source before activation) distinguish its purpose from sibling tools like sap_activate or sap_atc_run.

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 concrete example of when to use version='inactive', which is a clear usage signal. It does not explicitly name sibling alternatives or state when not to use this tool, but the context of syntax checking is clear enough relative to siblings like sap_atc_run, sap_where_used, or sap_get_source.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral detail beyond that: it names the BAPI, documents the JSON response shape, and indicates optional fields. No contradictions with annotations are present.

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

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

The description is well-structured with clear Args, Returns, and Examples sections. It is compact, front-loads the core purpose, and every section contributes to correct tool usage.

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 tool, the description sufficiently covers purpose, parameters, return format, and example usage. It doesn't detail error behavior or authentication requirements, but the annotations and schema already cover the safety profile and parameter constraints, so the missing pieces are minor.

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 described in the schema. The description adds value by giving example usernames and mapping natural-language questions to the username parameter, which helps an agent infer correct invocation from user requests.

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 reads SAP user details and names the specific attributes it returns (address, logon data, lock status, roles, profiles). It also identifies the underlying BAPI, which differentiates it from the many read/search tools among the 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 gives concrete natural-language examples showing when to call it ('What roles does user JSMITH have?', 'Is user VENNELAKA locked?'). It provides clear context for its intended use, though it doesn't explicitly contrast it with alternative sibling tools or state when not to use it.

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

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

Annotations already mark this read-only/idempotent, so the description adds the return shape and truncated flag, which is useful. However, it says 'Returns (json)' while response_format defaults to markdown in the schema, leaving the actual default output ambiguous and creating a mild description-vs-schema inconsistency.

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

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

The description is well-organized with supply options, return shape, and examples. Minor redundancy exists between the 'Supply either' bullets and the 'Args:' line, but overall it is compact and front-loaded.

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

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

For a tool with no output schema, the description covers input modes, max_results, response_format, return shape, and usage context with helpful examples. The only meaningful gap is not clarifying that the default response is markdown rather than the JSON shape shown.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real value by explaining the object_uri vs object_type+object_name alternatives, noting function_group is needed for functions, and mapping natural-language examples to parameter values.

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 opens with a specific verb+resource: 'Find all repository objects that reference a given object (where-used list).' It distinguishes this from sibling sap_search_objects by framing it as reference lookup and names sap_search_objects as the source for object_uri.

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?

'Essential before changing or deleting anything' clearly states when to use it, and 'Supply either object_uri... OR object_type + object_name' explains the primary calling modes. It doesn't explicitly list when not to use it or compare with other reference tools, so it falls just short of full 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?

The description adds substantial behavior beyond the destructiveHint annotation: it reveals the full stateful lock-write-activate-unlock flow, ETag-based concurrency protection, automatic lock release on errors, and that activation errors leave the source written but inactive. 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 long but every section earns its place: args, return shape, example, and error handling. It is well-structured with headers and bullets, making the dense information easy for an agent to scan and act on.

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, 7 parameters, no output schema, and destructive behavior, the description is remarkably complete. It covers the write flow, concurrency, transports, activation behavior, error codes, return fields, and a concrete example, leaving little for an agent to guess.

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 every parameter. The description's Args list mostly restates schema information, though it does add practical context like 'required for functions' and 'required for non-local objects.' That is useful but not a major semantic addition beyond the schema.

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

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

The description states a specific verb and resource: 'Replace the source code of an EXISTING program, include, class, interface, or function module.' It also explicitly says the tool does not create objects, which distinguishes it clearly from sap_create_object and other 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 gives clear context for when to use the tool, including the requirement that the object already exist and that a transport is needed for non-local objects, with direction to sap_list_transports. It does not enumerate all alternatives, but the 'does not create objects' note and transport guidance are strong practical cues.

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