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., "@getsnap-mcp Screenshot stripe.com on mobile and tell me if anything overlaps."
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.
Official MCP server for getSnap.dev. Gives Claude and other agents the ability to capture a web page, compare two pages and audit one for accessibility.
The capture tools return the image itself, not a link to it. A model can look at the page it just asked for, so "screenshot this and tell me what's broken" works in a single turn.
No install step. Your client runs it with npx.
Get a free API key at getsnap.dev — 100 captures a month, no card.
claude mcp add getsnap --env GETSNAP_API_KEY=sk_live_... -- npx -y getsnap-mcpclaude_desktop_config.json:
{
"mcpServers": {
"getsnap": {
"command": "npx",
"args": ["-y", "getsnap-mcp"],
"env": { "GETSNAP_API_KEY": "sk_live_..." }
}
}
}The same block works in any client that speaks MCP over stdio.
Related MCP server: claude-vision-mcp
Tool | Credits | Returns |
| 1 | The image, inline |
| 1 | A link — a PDF can't be shown to a model |
| 2 | Similarity score + the diff overlay, inline |
| 1 | WCAG violations by severity |
| 0 | Credits used and remaining |
Cookie banners and ad overlays are removed by default on captures. Cached responses cost nothing and say so.
Large images are not inlined. Past about 1.5 MB the capture still
happened and is still on the CDN, so the tool returns the link and says
why. A full_page capture of a long page will usually hit this — pass
format: "jpeg" or full_page: false to get it inline instead.
Every capture spends a credit, so each tool description states its cost. An agent deciding whether to call something should be able to see what it will cost before it does.
compare_pages costs 2, because it launches a browser per URL.
Variable | Required | Default |
| yes | — |
| no |
|
Without a key the server exits immediately with a message explaining where to get one, rather than starting and failing on first use.
Once connected, ask your agent in plain language:
"Screenshot stripe.com on mobile and tell me if anything overlaps."
"Compare our staging site against production and show me what moved."
"Audit example.com for accessibility and list the critical failures."
"How many getSnap credits do I have left?"
This package versions independently of the getSnap REST API and the Node and Python SDKs. It shared their number until 1.14.3, when it moved out of the API monorepo into this repository; from here it moves on its own schedule.
MIT licensed. Issues to support@getsnap.dev.
Run axe-core against a URL in a real browser and return WCAG 2.0/2.1/2.2 violations by severity, with the elements responsible. Costs 1 credit per call. Returns structured findings rather than an image, so you can act on them directly.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| max_violations | No | Cap on violations returned, so a bad page does not flood the context |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations it discloses the engine (axe-core), that execution happens in a real browser, the WCAG versions checked, and a credit cost per call, which is genuine added context. It omits things like expected runtime/timeouts or whether the audit covers only the given URL or linked pages.
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?
Three short sentences with the core action, the output shape, and the cost, all front-loaded. No filler or 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?
With no output schema, the description does the necessary work by naming the return structure (violations grouped by severity with offending elements). Small gap: it doesn't clarify whether passing rules/incomplete checks are included or the shape of each finding.
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 only 50%: max_violations is documented in the schema itself and the description adds nothing about its default or cap semantics, while url has no schema description and is only implicitly explained by 'against a URL in a real browser'. Baseline 3 is appropriate since the schema does most of the work.
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 (run axe-core against a URL) plus the exact output (WCAG 2.0/2.1/2.2 violations by severity with responsible elements). The line 'returns structured findings rather than an image' explicitly separates it from the capture_screenshot and capture_pdf siblings.
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?
It implicitly routes the agent to this tool when actionable findings are needed instead of a visual artifact ('so you can act on them directly'), and the 'costs 1 credit per call' note gives a selection signal. It does not explicitly say when not to use it, nor position it against compare_pages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a URL to PDF and return a link to it. Costs 1 credit per call. A PDF cannot be shown to you inline - use capture_screenshot if you need to read the page yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to render | |
| delay | No | ||
| full_page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds two genuinely useful facts: the per-call credit cost and the fact that the PDF output is not readable inline. That is good extra context, but it says nothing about latency, the effect of the delay setting, or whether the returned link is temporary or durable – all of which matter for a rendering tool that costs money.
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?
Three short sentences with the action, cost, and alternative in descending priority. No filler and no repetition of the schema.
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?
There is no output schema, and the description adequately covers the return value ('a link to it'). However, for a 3-parameter tool where two parameters are undocumented in the schema, the description should explain delay and full_page, and it does not.
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 only 33% – 'delay' and 'full_page' carry no per-parameter documentation at all, and the description does not fill that gap. 'Render a URL to PDF' only loosely implies full-page behavior; nothing explains what delay controls (a wait before capture, presumably) or its units.
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 first sentence names a specific verb and resource ('Render a URL to PDF') and states the return value ('a link to it'), so an agent knows exactly what calling it produces. It also distinguishes itself from capture_screenshot in the same breath.
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?
It gives an explicit selection rule: use capture_screenshot instead 'if you need to read the page yourself', because a PDF is not shown inline. It also reveals the 1-credit cost, which is a real routing signal against the check_usage sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a URL in a real browser and return the image, so you can see the page. Removes cookie banners and ad overlays by default. Costs 1 credit per call. Use full_page for the whole scrollable page, or device to emulate a phone or tablet.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page to capture | |
| delay | No | Extra wait in ms after load, for late content | |
| device | No | desktop | |
| format | No | jpeg is markedly smaller and usually enough to read a layout | png |
| full_page | No | Capture the whole scrollable page, not just the viewport | |
| return_image | No | false returns only the CDN URL, which keeps a large capture out of the context window | |
| viewport_width | No | ||
| viewport_height | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds genuinely non-obvious behavior: cookie banners and ad overlays are removed by default (the captured page is not raw), each call costs 1 credit, and return_image=false keeps large captures out of the context window. It stops short of disclosing auth/crawl restrictions or failure modes for unreachable URLs.
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?
Four short sentences: purpose first, default side effect second, cost third, parameter tips last. Nothing is repeated verbatim from the schema and each sentence changes what the agent would do.
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 8-parameter open-world tool with no output schema, the description covers the essentials an agent needs: what comes back (an image), the credit cost, the default cleanup behavior, and the context-window escape hatch. The two viewport parameters remain unexplained anywhere, which is the only notable hole.
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 63%, and the schema already documents delay, format, full_page, and return_image well. The description adds real value for `device`, whose enum has no schema description, by explaining it emulates a phone or tablet, but viewport_width/height and format go unmentioned in prose, leaving the description roughly at baseline.
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?
"Render a URL in a real browser and return the image" is a specific verb + resource + output, and the phrase "so you can see the page" frames the agent-facing benefit. It implicitly separates itself from capture_pdf and audit_accessibility by promising an image, but never names the sibling tools the way a 5 would.
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 tells the agent how to use two parameters (full_page, device) but never says when to pick this over compare_pages, capture_pdf, or audit_accessibility, nor when not to call it (e.g. pages requiring auth or JS-heavy SPAs). Usage is implied by the parameter tips rather than stated as selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many credits are used and remaining on this key this period. Free - spends no credit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description's added value is the cost disclosure ('spends no credit') and the scope ('this key', 'this period'), which are not in structured fields. It does not say what the response looks like or how the period is defined, which keeps it below a 5.
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, front-loaded with what it returns and followed by the cost reassurance. Nothing is 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 a zero-parameter read-only tool with annotations covering safety, this covers purpose, scope and cost. Only the definition of 'this period' (billing cycle?) and the shape of the returned figures are unaddressed.
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?
The tool takes zero parameters, which sets the baseline at 4. The description correctly implies no inputs are needed by saying it reports on 'this key' implicitly derived from auth.
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 resource and metric: credits used and remaining on this key for the current period. The verb is implicit (it reports rather than acts), and the sibling tools are all page/screenshot utilities, so confusion is unlikely.
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?
'Free - spends no credit' gives the agent a clear reason to call it freely, and 'this key' scopes the target. However, there is no explicit when-to-use or when-not guidance, nor any statement of what period boundary applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture two URLs and compare them pixel by pixel. Returns a similarity score and an overlay image marking what changed, which you can look at. Costs 2 credits - it launches a browser per URL. Use for staging against production, or a page before and after a change.
| Name | Required | Description | Default |
|---|---|---|---|
| after_url | Yes | ||
| full_page | No | ||
| threshold | No | Per-pixel colour tolerance. Higher ignores more, e.g. antialiasing differences. | |
| before_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely non-obvious cost detail: 2 credits because a browser is launched per URL. It also describes the return payload (similarity score plus overlay image). Missing are timeout or failure behavior for unreachable URLs, which is a real risk for an open-world browser 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?
Three tight sentences, front-loaded with the action and output, then the cost, then the use cases. No filler or restated title text.
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?
With no output schema, the description helpfully explains what comes back, and it discloses the credit cost. It falls short only on the undocumented full_page parameter and on error/timeout behavior for an open-world capture 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 only 25% — only threshold is documented in-schema. The description implies the before/after URL pairing semantics but adds nothing about full_page, and the phrase "pixel by pixel" only loosely gestures at how threshold behaves.
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 pair ("capture two URLs and compare them pixel by pixel") plus the return artifacts (similarity score, overlay image). The dual-URL comparison framing inherently separates it from capture_screenshot and capture_pdf, which take a single target.
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?
Gives two concrete usage scenarios: staging vs production, and before/after a change. It does not explicitly say when to prefer capture_screenshot instead, but the dual-URL requirement makes the boundary reasonably evident.
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.14.5audit_accessibilitycapture_pdfcapture_screenshotcheck_usagecompare_pagesScored across 5 tools
Each tool has a clearly distinct purpose: capture (screenshot/pdf), compare two pages, audit accessibility, and check credits. The only potential overlap—capture_screenshot vs capture_pdf vs compare_pages, all of which render URLs—is resolved explicitly in descriptions (e.g., PDF can't be shown inline, compare diffs two pages).
All tools follow a consistent snake_case verb_noun convention: compare_pages, audit_accessibility, capture_screenshot, capture_pdf, check_usage. The shared capture_ prefix is used sensibly for the two rendering tools.
Five tools is well-scoped for a page-capture/audit service, with no filler. Each tool earns its place and covers a distinct capability.
Core lifecycle is covered: screenshot, PDF, comparison, accessibility audit, and credit usage. Minor gaps exist (e.g., no HTML/text extraction or element-scoped capture beyond device/full_page params), but agents can work around these.
Screenshot, PDF and HTML-to-image rendering API so Claude and Cursor can see any web page.
Screenshot, PDF and HTML-to-image rendering API so Claude and Cursor can see any web page.
Hosted browser for agents: open pages, search the web, extract data, read PDFs and take screenshots.
Generate images, GIFs, videos, and PDFs from HTML, URLs, or templates — from your AI agent.
