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

Goes well past the annotations: pricing (0.50 USDC on Base over x402, no account), the two-step call protocol (unpaid call returns an isError PaymentRequired object, retry with signed payment in _meta["x402/payment"], settlement in _meta["x402/payment-response"]), and the strong guarantee that nothing is charged if the check fails or settlement fails. This is exactly the extra context annotations cannot carry, and it is consistent with readOnlyHint=false / idempotentHint=false since each call can move funds.

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 purpose, then usage trigger, then return shape, then payment mechanics and the escape hatch pointer. Every sentence carries information, but the x402 paragraph is dense and packs three distinct facts (unpaid probe, retry, settlement location) into one long sentence.

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 still explains the return ('clean, or the rules that matched') and the failure/charging semantics, and it resolves the biggest unknown for a paid open-world tool: how to pay and what an unpaid call looks like. Nothing an agent needs in order to invoke 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 both `text` and the nested `fields` map are already documented, including the 20,000-character limits. The description adds nothing parameter-specific beyond the schema — no guidance on when supplying `fields` is worthwhile — so baseline 3 applies.

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 object ('Screens text for instructions aimed at the agents that will read it') plus the ruleset used, so the agent knows exactly what comes back and why. The scope ('text it did not write: a listing, an email, a web page or another agent's output') separates it cleanly from siblings like verify_document or check_mcp_server, which validate artifacts rather than scan content for injected instructions.

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 it before your agent reads text it did not write' gives an explicit trigger condition, and the examples enumerate the concrete cases. It also states the downstream choice ('so the text can be dropped or held back first'), though it names no exclusion or alternative sibling for overlapping checks.

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