Get a receipt

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

The annotations already mark the tool as read-only and non-destructive, so the bar is lower. The description adds valuable behavioral context beyond annotations: no key is needed, the receipt is content-hashed, reproducible, and Ed25519-signed with a published key URL. This gives the agent meaningful integrity and trust information.

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 verb and resource, and every sentence earns its place. The first sentence states the action and endpoint; the second adds only high-value security and reproducibility details without 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 one-parameter read-only tool with rich annotations, the description is nearly complete: it explains purpose, prerequisites, and receipt properties. It does not describe the return value structure, but since no output schema exists, a bit more detail on the returned verdict format could improve completeness. Still, it is 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?

Schema description coverage is 100%, and the only parameter 'id' is already documented as 'Receipt id from a validation result' with a pattern. The description adds no new parameter semantics beyond referring to a receipt id, 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 a specific verb ('Fetch'), a specific resource ('stored verdict by receipt id'), and an explicit endpoint ('GET /api/v1/receipts/{id}'). It also states the purpose ('re-check an earlier result'), which distinguishes it from the validation-focused 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 a clear context: use it when you have a receipt id and want to re-check an earlier result. It also provides a prerequisite ('No key'). However, it does not name or contrast against the closely related sibling 'verify_receipt', so the agent is left to infer when to use this tool versus alternatives.

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