The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Render MCP listing page.
Gives an AI agent a real browser. Screenshots, PDFs, and the HTML a page produces after JavaScript has run.
No API key. No signup. No account. Point your client at a URL and it works.
An agent can fetch a URL. It cannot see one.
Ask an assistant to check whether a page looks right, or to read a site built with React, and it hits a wall: a plain HTTP fetch returns an empty shell and a loading spinner. The content is built by JavaScript that never runs.
The usual answer is a rendering API — but every one of them requires you to sign up, verify an email, and paste an API key. An agent working on its own can't do any of that. It has no inbox and no card. A free tier it cannot register for is worth nothing to it.
This server needs none of it. It runs on Cloudflare's network, launches a real headless browser, and hands back what the page actually looks like.
Claude Code — as a plugin (one command, and updates arrive automatically)
Claude Code — directly
Claude Desktop, Cursor, and other clients — add to your MCP config:
That's the whole setup. Nothing to install, nothing to configure, no credentials.
screenshot_urlSee a page as a person would. Returns a PNG.
| Argument | Type | Notes |
|---|---|---|
url | string | Required. Absolute, including https:// |
full_page | boolean | Capture the whole scrollable page. Default false |
width | number | Viewport width, 320–2560. Default 1280 |
height | number | Viewport height, 240–2000. Default 800 |
Good for: confirming a deployment looks right, checking a layout, seeing what a user sees.
rendered_htmlThe DOM after JavaScript has executed. Returns HTML text.
| Argument | Type | Notes |
|---|---|---|
url | string | Required. Absolute, including https:// |
wait_for | string | CSS selector to wait for, if content loads late |
max_chars | number | Truncation limit, 1,000–500,000. Default 100000 |
Good for: single-page apps, anything where a plain fetch returns a shell.
page_diagnosticsLoad a page and report what went wrong: JavaScript console errors, failed network requests, and any 4xx/5xx responses. Returns a readable summary.
| Argument | Type | Notes |
|---|---|---|
url | string | Required. Absolute, including https:// |
include_warnings | boolean | Include warnings and info, not just errors. Default false |
width | number | Viewport width, 320–2560. Default 1280 |
height | number | Viewport height, 240–2000. Default 800 |
Good for: a deployment that might have shipped a bug, a page that loads blank, a site that "looks broken" and you need to know why.
Stated honestly: this is not a rare capability. Microsoft's @playwright/mcp returns console
messages, and Google's chrome-devtools-mcp returns them with source-mapped stack traces across
29 tools. Both are excellent, both are better resourced than this, and between them they are
downloaded around 34 million times a month. If you can run a local process, use one of them.
The one thing neither can do is run where nothing can be installed. They need npx, Node, and
browser binaries, or a local Chrome. This needs a URL. That is the whole of the difference, and
it only matters if you are in that situation.
inspect_elementAnswers "why isn't this element showing where I expect?" for a CSS selector.
| Argument | Type | Notes |
|---|---|---|
url | string | Required. Absolute, including https:// |
selector | string | Required. CSS selector, e.g. .buy-button |
max_matches | number | How many matches to report, 1–10. Default 3 |
width | number | Viewport width, 320–2560. Default 1280 |
height | number | Viewport height, 240–2000. Default 800 |
Leads with a diagnosis, then the numbers: resolved box model, computed
display / visibility / opacity / position / z-index, colours, whether it's inside the
viewport, and whether another element is covering it.
The useful part is that it walks up the tree. The usual reason an element is missing is not the element — it's an ancestor, and the answer you want is which one:
It also catches the case no single property reveals. Content inside a closed <details> keeps a
normal box and reports display:block, visibility:visible, opacity:1 — everything looks fine,
and it still doesn't paint:
Good for: an element that "should be there", a click landing on the wrong thing, verifying a CSS change actually applied. Cascade resolution and layout cannot be derived from reading HTML and CSS — this is the one thing a browser is strictly required for.
url_to_pdfRender a page to PDF as a browser would print it.
| Argument | Type | Notes |
|---|---|---|
url | string | Required. Absolute, including https:// |
landscape | boolean | Default false |
Good for: archiving a page, turning a rendered report into a document.
Stated plainly, so an agent doesn't waste calls discovering them:
169.254.x.x, .internal and .local
hostnames are refused. This server runs inside Cloudflare's network and an unvalidated URL
would be a server-side request forgery.Failures come back as readable text explaining what went wrong, not as protocol errors — so an agent can route around them rather than crashing.
URLs and page content are never stored or logged. Each call launches a browser, does the work, hands back the result, and closes it. Nothing about what you asked for is retained.
One thing is counted, and it's worth stating precisely rather than hiding behind "anonymised":
| Recorded | Not recorded |
|---|---|
Which tool ran (screenshot_url, …) | The URL, or any part of it |
How it ended (ok, timeout, capacity, …) | Your IP address |
| How long it took, in milliseconds | Any header, cookie or credential |
| Any page content, image or PDF |
That's three fields with no way to tie them to a request, a person or a site. The function that
writes them is never handed the URL in the first place, so it cannot record one by accident —
see count() in src/index.js.
It exists for one reason: this server is free, and the only way to decide whether it's worth keeping alive is knowing whether anything calls it.
The counts are public — no login, no dashboard:
Two layers, both tested outside their host:
src/protocol.js — the MCP request/response surface as pure functions, with no Cloudflare
or browser dependency. Every URL validation and SSRF rule is proven under plain Node before
anything deploys.src/inspect-page.js — the half of inspect_element that runs inside the page. It closes
over nothing, so any real DOM can execute it. Its tests build fixture pages in headless Edge
and assert on real computed styles and real geometry. A mocked DOM would prove nothing here:
the entire premise of the tool is that these values only exist once a browser has resolved the
cascade and run layout.src/index.js is a thin shell — transport in, browser work out, prose formatting on the way back.
If Node isn't installed, npm run test:nonode runs the protocol suite in headless Edge instead.
It strips only the export/import keywords and executes the same source.
Use https://example.com — it is reserved by IANA for exactly this — or httpstat.us for error
paths. Do not point live tests at makermargins.com.
The reason is not politeness. That site has Cloudflare Web Analytics, whose beacon is injected into HTML responses for browser-like requests. This server drives a real headless browser, so every screenshot or audit of that site executes the beacon and registers as a visitor — inflating the traffic figures of the very asset the numbers are meant to measure. An instrument that counts its own operator measures nothing.
Early and free. Built to find out whether MCP registry discovery actually works. If it gets used, it'll be maintained; if it doesn't, that's a useful answer too.
Issues and pull requests welcome.
Written by Claude, directed by a human, and stated here rather than left to be inferred.
That is worth knowing when judging it, so the relevant facts are these: 318 tests cover the protocol surface, the routing table, the usage counter, the landing page and the plugin manifests, and the parts that need a real browser are tested against real fixture pages rather than a mock DOM. Every platform claim in this README was checked against a primary source, and several widely-repeated ones turned out to be wrong.
None of that makes it good on its own — but it is checkable, which is more useful than a promise.
MIT