print_pdf

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

With no annotations provided, the description carries the full behavioral burden and does substantial work: it discloses the side effect (file saved to results/ dir), the return contract (path and size, not bytes), and even the rationale for that contract. It stops short of mentioning failure modes or tab-state requirements, but the core behavioral profile is well covered.

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 sentences, ~40 words, with the action front-loaded and zero filler. The second sentence earns its place by explaining the return shape and the design rationale, which are essential for the agent to know before invoking.

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?

Given no output schema and no annotations, the description covers the three things an agent must know: what happens (PDF rendered via print pipeline), where output goes (results/ dir), and what comes back (path and size). The main gap is explicit guidance distinguishing this from screenshot for page-visual needs, and minor details like error behavior or the meaning of the returned path.

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 75%, so the schema already documents six of eight parameters with ranges and defaults. The description adds no parameter-level detail, but it doesn't need to for the covered parameters; the two uncovered ones (landscape, preferCSSPageSize) are self-descriptive booleans. This lands at the baseline: schema does the heavy lifting.

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 a specific verb (render/save), a specific resource (the page → PDF), and the mechanism (Chrome's print pipeline). It clearly differentiates from visual siblings like screenshot by specifying PDF format and the print pipeline, and from download_file by describing where the output lands.

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 second sentence implies usage context: use this to produce a PDF artifact for the user, not to consume content yourself ('a PDF is not something to spend context on'). However, it never explicitly names alternatives like screenshot or read_as_markdown or states when to prefer one over the other, leaving the routing to inference.

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