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

Annotations cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower, and the description adds material context beyond them: this is a paid call at US$0.02 per successful autonomous x402 call or 1 Horse Truth credit, which tells the agent about cost and the x402 payment path. It stops short of stating whether billing occurs on failure or anything about the receipt's structure.

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?

Three sentences, front-loaded with the cost model and then purpose and alternative. Slight redundancy in repeating 'cryptographic receipt' across the purpose sentence and the when-to-use sentence, but nothing is wasted overall.

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 burden of explaining what the receipt actually contains (format, verifiability method, fields), and it does not. For a tool whose entire value is producing a verifiable proof artifact, the missing receipt detail is a real gap.

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 single 'horse' parameter is documented at 100% schema coverage, including the Australian form-guide naming convention and the pointer to resolve_horse. The description adds nothing about the parameter, so the schema carries the full burden — baseline 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?

States a specific verb and resource: it 'returns a cryptographic receipt for the current derived horse-intelligence payload.' It also explicitly distinguishes itself from horse_intelligence, telling the agent that this is the proof artifact rather than the read itself.

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 an explicit when-to-use ('when you need a cryptographic receipt for the current read, so you can later prove what was returned') and names the alternative for the other case ('Use horse_intelligence instead for the read itself'). The routing decision is fully specified.

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