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

With no annotations supplied, the description carries the full disclosure burden and does unusually well on the most consequential point: it states plainly that the on-chain anchor WRITE is stubbed in this build and that deliveries are marked anchor_status stubbed. It also discloses the $5.00 USDC on Solana charge and that the service absorbs the write cost. It does not cover idempotency for a repeated receipt_id, whether payment is still collected when the write is stubbed, or failure behavior, which keeps it below a 5.

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 text is only two sentences, yet the opening is a price tag followed by the tangled clause "the payment buys the request and quote for anchoring", which is easy to misread as purchasing only a quote. The critical stub disclosure is placed second, after the pricing preamble. It is compact but not front-loaded on the action.

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 paid, chain-touching operation with no annotations and no output schema, the description covers cost and the stubbed-write caveat, which are the two facts an agent most needs. It stops short of explaining the required parameter formats, what a delivery contains beyond anchor_status, or how a repeat call behaves. Adequate for the core decision, incomplete 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 0%, so neither receipt_id nor receipt_hash is documented in the schema, and the description does not fill that gap. It implies receipt_id identifies an already-issued receipt but gives no format, and receipt_hash is never mentioned at all, leaving its algorithm or encoding unknown. The description adds context about what the receipt is, but not enough meaning about the two parameters.

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 names a specific verb and resource: anchoring one already-issued receipt on Solana. That separates it from siblings such as execution_receipt_issue and execution_receipt_verify, which create or check receipts rather than anchoring them. The purpose is clear, but the lead sentence is dominated by pricing ("$5.00 USDC ... per anchored receipt") rather than by what the tool does, so the agent must read past the price to find the action.

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 phrase "anchoring one already-issued receipt" implies the receipt must exist first, which suggests issuing before anchoring. However, no sibling tool is named as the alternative, and there is no explicit statement of when not to use this tool, for example when the receipt is not yet issued or when the anchor is already present. Usage is implied rather than instructed.

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