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

Annotations already establish readOnly/idempotent/non-destructive, yet the description adds substantial behavior beyond them: per-address and per-call pricing with a minimum, error semantics (422 naming the offending index, not charged), latency (~0.5 s for 1,000), data-handling (submitted text never logged or stored), and honest limitations (non-match does not clear an address; not legal advice; verify at OFAC). That is exactly the kind of context structured fields cannot carry.

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?

Front-loaded and dense with useful facts, but there is real repetition: sentence three ('Returns the OFAC sanctions screen of 1-1,000 crypto addresses in one call') restates sentence one, and the batch-size/pricing figures appear multiple times. Trimming the redundant return line and price restatement would sharpen it without losing information.

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?

An output schema exists, so return values need not be explained. Given that, the description covers everything else an agent needs before calling: matching rules, batch limits, cost bounds, failure mode, latency, data retention, and legal caveats. Nothing material is missing for a one-parameter screening tool.

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 100%, so the baseline would be 3, but the description goes further: it explains that EVM and bech32 entries match case-insensitively while other formats are matched exactly as listed, that pricing is per address, and that a single invalid item aborts the batch with a 422 identifying its index. That is meaning the schema's regex and min/max alone do not convey.

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 (screen), resource (crypto addresses), and scope (up to 1,000, against the OFAC SDN list) in the first sentence, then explicitly names the sibling it is not for: 'For one address use check_sanctions.' An agent can pick between the batch and single-address tools without opening either schema.

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?

Names the alternative tool and the exact condition that selects it (single address → check_sanctions), and bounds the batch regime with concrete limits (1-1,000 per call, one invalid item fails the whole batch). This is explicit when-to-use/when-to-use-something-else guidance rather than implied context.

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