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

Annotations only declare readOnlyHint and openWorldHint; the description adds strong behavioral context beyond them: the $1 USDC x402 charge, the no-charge rule when too few sources answer, and how async changes the charging/queueing order. It stops short of describing latency, rate limits, or response shape.

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-loads the purpose and deliverables, then appends billing/async rules. The enumerations are dense but each clause carries information; the sentence structure is a bit run-on, which slightly hurts scannability.

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 correctly compensates by enumerating the report's contents and the PDF add-on, and it covers cost and async semantics. The remaining gap is the domain-vs-policy_url input decision, which neither schema nor description resolves.

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 coverage is 60%, and the two undocumented parameters (domain and policy_url) are the most important inputs — the description says 'any website' but never clarifies when to pass a bare domain versus a full policy URL, nor which is required. It adds useful meaning for async (core source pre-check) but not for the target-selection params.

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+resource ('Privacy policy and terms review for any website') and then enumerates the exact deliverable contents (data collected, sale/sharing, AI training, retention, rights, arbitration/class-action waivers, GDPR/CCPA gaps, privacy score, PDF). This is enough for an agent to distinguish it from sibling report_* tools without opening the schema.

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?

Scope is implied ('for any website') and the billing/async mechanics give some usage context, but the description never names an alternative or a when-not condition. An agent cannot tell from this text how report_privacy_policy differs from report_domain or legal. Usage is implied rather than stated.

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