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

With readOnlyHint and openWorldHint already declared, the description adds meaningful context annotations cannot: the return payload ('PDF bytes'), that rendering happens via a headless browser, and a per-call cost of $0.009 USDC via x402. It does not explain the url/html mutual-exclusivity or failure behavior for unreachable URLs, keeping it out of 5 territory.

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?

Four short sentences, zero filler: purpose, return value, use cases, price. The core action and the cost — the two things an agent most needs before committing — 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?

No output schema exists, and the description compensates by stating the return value ('PDF bytes'). The main residual gap is that zero parameters are required, yet nothing says what happens if neither url nor html is supplied, nor whether they are mutually exclusive at invocation time.

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 only 50% (the 'html' param is described as 'Raw HTML instead of url', the 'url' param has none). The description does clarify that the two inputs are alternatives ('a URL or raw HTML'), which is the single most important semantic for this tool, but adds no format or constraint detail. Baseline 3 fits.

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 (render) and resource (URL/raw HTML to PDF) plus the mechanism (headless browser). An agent can distinguish it from siblings like screenshot, doc_convert, pdf_fill, and pdf_to_images without opening any 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?

Gives concrete use cases ('invoices, reports, receipts, archiving pages'), which is real when-to-use guidance. It does not name competing siblings (screenshot for images, doc_convert for other formats) or state when not to use it, so it stops short of a 5.

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