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

With no annotations at all, the description carries the full burden and does well: it discloses per-document pricing (€0.006), the auth mechanism (API key via Authorization: Bearer), and several non-obvious defaults (A4, print_css true, footer auto-appends page numbers). What it omits is failure behavior, rate limits, or whether a charge occurs on error.

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 cost/auth, then a compact parameter rundown — a sensible order with no filler sentences. The single dense paragraph is slightly hard to scan, and the unlabeled parameter dump could have used lighter structure, but nothing is wasted.

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?

An output schema exists, so return values need no explanation; pricing, auth, defaults, and all 10 parameters are covered. The remaining gaps are operational edge cases (maximum document size, timeout behavior, billing on failed renders). For a tool of this complexity the description is nearly sufficient to call correctly on the first try.

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 0% across 10 parameters, so the description must compensate entirely, and it does: every parameter is explained with meaning, the format enum is enumerated, margin gets a concrete example (15mm), and the header/footer/page_numbers interaction is spelled out. This is the main source of parameter meaning and it is essentially complete.

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?

"Pixel-accurate PDF from a URL or your HTML" gives a specific verb (render/generate) and resource (PDF) plus the fidelity promise that separates it from generic converters like doc_convert or pdf_tools. The named use cases (invoices, reports, contracts) sharpen the intent further. It never names a sibling tool explicitly, which keeps it 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?

The phrase "Invoices, reports, contracts" implies the intended scenarios, and the url-vs-html choice is implied by the parameter list. However, there is no explicit statement of when to prefer this over pdf_tools, doc_convert, screenshot, or url_to_markdown, and no stated prerequisites or limits. Usage is inferable but not directed.

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