Skip to main content
Glama

url_to_pdf

Read-only

Render a web page to PDF. Requires an API key purchased at https://url-pdf.hammbox.com/buy. If this MCP request carries a valid "x-api-key" or "Authorization: Bearer" header, it renders directly and returns a 1-hour download URL; otherwise it returns purchase guidance.

Input Schema

NameRequiredDescriptionDefault
urlYesAbsolute http(s) URL of the page to render. Required.
scaleNoScale, 0.1-2. Default 1.
widthNoViewport width in px, 320-3840. Default 1280.
formatNoPaper size. Default A4.
heightNoViewport height in px, 240-2160. Default 900.
marginNoMargin shorthand like "10mm" — or an object {top,right,bottom,left}. Optional.
waitMsNoExtra settle time after load, 0-10000ms. Few dynamics pages need this.
blockAdsNoBlock requests to major ad/analytics domains before rendering. Default false.
darkModeNoRender with prefers-color-scheme: dark. Default false.
landscapeNoLandscape orientation. Default false.
timeoutMsNoNavigation timeout in ms, 5000-100000. Default 45000.
waitUntilNoPuppeteer navigation wait condition. Default networkidle2.
clickSelectorNoCSS selector to click before rendering (expand, dismiss modal, switch tab).
printBackgroundNoPrint background graphics. Default true.
waitForSelectorNoOptional CSS selector to wait for before rendering.
deviceScaleFactorNoDevice pixel ratio, 0.5-3. Default 1. Set 2 for retina.
hideCookieBannersNoRemove elements that look like cookie consent banners. Default false.
preferCssPageSizeNoHonor the page CSS @page size instead of the format option.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / blockAds
      Added value: +{
      +  "description": "Block requests to major ad/analytics domains before rendering. Default false.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / clickSelector
      Added value: +{
      +  "description": "CSS selector to click before rendering (expand, dismiss modal, switch tab).",
      +  "type": "string"
      +}
    • addedInput schema / properties / darkMode
      Added value: +{
      +  "description": "Render with prefers-color-scheme: dark. Default false.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / deviceScaleFactor
      Added value: +{
      +  "description": "Device pixel ratio, 0.5-3. Default 1. Set 2 for retina.",
      +  "type": "number"
      +}
    • addedInput schema / properties / height
      Added value: +{
      +  "description": "Viewport height in px, 240-2160. Default 900.",
      +  "type": "number"
      +}
    • addedInput schema / properties / hideCookieBanners
      Added value: +{
      +  "description": "Remove elements that look like cookie consent banners. Default false.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / timeoutMs
      Added value: +{
      +  "description": "Navigation timeout in ms, 5000-100000. Default 45000.",
      +  "type": "number"
      +}
    • addedInput schema / properties / width
      Added value: +{
      +  "description": "Viewport width in px, 320-3840. Default 1280.",
      +  "type": "number"
      +}
  2. First observed

TDQS

A4/5.0
Behavior5/5

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

Annotations establish only the safety profile (readOnly, non-destructive, open-world). The description adds genuinely non-obvious behavior: a paid API key prerequisite, accepted credential locations ("x-api-key" or "Authorization: Bearer"), the dual-path response, and the fact that the returned download URL expires after 1 hour. That is exactly the context an agent needs before calling.

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

Conciseness5/5

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

Three sentences, front-loaded with the action, then the prerequisite, then the branching outcome. The purchase URL sentence earns its place because it explains the failure mode an agent will otherwise misread as an error.

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?

For an 18-parameter, no-output-schema tool the description covers the critical unknowns: auth requirement and the shape/expiry of the result. It does not mention render-failure or timeout error behavior, a minor gap given that openWorldHint implies external variability.

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% across all 18 parameters, including ranges, defaults and enums, so the schema already carries parameter meaning. The description adds nothing about parameters, which is the correct baseline of 3 when the schema does the heavy lifting.

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 specific verb and output format ("Render a web page to PDF"), which cleanly separates it from url_to_markdown, url_to_extract and url_to_screenshot without naming them. It stops short of explicit sibling differentiation, but the artifact type makes the boundary obvious.

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

Usage Guidelines3/5

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

Usage is implied by the auth explanation: with a valid key it renders, without one it returns purchase guidance. However, there is no guidance on when to prefer this tool over the sibling renderers (screenshot, markdown) or on limits such as page complexity, so the agent must infer selection criteria.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.