Urlbox

Get a render

get_render

Read-only

Get a render's status, result URL, timings and failure reason by its render id, with a finished render's markdown, HTML or text inlined as the render tool would have returned it (from a render tool's result, or from list_renders). To collect several renders, for example ones you queued with wait_seconds 0, pass them all as renderIds (up to 50) in one call instead of one call per id. To collect a render_batch, pass its batchId: that also sends the batch's next items. Give exactly one of renderId, renderIds or batchId. Set wait_seconds (up to 95) to wait for renders still queued or running; if any are still going when the wait ends, the result says so (status running, or listed under running for a batch) and you can call get_render again.

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": "get_render"
  }
}

Input Schema

Name	Required	Description
`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.
`batchId`	No	A batch id from render_batch. Give exactly one of renderId, renderIds or batchId.
`renderId`	No	One render id. Give exactly one of renderId or renderIds.
`renderIds`	No	Up to 50 render ids to fetch in one call. Give exactly one of renderId, renderIds or batchId.
`wait_seconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 8, 2026

addedInput schema / properties / batchId

Added value: +{
+  "description": "A batch id from render_batch. Give exactly one of renderId, renderIds or batchId.",
+  "minLength": 1,
+  "type": "string"
+}

changedInput schema / properties / renderIds / description

Previous value: -"Up to 50 render ids to fetch in one call. Give exactly one of renderId or renderIds."New value: +"Up to 50 render ids to fetch in one call. Give exactly one of renderId, renderIds or batchId."

Changed3 schema fields changedNov 6, 2026

addedInput schema / properties / renderId / description

Added value: +"One render id. Give exactly one of renderId or renderIds."

addedInput schema / properties / renderIds

Added value: +{
+  "description": "Up to 50 render ids to fetch in one call. Give exactly one of renderId or renderIds.",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 50,
+  "minItems": 1,
+  "type": "array"
+}

changedInput schema / required

Previous value: -[
-  "intent",
-  "renderId"
-]New value: +[
+  "intent"
+]

First observedNov 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the read-only/non-destructive annotations, it discloses real behavior: finished renders have their markdown/HTML/text inlined as the render tool would have returned it, waits are capped at 95 seconds with a stated running outcome, and a batchId call has the side effect of sending the batch's next items. That side-effect disclosure is exactly the kind of context annotations cannot carry.

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?

It is front-loaded with the primary capability and then layers the multi-id, batch, and wait guidance in descending priority with no filler. The sentences are long and dense, so a reader must hold several clauses at once, but nothing is redundant.

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?

With no output schema, the description carries the return contract itself, naming status, result URL, timings, failure reason and inlined content, plus how partial/in-progress results are represented. For a read tool with three mutually exclusive selectors and a blocking wait, this is complete enough to call correctly on the first try.

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 80%, so the baseline is 3, but the description adds meaning the schema lacks: the "exactly one of renderId, renderIds or batchId" contract is restated as a usage rule, renderIds is framed as a batch fetch of queued work, and wait_seconds is explained as blocking for still-queued or running renders up to 95. Only the required intent parameter goes unmentioned, which the schema already covers.

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?

The description opens with a specific verb and resource ("Get a render's status, result URL, timings and failure reason by its render id") and even enumerates the returned fields plus inlined markdown/HTML/text. It implicitly separates itself from list_renders by pointing to it as a source of ids, so an agent can distinguish this single/multi-fetch tool from the listing sibling.

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?

It gives explicit when-to-use guidance: batch up to 50 queued ids in one call instead of looping, use batchId to collect a render_batch (which also advances the batch's next items), and use wait_seconds to block on running renders rather than polling blindly. It also tells the agent exactly what to do on a partial result (call get_render again).

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.