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

The description reveals substantial behavioral detail beyond the annotations: it explains that the tool never fabricates results, reports partial screening via reason_code, discloses which lists actually ran, and returns an Ed25519-signed compliance receipt. This strongly aligns with readOnlyHint and idempotentHint and adds safety-relevant context.

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 well-structured with clear sections, but it is longer than necessary: four example user queries are largely redundant, and the source-list and UN-exclusion points are repeated several times. Every section contributes value, yet trimming would improve focus.

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?

Despite having no output schema, the description fully characterizes the response: screening_status priorities, matched semantics, match fields, lists_screened, sources_unavailable, reason_code, and compliance_receipt. It also covers failure behavior and tells the agent exactly what to branch on, so nothing needed for correct invocation is missing.

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?

The input schema already provides full parameter descriptions (100% coverage), so the baseline is 3. The description adds value with real example user queries mapped to exact parameter values and clarifies that country annotates and ranks results rather than filtering them, which is meaningful semantic nuance.

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 clearly identifies a free sanctions-screening tool with an explicit verb ('screening') and resource ('a name or entity against official sanctions lists'). It further distinguishes itself by naming the exact source lists, excluding the UN list, and differentiating from siblings like get_status or verify_company_record.

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?

Dedicated WHEN TO USE and WHEN NOT TO USE sections specify concrete contexts such as onboarding, payment processing, vendor engagement, and due diligence. It also explicitly excludes KYC/AML, PEP screening, adverse media, and bulk screening, which gives an agent clear routing guidance.

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