Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@screenshotty-mcp Screenshot https://example.com and tell me what's broken on mobile"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol server for the Screenshotty screenshot API. Lets Claude, Cursor, Cline, and any other MCP client capture web pages — or render HTML — as images or PDFs, and see the result, since images come back inline.
Sign up at https://screenshotty.link/sign-up?utm_source=mcp (250 screenshots/month free, no credit card) and copy a key from Dashboard → API Keys.
Related MCP server: pursr-mcp
claude mcp add screenshotty --env SCREENSHOTTY_API_KEY=your_key -- npx -y screenshotty-mcp{
"mcpServers": {
"screenshotty": {
"command": "npx",
"args": ["-y", "screenshotty-mcp"],
"env": {
"SCREENSHOTTY_API_KEY": "your_key"
}
}
}
}Claude Desktop config lives at ~/Library/Application Support/Claude/claude_desktop_config.json
(macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows).
Tool | What it does |
| Screenshot a page (PNG, JPEG, WebP). Returns the hosted URL, plus the image inline when it is 2 MB or smaller. Options: viewport, full page, CSS selector, wait, ad blocking, cookie-banner blocking, light/dark mode, device scale factor. |
| Render an HTML document (inline CSS/JS; public http(s) assets only) to PNG, JPEG, or WebP — social cards, charts, email previews. Returns the URL plus the image inline. |
| Render a page ( |
Example prompts: "Screenshot https://example.com on a 390px-wide viewport and tell me what's broken on mobile", "Save our pricing page as a PDF", "Design a 1200×630 Open Graph card for this blog post and render it".
Variable | Required | Default |
| yes | — |
| no |
|
npm install
npm run build
SCREENSHOTTY_API_KEY=your_key npx @modelcontextprotocol/inspector node dist/index.jsMIT
Render a web page (url) or an HTML document (html) to a PDF. Returns the hosted PDF URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page to capture (http:// or https://) | |
| html | No | HTML document to render instead of a URL | |
| adblock | No | Block ads | |
| printed | No | Use the print stylesheet. Default true | |
| wait_ms | No | Extra wait before capturing, in ms | |
| light_mode | No | Force light or dark color scheme | |
| viewport_width | No | Viewport width in pixels. Default 1920 | |
| viewport_height | No | Viewport height in pixels. Default 1080 | |
| block_cookie_banner | No | Hide cookie consent banners |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the return value ('hosted PDF URL'), which no output schema covers, but says nothing about render timeouts, async/polling behavior, auth or rate limits for a 9-parameter rendering tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste, with the action and input modes front-loaded and the return value folded into the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return format is covered even without an output schema, but with 0 required parameters the description should resolve which of url/html is expected and whether they are mutually exclusive; it only implies this. No annotation coverage exists to fill the behavioral gap for a fairly rich rendering tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all nine parameters including adblock, printed, wait_ms and viewport dimensions are already documented in the schema; baseline 3 applies. The description only names the url and html params and adds the 'instead of' exclusivity hint, which is marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Render) and resource (web page/HTML → PDF), and the two input modes are named directly. The PDF output distinguishes it from screenshot_url/screenshot_html, but the siblings are never named, so differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the '(url)' and '(html)' cues and the phrase 'instead of a URL', which hints at mutual exclusivity. However, it never states when to choose PDF generation over the screenshot siblings, nor what happens if both or neither of the two input params are supplied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an HTML document (inline CSS/JS allowed, public http(s) assets only) to an image — e.g. social cards, charts, email previews. Returns the hosted image URL and the image itself when it is 2 MB or smaller.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | Complete HTML document or fragment to render | |
| format | No | Image format. Default png | |
| adblock | No | Block ads | |
| wait_ms | No | Extra wait before capturing, in ms | |
| selector | No | CSS selector of a single element to capture | |
| full_page | No | Capture the whole scrollable page. Default true | |
| light_mode | No | Force light or dark color scheme | |
| viewport_width | No | Viewport width in pixels. Default 1920 | |
| viewport_height | No | Viewport height in pixels. Default 1080 | |
| block_cookie_banner | No | Hide cookie consent banners | |
| device_scale_factor | No | 1 = standard, 2 = retina, 3 = high-dpi | |
| transparent_background | No | Transparent background (PNG/WebP only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose two meaningful traits: only public http(s) assets are fetched (no local/private resources), and the inline preview image is returned only when it is 2 MB or smaller while the hosted URL is always returned. Auth requirements, rate limits, and timeout behaviour remain undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences: capability plus content constraints first, return behaviour second. Zero filler and no restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter rendering tool with no output schema, the description covers the essential unknowns: what input is accepted, what external resources resolve, and what the caller receives (hosted URL plus conditional inline image). Remaining parameter detail is fully carried by the schema, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds semantics the schema doesn't: inline CSS/JS is executed and external assets must be publicly reachable http(s) URLs, which directly qualifies how the required 'html' parameter is handled. It adds no per-parameter overrides for format, selector, wait_ms, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Render an HTML document ... to an image') plus concrete artefact types (social cards, charts, email previews). It implicitly separates itself from screenshot_url by taking HTML source rather than a URL, but never names the sibling, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example outputs (social cards, charts, email previews) give clear context for when this tool fits, and the '(inline CSS/JS allowed, public http(s) assets only)' constraint pre-empts a wrong invocation. It does not state when to prefer screenshot_url or generate_pdf instead, so there are no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of a web page. Returns the hosted image URL and, for images up to 2 MB, the image itself so you can see the page.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page to capture (http:// or https://) | |
| format | No | Image format. Default png | |
| adblock | No | Block ads | |
| wait_ms | No | Extra wait before capturing, in ms | |
| selector | No | CSS selector of a single element to capture | |
| full_page | No | Capture the whole scrollable page. Default true | |
| light_mode | No | Force light or dark color scheme | |
| viewport_width | No | Viewport width in pixels. Default 1920 | |
| viewport_height | No | Viewport height in pixels. Default 1080 | |
| block_cookie_banner | No | Hide cookie consent banners | |
| device_scale_factor | No | 1 = standard, 2 = retina, 3 = high-dpi |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does disclose a useful non-obvious trait: it returns a hosted image URL and the image itself only up to 2 MB. That is genuine added value. However, it says nothing about permissions, rate limits, or failures on non-renderable pages, so coverage is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste, with the core action front-loaded ahead of the return-value note. Nothing redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter tool with no annotations and no output schema, the description covers the essential minimum: what it does and what it returns. It omits usage routing against the two siblings and any behavioral caveats, leaving clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 11 parameters are already documented (defaults, ranges, enums) in the schema. The description adds no parameter-level detail beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ("Capture a screenshot of a web page"), which is clear and actionable. It implies differentiation from screenshot_html (a URL vs HTML content) and generate_pdf, but never names or contrasts those siblings explicitly, so it stops short of full sibling discrimination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over screenshot_html or generate_pdf, no mention of prerequisites or auth, and no exclusions. The agent must infer the choice entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.0generate_pdfscreenshot_htmlscreenshot_urlScored across 3 tools
Each tool has a clearly distinct output type and input: screenshot_url captures web pages as images, screenshot_html renders HTML to images, and generate_pdf produces PDFs from either URL or HTML. The names unambiguously indicate the result format, so an agent can easily select the right tool.
All three tools use a consistent snake_case verb_noun pattern. The slight variation between 'screenshot' and 'generate' verbs is natural and does not break the predictable structure.
Three tools cover the core purpose without redundancy: two input types for images and one combined tool for PDF output. This minimal set is well-scoped and each tool earns its place.
The surface covers all key combinations: URL to image, HTML to image, and URL/HTML to PDF. No obvious operations are missing for a screenshot and PDF generation service.
Screenshot, PDF, OG-image, and page extraction (markdown/JSON) over MCP. Bearer key or x402.
Clean PNG/JPEG screenshots via REST or MCP, with goal-driven multi-step navigation.
Screenshots of any public web page as PNG, JPEG, WebP, PDF or a scrolling video.
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
