URLpipe

Save a page as PDF

capture_pdf

Idempotent

Exposes POST /pdf. Prints the whole rendered page to a PDF — JavaScript executed, web fonts and lazy-loaded images included, its headings as bookmarks. 1 credit, whichever options you use.

Use it to archive or hand on a page as a document: a receipt, an article, a report, terms as they stood today. pdf_options choose the paper, the orientation, the margins and the scale, whether backgrounds print, whether the page's print stylesheet or its on-screen look is used, and whether to cut it into sheets at all; page_options wait for the page and take ads and cookie banners out of it.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	The page to fetch. Must be a public http(s) URL.
`sync`	No	Wait for the result and return it (default false). When false the call returns a token immediately and you collect the result with get_result.
`labels`	No	Your own keys to find this request by later, e.g. {"client": "acme"}: they come back with the result, in the webhook and in list_requests, which can filter by them. Up to 16 keys of up to 40 letters, digits, _ - or .; string values up to 256 characters.
`max_age`	No	How fresh a stored result must be to be reused, e.g. "2 hours" or "3 days". Default 7 days, maximum 30. A reused result is free. Pass "0" to force a fresh fetch.
`report_to`	No	Async only: a webhook URL to deliver the result to. Defaults to the project's configured endpoint, if it has one.
`project_id`	Yes	Which project this request belongs to. From list_projects.
`pdf_options`	No	How to print the PDF. Every key is optional; leave it out for A4 portrait.
`residential`	No	Fetch the page from a residential (home ISP) exit instead of a datacentre one. Costs a surcharge per page visit — see get_usage. Use it for sites that block datacentre traffic.
`page_options`	No	What to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too, and what scrolling loaded is in all of them.
`idempotency_key`	No	Makes the call safe to retry: sending it again with the same key within 24 hours returns the first call's token and result instead of starting (and charging for) new work, even with max_age "0". Up to 255 printable ASCII characters; a UUID is ideal.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 12, 2026

changedInput schema / properties / page_options / description

Previous value: -"What to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too."New value: +"What to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too, and what scrolling loaded is in all of them."

addedInput schema / properties / page_options / properties / scroll_to_bottom

Added value: +{
+  "description": "Scroll down the page before reading it, for as long as scrolling loads more (up to 25s). For listings and feeds that load their content as they are scrolled.",
+  "type": "boolean"
+}

AddedOct 12, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-schema context: a flat cost of '1 credit, whichever options you use', and the rendering behaviors (JavaScript executed, web fonts and lazy-loaded images included, headings turned into bookmarks). It does not mention the residential surcharge or caching beyond what the schema states, so it is not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is front-loaded: the first sentence establishes the operation and its rendering fidelity, the second gives cost, and the third gives use cases and options. The third sentence is long and slightly dense, but every clause earns its place by summarizing an option group the agent would otherwise have to read out of the nested schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description is not obligated to explain return values, and it covers cost, rendering behavior, and both option groups. The remaining gap is routing: for a 10-parameter tool with many near-sibling capture tools, it should say when PDF output is the right pick versus capture_screenshot or fetch_html.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all ten parameters in detail, including the enum values and defaults. The description's paragraph on pdf_options and page_options ('the paper, the orientation, the margins and the scale... whether to cut it into sheets') mostly paraphrases those same fields rather than adding new semantics such as format constraints or interactions. The 3 baseline is therefore correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete verb and resource: it 'Prints the whole rendered page to a PDF', and goes further to specify what the PDF includes (executed JavaScript, web fonts, lazy images, headings as bookmarks). This is far more specific than a title restatement. However, it never names or contrasts with the obvious sibling alternatives (capture_screenshot, fetch_html, fetch_markdown), so it falls short of the explicit sibling differentiation a 5 requires.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear use context — 'archive or hand on a page as a document' with concrete examples (a receipt, an article, a report, terms as they stood today). This tells the agent when this tool is appropriate. What is missing is any exclusion or explicit alternative: nothing says when to prefer capture_screenshot or fetch_markdown over this, which keeps it below a 5.

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

All URLpipe tools Inspect

Try in Browser

Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?