url2image

create_screenshot_batch

Render a list of web pages in a real browser. Returns a batch id to poll. The first 10 screenshots each month are free, metered per network address rather than per key, so issuing another key does not reset them. Beyond that the batch pauses and reports how many credits it needs.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No	Label for the batch, shown on the results page.
`urls`	Yes	Public http or https addresses. Bare domains are accepted and normalised.
`width`	No
`format`	No	One file per URL, collected in a zip. PDF output is disabled on this deployment.	png
`height`	No
`delay_ms`	No	Extra settle time after the page reports it has loaded.
`dark_mode`	No
`full_page`	No	Capture the whole scrollable page rather than just the viewport. Off by default; a long page costs the same credit but takes much longer to render.
`device_scale_factor`	No	Use 2 for retina density output.
`block_cookie_banners`	No

TDQS

A3.8/5.0

Behavior4/5

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

No annotations exist, so description carries full burden. It discloses that rendering happens in a real browser, the free tier limit, metering per network address, and that the batch pauses when credits are exhausted. However, it does not mention error conditions or what happens on failure, reducing transparency slightly.

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?

Two sentences cover the core action and key metering behavior. The most important action ('Render ... Returns batch id') is front-loaded. However, it could be slightly more structured by separating parameters from limitations, but overall it's efficient.

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

Completeness3/5

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

The tool has 10 parameters and no output schema. The description omits the return format (beyond batch ID) and does not clarify which parameters are critical. For a complex batch creation tool, more detail on usage patterns (e.g., typical values, interaction between full_page and delay) would improve completeness.

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 60%; the description adds meter pricing context but does not improve understanding of individual parameters beyond what the schema already provides. For the 40% of parameters without schema descriptions (e.g., dark_mode, block_cookie_banners), the description offers no help, so it does not compensate.

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?

Description clearly states the tool renders web pages in a real browser and returns a batch ID. The verb 'render' and resource 'web pages' are specific. Sibling tools are distinct (e.g., get_screenshot_batch retrieves results, create_credit_checkout deals with payments), so no confusion.

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?

The description implies polling via get_screenshot_batch ('Returns a batch id to poll') but does not explicitly state when to use this tool versus alternatives, e.g., when to use list_sample_captures instead. No when-not-to or exclusion criteria provided.

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

All url2image tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: payment, screenshot rendering, account balance, batch status polling, and sample preview. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent 'verb_noun' pattern in snake_case, such as 'create_screenshot_batch' and 'get_account_balance', making the set predictable.

Tool Count5/5

With 5 tools covering core functionalities (screenshot creation, status checking, account management, and payment), the set is well-scoped without being too sparse or overwhelming.

Completeness4/5

The tool surface covers the main workflow: creating batches, checking results, managing credits, and purchasing. A minor gap is the lack of a cancel or delete operation for batches, but this is not critical.

Resources

Need Help?