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

Annotations provide idempotentHint/destructiveHint/readOnlyHint, and the description adds genuinely useful context beyond them: cost ($0.10, x402-paid), the non-obvious null-score semantics for no-risk findings, the 'review required' follow-up, and the scope boundaries. This meaningfully extends what an agent can infer from the annotations alone.

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 with zero waste: cost/function first, then outcome behavior, then exclusions. Every clause earns its place, and the most decision-relevant facts (paid, caller-provided inputs, null-score behavior, what it won't do) are front-loaded.

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 the rich output schema, 100% parameter coverage, and annotations, the description covers the core invocation facts: what to provide, what the result means, and cost. Minor gaps remain — the x402 payment flow is only explained in the schema's parameter descriptions, not the tool description — but nothing an agent needs to call it correctly 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?

Schema description coverage is 100%, so the schema already documents all 15 parameters well, including payment fields. The description adds only light semantic grouping by naming the signal categories (sanctions, exposures, labels, funding) that map to params like sanctionsHits, exposures, labels, and fundingSources. Per the rubric, baseline 3 applies when the schema does the heavy lifting.

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 names a specific verb ('analyzes') and resource ('caller-provided sanctions, exposures, labels, and funding context') and precisely defines the outcome boundary: positive findings get a score, no findings yields null/unknown with review required. The explicit exclusions — 'No chain lookup, independent sanctions screening, or compliance clearance' — sharply differentiate it from risk-related siblings like mcp_risk_score and action_safety tools.

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?

The description gives clear context for when to use the tool (when you have caller-provided risk signals to score) and explicit when-not boundaries (no chain lookup, no independent screening, no compliance clearance). However, it never names the sibling tools that supply those excluded capabilities, so an agent must infer alternatives rather than be routed to them directly.

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