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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds material context they cannot carry: a $0.01 USDC x402 charge per answer with refusals uncharged, a fail-closed refusal policy enumerating six distinct failure modes, and a byte-for-byte deterministic response bound to an artifact hash. That is exactly the economics and error semantics an agent needs before spending money.

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?

Dense and front-loaded: purpose, required inputs, refusal conditions, cost, then output contract and docs link. A little repetition ('no-ruling-v1' and the tolerance are restated in the refusal list) costs it the top band, but almost every clause carries operational weight.

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?

With no output schema, the description takes on the return contract and does so explicitly: the JSON envelope of the named endpoint byte for byte, including the artifact hash. Combined with cost, refusal behavior and a rules URL, an agent has everything needed to call this correctly or predict why it will refuse.

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 coverage is 43%, and the description compensates by pinning the acknowledge sentinel value ('no-ruling-v1') and the freshness_tolerance grammar ('P<n>D' whole days, ceiling-bounded), plus stating that trade_date must be an in-coverage business day. It says less about settlement_lag and accrual_start, which the schema already patterns, so it stops short of full coverage but clearly outpaces the schema alone.

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?

Names the precise computational product — a settlement date on the Payments Canada holiday calendar plus an accrual fraction under five named conventions — which no sibling tool touches. The verb is elided in the opening fragment, but the resource, scope and domain are unmistakable.

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?

"Send all seven inputs, including acknowledge no-ruling-v1 and a freshness_tolerance..." gives an explicit calling prerequisite, and the refusal list effectively states the preconditions that must hold. There is no comparison against alternative tools, but the siblings (base64, timestamps, list diff) are unrelated, so no routing ambiguity exists.

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