capture_pdfRender a URL to PDF and return a link for downloading or sharing. Use when you need a document version of a page rather than an inline screenshot.
Render a URL to PDF and return a link to it. Costs 1 credit per call. A PDF cannot be shown to you inline - use capture_screenshot if you need to read the page yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to render | |
| delay | No | ||
| full_page | No |
Changes observed during successful MCP inspections.
v1.14.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds two genuinely useful facts: the per-call credit cost and the fact that the PDF output is not readable inline. That is good extra context, but it says nothing about latency, the effect of the delay setting, or whether the returned link is temporary or durable – all of which matter for a rendering tool that costs money.
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?
Three short sentences with the action, cost, and alternative in descending priority. No filler and no repetition of the schema.
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?
There is no output schema, and the description adequately covers the return value ('a link to it'). However, for a 3-parameter tool where two parameters are undocumented in the schema, the description should explain delay and full_page, and it does not.
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 only 33% – 'delay' and 'full_page' carry no per-parameter documentation at all, and the description does not fill that gap. 'Render a URL to PDF' only loosely implies full-page behavior; nothing explains what delay controls (a wait before capture, presumably) or its units.
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 first sentence names a specific verb and resource ('Render a URL to PDF') and states the return value ('a link to it'), so an agent knows exactly what calling it produces. It also distinguishes itself from capture_screenshot in the same breath.
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?
It gives an explicit selection rule: use capture_screenshot instead 'if you need to read the page yourself', because a PDF is not shown inline. It also reveals the 1-credit cost, which is a real routing signal against the check_usage sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.