sap_read_dumps

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

No annotations provided, so description carries the burden. It discloses date defaults behavior ('defaults to today'), which is useful. However, it omits other behavioral aspects like authorization requirements, whether results are limited by max_rows (though schema covers that), or pagination. Since no annotations exist, a score of 3 reflects that the description adds some value but not comprehensive 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?

Two sentences, very concise. Front-loaded purpose, then a single key detail about date defaults. No wasted words; each sentence earns its place.

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

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

For a read tool with no output schema and no annotations, the description covers the essentials: what it reads and date defaults. However, it does not describe return format or typical usage context, which is a minor gap. Sibling tools exist but no guidance, so completeness is adequate but not rich.

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

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

Schema coverage is 100%, so parameters are already described in the schema. The description does not add much beyond the schema, but it clarifies date format and default behavior, which supplements the schema. Baseline is 3 given high schema coverage and no extra parameter details needed.

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

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

Description specifies clear verb+resource: 'Read ST22 ABAP runtime errors (short dumps)'. It distinguishes from siblings by naming ST22 runtime errors specifically, which differs from reading tables, code, jobs, etc. However, it does not explicitly contrast with 'sap_read_table_data' or others, but the ST22 reference is sufficiently unique.

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?

Implies usage: it's for reading runtime errors, but does not explicitly state when to use versus when not to use alternatives. It mentions date defaults, but no explicit alternatives or exclusions. With several sibling tools for similar operations, the lack of explicit guidance on when to choose this over others is a gap.

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