Urlbox

Render a list of URLs

render_batch

Destructive

Render a list of URLs, or one URL several ways (formats, viewport widths, full page or not), in one call: for example URLs from a CSV, a Google Sheet or another tool's output. Up to 100 items per call; split longer lists into several calls. Items are queued at a pace your plan's rate limit allows, and each is billed like the same single render. Returns a batchId at once; collect the results with get_render({ batchId, wait_seconds }), which returns a short row per item (status, result URL or error), not the files themselves.

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>",
      "items": "<items>"
    },
    "name": "render_batch"
  }
}

Input Schema

Name	Required	Description
`items`	Yes	1 to 100 items. Repeat a URL with different options to render it several ways.
`intent`	Yes	Required. 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.
`project`	No	Project id (proj_…) or exact name to render with. Defaults to your default project.
`defaults`	No	Render options every item gets, e.g. { "format": "png", "full_page": true }. Look options up with describe_options.
`idempotency_key`	No	Any unique string. Calling again with the same key returns the first batch instead of rendering everything twice.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Adds substantial behavior beyond annotations: asynchronous queueing paced by the plan's rate limit, per-item billing identical to a single render, an immediate batchId return, and the exact path to collect results via get_render with its row-per-item shape. It does not explain why destructiveHint is true or what could be lost, 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 sentences ordered as purpose, limits, runtime/cost behavior, then result retrieval. The how-to-fetch-results note is front-loaded enough to prevent the common mistake of expecting files back, and nothing is filler.

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

Completeness5/5

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 compensates precisely by stating that the return value is a batchId and that get_render yields status/result URL/error rows rather than files. For an async, nested-object, open-world tool this covers everything an agent needs before calling.

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 baseline is 3; the description earns an extra point by explaining item semantics (repeat a URL with different options to render it several ways) and the concept of per-item options layered over shared defaults, which the schema only hints at. It says nothing about `intent` or `idempotency_key`, but the schema documents those fully.

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?

Uses a specific verb and resource ("Render a list of URLs") and immediately scopes it: batch of URLs, or one URL several ways (formats, viewport widths, full page). This clearly separates it from the single-URL `render` and option-inspection siblings without needing the schema.

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?

Gives concrete triggering contexts (URLs from a CSV, Google Sheet, or another tool's output) and a hard cap of 100 items with the instruction to split longer lists into several calls. It stops short of explicitly contrasting with `render` for single-URL cases or pointing to `list_renders` for historical batches.

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

All Urlbox tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.