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

With no annotations, the description carries the burden and does substantial work: SSRF-safe, noai pages refused, bad schemas rejected before payment, per-call price and payment rail (x402/USDC), and null semantics for fields not present. Gaps remain on timeouts, non-HTML responses, and other failure modes.

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 the use case, then Input/Output/Example/Price labels keep it scannable with almost no filler. The inline URL-encoded example is dense and slightly awkward to parse, which keeps it from a 5.

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?

No annotations and no output schema, so the description must supply everything, and it does: return shape (validated JSON, null, title, finalUrl), input constraints, refusals, and cost. An agent can call it correctly and predict the response without opening anything else.

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 already 100%, but the description goes well beyond it: URL-encoding requirement, object root, max 30 properties, depth 3, 3,000-char limit, plus a concrete inline example. These are hard constraints an agent would otherwise violate.

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 precise verb and resource: turn a web page into JSON matching a caller-supplied schema. The phrase 'specific fields from a web page as JSON' implicitly but clearly separates it from content-reading siblings like web_read and convert_to_markdown.

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 when an agent needs specific fields from a web page as JSON' gives clear selection context, and the fixed-schema pointer gives a fallback path. It never names an alternative (web_read, web_metadata, docs_extract) or states when not to use it, so the agent must infer the boundaries.

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