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

Annotations already give readOnlyHint=true and openWorldHint=false, but the description adds key behaviors: it does not perform authentication, does not re-fetch any data, does not reconstruct history, and does not assign economic significance. This meaningfully explains the tool's boundary and fallibility without repeating the annotations verbatim. The 'examples are synthetic' parenthetical is a perfect transparency addition.

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 a lean three-point list: purpose, behavior, caveat. It front-loads the primary action and then names exclusions in a tight list. It is not bloated or redundant, though 'Examples are synthetic.' could arguably be dropped or moved to a parenthetical, but it is short and earns its place.

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?

Given no output schema, the description still tells the agent that results are 'threshold crossings' without economic interpretation, and that the tool takes two snapshots plus a threshold in basis points. The schema covers the structure of `after`, `before`, and `threshold_bps`, and the preceding notes about no data access set expectations. The main remaining gap is the absence of an explicit output format, but for a comparison tool this is acceptable because the return is predictable for a human, and the agent can infer it.

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?

Since schema_description_coverage is 100%, the baseline is 3. The description adds a little context by mentioning 'threshold crossings' and 'threshold_bps', but it does not explain how each parameter maps to the comparison logic beyond what the schema already does (e.g., 'before' describes schema_version). The additional 'Issuer origin not confirmed' for `after` is schema content, not description content, so the description adds no new parameter semantics.

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 ('compare') and resource ('two 402rates Treasury snapshots'), then enumerates the exact fields covered (yield, issuer divergence, source identifiers, calculation windows, data availability). It immediately differentiates from siblings like compare_settlement_costs by specifying 'issuer_vs_basis_bps' threshold crossing and 'Treasury snapshots'.

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 tool's purpose itself implies when to use it (whenever you need to diff two saved Treasury snapshots), but there is no stronger 'use this over X' guidance. The description only lists exclusions ('no new data access, no authentication, no historical reconstruction, no automatic monitoring') rather than actively routing the agent away from possible alternative tools. Some of those negatives are constraints, not usage criteria.

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