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

Annotations already declare read-only, idempotent, non-destructive, but the description adds substantial context beyond them: the fuzzy-matching behavior (spelling, transliteration, word order), what the response contains (scored matches with lists, references, birth dates), and the full cost model — 0.005 USDC via x402, 3 credits, or 5 free paid-tool calls per day. That payment/free-tier detail is exactly the kind of operational fact annotations cannot convey.

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 sentences, front-loaded with the 'Use when' trigger, then capability/return shape, then pricing. Dense but every clause carries information the agent needs (coverage, matching behavior, output shape, cost), with no filler or repetition of the title.

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, yet the description states what comes back (scored possible matches with list, reference and birth date), plus cost and free-tier mechanics and the api_key path. For a single-lookup screening tool this covers everything needed to invoke it correctly; only the person/entity enum semantics remain unaddressed.

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 75%, so the baseline is 3, and the description earns an upgrade by explaining how the name parameter is actually matched — fuzzy handling of spelling variants, transliteration and word order — which is behavioral meaning the schema does not carry. It does not clarify the person/entity enum or how birth_year is used to disambiguate matches, leaving those to the schema.

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 — 'screens the name against the EU, UN, UK and US OFAC lists' — and scopes it further with dataset size (25,000+ persons, companies and vessels) and refresh cadence. This clearly separates it from sibling batch/wallet variants (eu_sanctions_batch, eu_sanctions_wallet) without naming them explicitly.

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?

'Use when you must check whether a person or company is under sanctions' gives an explicit trigger condition, which is more than most siblings offer. However, it never names alternatives such as eu_sanctions_batch for multiple names, pep_screen, or us_trade_screen, so the agent must infer routing from tool names alone.

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