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

Annotations already cover readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety profile is fully declared. The description adds meaningful behavioral context beyond annotations: it describes the return structure (per-name match lists with fuzzy scores, source attribution, risk topics, disclaimer field), the informational nature of results (not legal/compliance advice), and that matches are 'potential hits' requiring verification rather than confirmed listings. This is genuinely useful behavioral disclosure.

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 single well-organized paragraph that front-loads the core purpose, adds return-structure detail, and closes with an important disclaimer about interpretation. It's somewhat dense but every sentence earns its place. Could arguably be split into clearer sections, but it's efficient and appropriately sized for a tool with meaningful caveats.

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 an output schema exists (return format is likely documented there), full schema parameter coverage, and comprehensive annotations (readOnly, idempotent, non-destructive), the description compensates for what structured fields don't cover: interpretation guidance, source scope, use cases, and the informational-vs-confirmatory distinction. For a sanctions screening tool with compliance implications, this level of contextual completeness is appropriate.

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 100%, so all three parameters are fully documented in the schema (names array with max 1000, fuzzy boolean default true, min_score default 0.7). The description adds value by explaining the interpretation of match scores (potential hits needing verification) but doesn't add syntax or format details beyond what the schema already provides. Baseline 3 with moderate added context is appropriate.

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 uses a specific verb ('screen') with a clear resource ('person or company names against UN, EU, OFAC and PEP sanctions lists'), specifies the data source scale (768K+ entries via OpenSanctions), and names its typical use case. It clearly distinguishes from siblings like lookup_company and company_enriched by focusing on sanctions screening rather than general entity lookup.

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?

It gives a concrete typical use case ('counterparty checks before onboarding or processing a payment'), which is clear context. However, it does not explicitly state when NOT to use this vs alternatives or name sibling alternatives. It does clarify that matches are informational and require verification, which guides appropriate interpretation of results.

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