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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavioral context beyond that: the call is paid ($0.002 / 2000 atomic USDC on eip155:8453) and payment is carried in an x402 PAYMENT-SIGNATURE header. It omits what happens when payment is absent or invalid and any rate limiting, which keeps it from 5.

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?

Two tightly packed sentences, front-loaded with what is detected and followed by the payment prerequisite. No filler, no repetition of the schema or annotations, and every clause carries decision-relevant information.

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?

There is no output schema, so the description is the only place an agent could learn what a screening call returns, and it says nothing about verdict shape, per-item results for the batch form, or payment failure behavior. The detection scope and payment model are complete, but the return-value gap is material for a no-output-schema tool.

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 the single 'prompt' and batch 'prompts' fields are already fully documented in the schema with length and item limits. The description adds no meaning about choosing the single versus batch form, so the baseline 3 for schema-carried parameter semantics 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?

The description names the exact threat classes screened (prompt injection, MCP tool-poisoning, Unicode tag smuggling, secret exfiltration) and pairs them with the tool's own 'prompt' scope, which clearly separates it from screen_address, screen_domain, screen_url and screen_batch. The framing is nominal ('firewall') rather than an explicit verb like 'scans', so it falls just short of 5.

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?

There is no when-to-use guidance, no mention of when NOT to use it, and no routing to alternatives such as screen_secret, despite secret exfiltration being one of the listed detections and screen_secret being a sibling. The only prerequisite mentioned is payment, which is useful but is not usage guidance.

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