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

Goes well beyond the readOnly/openWorld/idempotent annotations: it discloses fuzzy-matching behavior (spelling variants, transliteration, word order), return shape (scored matches with memberships, references, programmes, birth dates), data freshness (weekly refresh, 25,000+ entities), and cost (0.005 USDC via x402 or 3 credits). This is exactly the extra context an agent needs.

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 with the core action and coverage, then matching behavior, then returns, then pricing. Every clause carries distinct information with no redundancy.

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 compensates by describing the return content, and it also covers input scope, pricing, and refresh cadence. An agent has everything required to invoke and interpret this tool correctly.

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 description coverage is 67%, so the schema already documents name and birth_year. The description adds meaning to the name input via fuzzy-matching/transliteration notes, but says nothing about the 'type' enum (person/entity) or the birth_year format, leaving the enum parameter to 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?

States a specific verb (screen) and resource (person or company name) with explicit scope: EU, UN, UK and US OFAC SDN lists in one call. This clearly distinguishes it from siblings like eu_sanctions_batch and eu_sanctions_wallet without needing to open their schemas.

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 intended scenarios ('For onboarding, payments and due-diligence agents'), giving clear context for when this single-name screen applies. It does not, however, explicitly route to alternatives such as eu_sanctions_batch for bulk screening, so it stops short of full when-to-use/when-not guidance.

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