Skip to main content
Glama

render_screenshot

Read-only

Capture a screenshot of a URL (rendered in a real browser) and return it as an image so you can VISUALLY review the design — contrast, layout, spacing, overflow. Use after any design/page change (HTTP 200 + text checks can't see color-on-color or layout issues).

CHEAPER ALTERNATIVE FIRST: each capture uses the account's monthly screenshot allowance. If the user already has the page open in a browser, ask them to paste a screenshot into the chat — you can review it directly at NO cost. Reserve render_screenshot for automated/agent-driven checks, a URL the user doesn't have open, or precise element/region shots. (Editing, image uploads, and pasted images are always free — only server-side captures count.)

CAPTURE THE SMALLEST REGION THAT ANSWERS YOUR QUESTION — a full-page shot of a long page can exceed the image size limit and wastes most of your context: • element_id — an Elementor widget id straight from wp_get_page (BEST: after patching widget 'db438b6', screenshot exactly that widget) • selector — any CSS selector, e.g. '.hero' or '#pricing' • clip — 'x,y,width,height' pixel region Default is the viewport only (not the whole page). Set full_page=true only when you genuinely need the entire scroll height. LONG PAGES — TILE INSTEAD OF full_page: capture consecutive clip slices ('0,0,1280,2000' then '0,2000,1280,2000', ...) and review each; every tile stays under the image size limit and keeps section-level detail a squashed full-page shot loses.

JUDGING RESULTS — read the caption's byte size before concluding anything: a blank capture is <6 KB and returns an ERROR; a multi-KB success is real content even if it looks white (lazy-loaded images below the fold render white — capture the viewport or a parent instead). 'Element not found' means YOUR selector is wrong (check the widget type — e.g. nested accordions are .elementor-widget-n-accordion), not that the service is down. NEVER re-shoot the same target more than twice: if two captures disagree with your expectation, stop and ask the user to look — do not declare the service down and keep burning the allowance.

Input Schema

NameRequiredDescriptionDefault
urlYesThe page URL to screenshot (http/https)
clipNoPixel region 'x,y,width,height'. Cannot be combined with element_id/selector.
widthNoViewport width px (1280 desktop, 390 mobile; default 1280)
formatNojpeg (default) | webp | png. png is lossless and much larger.
qualityNo1-100 for jpeg/webp (default 80). Ignored for png.
selectorNoCSS selector to capture, e.g. '.hero'. Ignored if element_id is set.
full_pageNoCapture the full scrollable page (default FALSE — viewport only)
element_idNoElementor element id from wp_get_page (e.g. 'db438b6') — captures just that widget

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations: it discloses the monthly capture quota, that blank captures return an ERROR at <6 KB, image size limits on full-page shots, lazy-load rendering white below the fold, and that 'element not found' means a bad selector rather than an outage. This is rich operational context, though the exact response shape (image bytes vs. caption) is only partly described.

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?

Despite its length, it is front-loaded (purpose in sentence one) and organized into labeled blocks for cost, region selection, tiling, and result judgment. Every section carries actionable content, though the multi-paragraph format is heavier than strictly necessary for a tool whose schema is already complete.

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 8 parameters, no output schema, and cost-bearing behavior, the description covers everything an agent needs: when to call, how to scope the capture, how to read the returned image and errors, and when to stop retrying. Nothing material is left to inference.

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, but the description adds real meaning: element_id should come straight from wp_get_page after patching a widget, selector and clip are mutually exclusive with it, full_page defaults to viewport-only, and long pages should be tiled with consecutive clip slices instead. It does not restate defaults for width/format/quality, 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?

States a specific verb and resource ('Capture a screenshot of a URL rendered in a real browser') plus the reason it exists (visual review of contrast, layout, spacing, overflow). An agent can immediately distinguish this from sibling inspection tools like wp_get_page or inspect_url.

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?

Explicitly says when to use it (after design/page changes that HTTP 200 + text checks cannot validate), when not to (user already has the page open — ask them to paste a screenshot for free), and names the cheaper alternative first. It also spells out the retry cap, which is a usage rule, not just advice.

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.

Resources