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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context beyond them: the check is ed25519 over a stored receipt, scope is exactly one receipt, and authentication must be a plan bearer token rather than x402. That auth constraint is material for callers and not obtainable from annotations.

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 terse sentences with no filler, and the authentication constraint is front-loaded. The telegraphic style of the first sentence costs a little readability but nothing is wasted.

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 should explain what verification returns (valid/invalid, error conditions), and it does not. Combined with five largely undocumented parameters and no statement of how the receipt is selected, an agent can call this correctly only by guessing at the identifier semantics.

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?

Five parameters with only host documented in the schema (20% coverage); the description says nothing about id, day, url, or how the token parameter relates to the 'plan bearer token' remark. With zero required parameters the agent gets no guidance on which identifier (id vs url vs host vs day) selects the receipt. This is a significant shortfall below the 50% compensation threshold.

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: checks the ed25519 signature of one stored receipt, and equates it to GET /v1/verify. That is clearly distinguishable from the broader sibling tools like verify-like 'check' or 'history'. The opening fragment 'Plan bearer token, never x402' is cryptic as a purpose statement but does not obscure the core 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 'Same check as GET /v1/verify' line gives an implicit usage anchor for agents familiar with the REST surface, but there is no explicit when-to-use versus the sibling tools (check, find, coverage, dispute_status). No exclusions or preconditions are stated beyond the token-type note, leaving the agent to infer selection.

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