Corpus coverage

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, signaling a safe, non-mutating operation. The description adds valuable context on the tool's return structure ('totals, per-source windows, Aktenzeichen counts, limits') and explains the semantic nuances of 'limits' (version-archive floor, federal scope, version date meaning, source window differences). It also clarifies that the tool does not conflate absence types, which goes beyond the annotations. A small gap is not detailing the exact format or pagination, but that is minor for a zero-parameter read-only tool.

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

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

The description is three sentences long and front-loads the most critical information: the tool's purpose and when to use it. The second sentence lists return elements and constraints, and the third reinforces a key distinction. Each sentence earns its place, though the second sentence is dense and might be slightly overwhelming, but it is not verbose.

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

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

For a zero-parameter, read-only tool with a rich description, the description is nearly complete. It covers the tool's scope, what it returns, its limitations, and when to use it. The absence of an output schema is compensated by the detailed description of the return contents. The only minor gap is that it doesn't explicitly state that it requires no arguments, but that is trivially inferred from the zero-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?

The tool has zero parameters, so the schema provides no parameter details. The description compensates by explaining the context and what the tool returns, which is more than sufficient for a no-parameter tool. While the schema is trivial, the description's detail on the tool's output ensures an agent understands what it will receive without needing parameter guidance.

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

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

The description identifies the tool as reporting corpus coverage with a specific scope ('Corpus scope with its holes stated') and distinguishes it from siblings by clarifying it never collapses 'outside_coverage' with 'not_in_corpus'. It also mentions 'totals' and 'limits' to specify what the tool returns, making its purpose unmistakable.

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

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

The first sentence states a clear condition for use: 'Call this once when your answer depends on whether an absence is real.' It also explicitly tells users not to collapse two different answers, thereby directing when to avoid using this tool and what distinction it maintains. No alternative sibling is named, but the guidance is sufficient for a tool with zero parameters, as the condition is highly specific.

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