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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false, closed-world), so the bar is low. The description nevertheless adds meaningful data-integrity context: the returned receipt is 'unsigned' and 'filtered' (i.e., redacted/public), which tells the agent the content is non-authoritative. It stops short of saying what gets filtered out or what auth is needed.

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

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

A single compact sentence with the core read semantics front-loaded and the caveat second. It wastes no words, though its extreme terseness is part of why the purpose and parameter details are missing.

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?

An output schema exists, so return values need not be explained, and annotations cover safety. But for a tool with a 0%-documented required id parameter and no named alternatives among the security-related siblings, the description is only marginally sufficient for correct invocation.

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

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

There is one required parameter, receipt_id, and schema description coverage is 0% — the schema documents nothing about it. The description does not mention the parameter at all, so it fails to compensate for the coverage gap; an agent gets no hint about the id's format, source, or whether it matches the original delivery's id.

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 verb 'Read' is clear, but the description never names the resource it operates on (a security receipt) — that identity comes only from the tool name and title. It does distinguish the object from the 'original delivery', which hints at scope, but an agent reading the description alone would not know what entity it is 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?

The clause 'retain original delivery for signature verification' implies this filtered view is not suitable for signature verification, which is useful when-not guidance. However, no sibling tool is named, no conditions for choosing this over the original delivery are spelled out, and the guidance is buried in a semicolon clause rather than stated as an instruction.

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