Skip to main content
Glama

Render with any Urlbox options

render
Destructive

General-purpose Urlbox render: any output format and any option. Prefer the specific tools; use this when you need an option combination they don't cover. One render can also save the page's markdown, HTML and metadata: set save_markdown, save_html or save_metadata instead of making a second call. The markdown and metadata come back with the result. Any other Urlbox option (proxies, cookies, headers, user agent and many more) goes in options: look it up with describe_options.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "intent": "<intent>"
    },
    "name": "render"
  }
}

Input Schema

NameRequiredDescriptionDefault
gpuNoEnable GPU acceleration to render 3D scenes and heavy WebGL content. This is a beta feature and requires pre-approval. Please contact support@urlbox.com to enable this feature on your account. Requires the ultra plan or above.
urlNoThe URL or domain of the website you want to screenshot. We will automatically prepend http:// if it is missing.
htmlNoHTML to render instead of a URL (HTML to PDF, HTML to image).
delayNoThe amount of time to wait before Urlbox captures a render in milliseconds.
forceNoGenerate a fresh render on each request, instead of getting a cached version.
widthNoThe viewport width of the browser, in pixels.
formatNoThe output format of the resulting render. One of: png, jpeg, webp, avif, svg, pdf, html, mp4, webm, md.
heightNoThe viewport height of the browser, in pixels.
intentYesRequired. In one or two sentences, what you are trying to achieve for the user with this call and why (for example: 'Screenshot the pricing page so the user can compare plans'). Recorded for analytics and audit; do not include secrets.
retinaNoTake a 'retina' or high-definition screenshot, equivalent to setting a device pixel ratio of 2.0 or @2x. Please note that retina screenshots will be double the normal dimensions and will normally take slightly longer to process due to the much bigger image size.
optionsNoAny other Urlbox render option by name, e.g. { "gpu": true }. For an option this tool doesn't list, look it up with describe_options first (it covers every option); don't search the web. Validated by the Urlbox API.
projectNoProject id (proj_…) or exact name to render with. Defaults to your default project.
selectorNoTake a screenshot of the element that matches this selector. By default, if the selector is not found, Urlbox will take a normal viewport screenshot. If you prefer Urlbox to fail the request when the selector is not found, pass fail_if_selector_missing=true.
wait_forNoWaits for the element specified by this selector to be present in the DOM before taking a screenshot or PDF. By default, Urlbox will take a screenshot or PDF if the wait_for element is not found after waiting for the time specified by the wait_timeout option. If you prefer Urlbox to fail the request when the wait_for element is not found, pass fail_if_selector_missing=true
block_adsNoBlocks requests from popular advertising networks from loading.
dark_modeNoEmulate dark mode on websites by setting prefers-color-scheme: dark
full_pageNoSpecify whether to capture the full scrollable area of the website. For PDFs, full_page mode will attempt to capture the whole website onto one single page PDF document. It's likely you'll want to also hide any cookie banners that crop up during a full page screenshot, so we recommend you use click_accept and hide_cookie_banners too.
save_htmlNoAlso save the page's rendered HTML.
wait_untilNoWaits until the specified DOM event has fired before capturing a render. The available options are: domloaded (the DOMContentLoaded event is fired); mostrequestsfinished (consider navigation to be finished when there are no more than 2 network connections for at least 500 ms); requestsfinished (there are no more than 0 network connections for at least 500 ms); loaded (the load event is fired); One of: domloaded, mostrequestsfinished, requestsfinished, loaded.
click_acceptNoSimilar to the hide_cookie_banners option, but instead of hiding the banners, this option attempts to click on the 'Accept' button, in order to accept cookies.
wait_secondsNoHow long to wait for the render before returning. 0 queues it and returns a render id at once. If the wait runs out the render keeps going; fetch it with get_render.
hide_selectorNoHide specific HTML elements on the page before rendering. This option accepts a comma-delimited string of CSS element selectors that will be hidden by setting their style to visibility: hidden !important; pointer-events: none !important;. This preserves the page layout while making elements invisible. This is particularly useful for: Hiding pop-ups, banners, or cookie notices; Removing advertisements or promotional overlays; Excluding navigation menus or sidebars; Hiding specific content sections; Selector types supported: Element selectors (e.g., h1, div, img) - Hide all elements of that type; Class selectors (e.g., .popup, .banner) - Hide elements with specific CSS classes; ID selectors (e.g., #header, #sidebar) - Hide elements with specific IDs; Complex selectors (e.g., .nav ul li, div.content > p) - Use any valid CSS selector; Multiple selectors - Combine multiple selectors with commas; Tip: To find the selector for any element, open your browser's DevTools, right-click the element in the Elements tab, and select "Copy > Copy selector".
save_markdownNoAlso extract and save the page as Markdown alongside the render.
save_metadataNoAlso extract and save page metadata (title, description, OpenGraph, etc.).
engine_versionNoSets the version of the urlbox rendering engine to use when rendering the page. This can be useful for testing how a page will render in the latest version of our rendering engine. One of: stable, latest, experimental.
hide_cookie_bannersNoAutomatically hides cookie banners from most websites, by setting their style to display: none !important;

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / engine_version
      Added value: +{
      +  "description": "Sets the version of the urlbox rendering engine to use when rendering the page. This can be useful for testing how a page will render in the latest version of our rendering engine. One of: stable, latest, experimental.",
      +  "type": "string"
      +}
    • addedInput schema / properties / gpu
      Added value: +{
      +  "description": "Enable GPU acceleration to render 3D scenes and heavy WebGL content. This is a beta feature and requires pre-approval. Please contact support@urlbox.com to enable this feature on your account. Requires the ultra plan or above.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / options / description
      Previous value: -"Any other Urlbox render option by name (see describe_options). Validated by the Urlbox API."New value: +"Any other Urlbox render option by name, e.g. { \"gpu\": true }. For an option this tool doesn't list, look it up with describe_options first (it covers every option); don't search the web. Validated by the Urlbox API."
    • addedInput schema / properties / save_html
      Added value: +{
      +  "description": "Also save the page's rendered HTML.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / save_markdown
      Added value: +{
      +  "description": "Also extract and save the page as Markdown alongside the render.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / save_metadata
      Added value: +{
      +  "description": "Also extract and save page metadata (title, description, OpenGraph, etc.).",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Goes beyond the annotations by disclosing a cross-cutting efficiency behavior — one call can also save markdown, HTML and metadata instead of a second call, and markdown/metadata come back with the result. It does add context on caching via the force parameter. It does not address the annotation profile (non-idempotent, destructiveHint=true — presumably credit consumption and no side-effect-free guarantee), which is the main remaining gap.

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?

Four short sentences, front-loaded with the tool's role, then the preference rule, then the batching tip, then the escape hatch for unknown options. Nothing is redundant with the schema and no sentence is filler.

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 a 26-parameter, open-ended tool with no output schema, the description covers the decision-relevant parts: why to pick this over siblings, how to batch extra outputs, and where undocumented options go. It is slightly thin on what the response looks like when save_* flags are used (where the saved artifacts surface), but that is a minor gap given full schema coverage.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining the semantics of the `options` bag (arbitrary Urlbox option names, validated by the API, look up via describe_options) and the save_markdown/save_html/save_metadata flags as alternatives to a second render. That is meaning beyond the schema's field descriptions.

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

Purpose5/5

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

States a specific verb and resource ("General-purpose Urlbox render: any output format and any option") and immediately positions itself relative to the narrower siblings. An agent can tell from sentence one that this is the catch-all render path rather than pdf, screenshot, or markdown.

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

Usage Guidelines5/5

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

Gives explicit routing: "Prefer the specific tools; use this when you need an option combination they don't cover," plus a rule for the escape hatch (look up unknown options with describe_options, don't search the web). This is exactly the when/when-not/alternative guidance the dimension asks for.

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.