site-shot-mcp
OfficialThis server lets AI agents capture website screenshots as images via Site-Shot.
Take viewport or full-page screenshots of any public URL with real Chromium rendering.
Choose PNG, JPEG, or WebP output and set viewport width/height.
Render through country proxies using two-letter ISO codes, with optional strict-country error handling.
Automatically remove ads and cookie banners for cleaner images and fewer vision tokens.
Override language, time zone, geolocation, add extra wait time, and cap maximum capture height.
Return screenshots directly as MCP image tool results for use in Claude, Cursor, Cline, and other MCP clients.
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., "@site-shot-mcpCapture a full-page screenshot of https://news.ycombinator.com"
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.
Site-Shot MCP server
Give Claude, Cursor, and other AI agents the ability to see public web pages — take website screenshots with Site-Shot over the Model Context Protocol.
Real Chromium rendering · full-page capture · country proxies · automatic ad & cookie-banner removal (cleaner images, fewer vision tokens).
A Site-Shot API key is required, and it takes a paid Site-Shot API plan: captures draw on that account's existing API allowance and limits. The key comes from your Site-Shot dashboard; pricing lists the plans. The no-signup browser tool at https://www.site-shot.com/ is for checking output quality; it does not issue keys.
Claude Code (plugin)
This repository doubles as a Claude Code plugin marketplace. The plugin runs the published
site-shot-mcp package over stdio and declares the API key as a required sensitive setting, so
Claude Code prompts you for it rather than asking you to paste it into this repository, a config
file, or a chat message.
Install
claude plugin marketplace add site-shot/site-shot-mcp
claude plugin install site-shot@site-shotor from inside a session:
/plugin marketplace add site-shot/site-shot-mcp
/plugin install site-shot@site-shotBoth forms resolve the marketplace from GitHub, so they work only after these manifests are published on the repository's public default branch — not from a local branch or a fork you have not pushed.
Try it before that
Load the plugin directory for a single session:
claude --plugin-dir /absolute/path/to/site-shot-mcp/plugins/site-shotTwo things matter here. Pass an absolute path — --plugin-dir is resolved against the session's
working directory. And start that session from an ordinary project directory, not from this
checkout: this repo is the site-shot-mcp package, so npm resolves the name locally, finds no
linked binary, and the server dies with sh: site-shot-mcp: command not found before Claude Code
ever sees it. From an unrelated directory npx fetches the published package and starts it
normally — checked both ways: exit 127 in this checkout, clean stdio start from an empty one.
To exercise the real install path instead — marketplace resolution, manifests and the required setting — add the checkout itself as a marketplace:
claude plugin marketplace add /absolute/path/to/site-shot-mcp
claude plugin install site-shot@site-shotThat installs into your user scope; undo it with claude plugin uninstall site-shot@site-shot and
claude plugin marketplace remove site-shot.
The API key
The plugin declares SITESHOT_API_KEY as a required, sensitive setting. Claude Code prompts you for
the key, masks it as you type, and substitutes it into the server's environment as
${user_config.SITESHOT_API_KEY}. Storage of the value is Claude Code's to handle.
Installing without one is not an error — Claude Code records it as still owed
(1 userConfig option not yet set (1 required)). Supply it through the masked prompt:
/plugin configure site-shot@site-shotConfigure it before expecting a capture: that setting is what feeds the server its key. What Claude Code does while it is unset — whether the server is launched at all, whether the tools are offered — is Claude Code's own behaviour and is not something documented here from observation.
The server's side is independent of that. When run directly over stdio without a key, it still starts and prints a warning on stderr. Capture tools return a clear missing-key error instead of an image.
The plugin adds one skill (site-shot:website-screenshots) and the two capture tools
below. It declares no hooks, no monitors and no scheduled capture jobs; the only process
it launches is the declared stdio MCP server.
Related MCP server: Webpage Screenshot MCP Server
Codex CLI (plugin)
This repository is also a Codex plugin marketplace. It installs the same plugin directory as Claude
Code does — one shared skill, the same pinned site-shot-mcp@1.2.0 over stdio — with its own
manifest, because the two hosts wire the credential differently.
Install
codex plugin marketplace add site-shot/site-shot-mcp
codex plugin add site-shot@site-shotExercised against Codex CLI 0.147.0 on macOS (arm64). As with Claude Code, these resolve the
marketplace from GitHub, so they work only once these manifests are on the public default branch;
before that, point codex plugin marketplace add at a local checkout path instead.
Installing is not the same as being configured, and neither is the same as a capture succeeding. Installation only puts the manifests in place. The server still needs the key below, and a capture still needs a Site-Shot plan with allowance left on it.
The API key
Codex forwards the variable named in the plugin's descriptor:
{ "command": "npx", "args": ["-y", "site-shot-mcp@1.2.0"], "env_vars": ["SITESHOT_API_KEY"] }env_vars is an allow-list of names, not values: no key appears in this descriptor, in the command
below, or in the manual config.toml entry further down. You provision the key in the environment
of the session you start Codex from.
macOS defaults to zsh, where read -p starts a coprocess rather than printing a prompt — and a
bash-labelled code fence does not change the shell you paste into. Invoke bash explicitly:
bash -c 'read -r -s -p "Site-Shot API key: " SITESHOT_API_KEY && printf "\n" && export SITESHOT_API_KEY && exec codex'-s keeps the key off the screen, nothing here puts it in argv, and the export is scoped to that
child session instead of lingering in the shell you typed from.
What this does not do is configure a Codex you start some other way. A desktop launcher or a remote session begins from its own environment, so it will run the server without a key until you provision one there too.
Manual MCP setup instead
If you would rather not install the plugin, the same stdio server can be configured by hand. This is an alternative to the plugin, not an addition — run both and you have two configurations of one server. Pick one.
[mcp_servers.site-shot]
command = "npx"
args = ["-y", "site-shot-mcp@1.2.0"]
env_vars = ["SITESHOT_API_KEY"]codex mcp add site-shot -- npx -y site-shot-mcp@1.2.0 writes that entry for you; add env_vars
afterwards, since codex mcp add --env KEY=VALUE would store the key in the file in clear text.
Check it with codex mcp get site-shot. If you already have an entry like this and now install the
plugin, remove the manual one deliberately with codex mcp remove site-shot — nothing here edits
your configuration for you.
Either route, the caveat from the Claude Code section applies: unless the entry sets cwd, Codex
starts the server from wherever you ran Codex, so running it inside this repo hits the same
local-name collision.
Claude Desktop & other MCP clients
Get a Site-Shot API key at https://www.site-shot.com/start/.
Add this to your Claude Desktop config (
claude_desktop_config.json):
{
"mcpServers": {
"site-shot": {
"command": "npx",
"args": ["-y", "site-shot-mcp"],
"env": { "SITESHOT_API_KEY": "YOUR_API_KEY" }
}
}
}Restart Claude Desktop. Ask it to "take a full-page screenshot of https://news.ycombinator.com" and it will call the server and show you the image.
Works the same way in any MCP client (Cursor, Cline, VS Code, LangChain, CrewAI) — point the client at
npx -y site-shot-mcp with SITESHOT_API_KEY in the environment.
Every integration above runs the same local stdio server, and that package is published on npm and in the official MCP Registry. It is not listed in the shared ChatGPT/Codex public plugin directory or in Claude's remote connector directory: both of those routes take a hosted HTTPS MCP endpoint, which Site-Shot has not deployed. Doing so is a separate decision.
Tools
Two tools, both returning the screenshot as an MCP image. There is no saved library, no listing, no markdown conversion and no scheduling — this server captures images and hands them back.
capture_screenshot
Screenshot a web page (viewport by default).
Param | Type | Default | Notes |
| string (required) | — | Page to capture |
| boolean |
| Capture the whole scrollable page |
| number | API default | Viewport / device size |
|
|
| Image format. |
| boolean |
| Remove ads |
| boolean |
| Remove cookie-consent popups |
| string | — | Proxy country as a two-letter ISO 3166-1 alpha-2 code, e.g. |
| boolean |
| Error out if the country has no proxy, instead of falling back to the US |
| string | — | Manual overrides |
| number | API default | Extra wait before capture (SPAs/animations) |
| number | 20000 (full page) | Cap captured height |
Returns the screenshot as an MCP image.
"API default" is not a number this package gets to state.
width,heightandwait_msare forwarded only when you pass them, so whatever applies when you don't is decided by the Site-Shot API and can change without a release here. Versions up to 1.1.0 printed pixel sizes forwidth/heightthat the API does not use — an agent that omitted them to take "the default" got a different viewport, with nothing in the returned image to reveal it. Pass explicit values whenever the size matters.
Country codes are ISO codes, never names. Pass
"DE", not"Germany". The API matches codes exactly and would otherwise render through a US proxy without telling you, so the server rejects full names before spending a render.strict_country(on by default) likewise turns an unavailable country into an error instead of a silent US screenshot — passfalseto opt back into the fallback. Supported countries →
capture_full_page
Same as capture_screenshot with full-page capture enabled.
Why call this server instead of the agent's own browser?
If your agent drives a browser, it can screenshot pages itself — and for pages that must be signed
into or stepped through a flow, that is the right tool. For public URLs, delegating the capture to
this server is usually better engineering: every capture runs the same pipeline (no re-planning
between runs), can be taken from a specific country with matching locale and time zone
(country + strict_country), is scored by an image classifier with an escalating retry ladder
behind it before being returned, and costs a fraction of a cent instead of a browser session plus
vision tokens per look. The full comparison, both directions honestly argued:
AI agent vs. screenshot API — who should capture the page.
Configuration
Env var | Required | Description |
| yes | Your Site-Shot API key (used as |
The server is a thin wrapper over the existing Site-Shot HTTP API (https://api.site-shot.com/) — no
separate backend.
Local development
npm install
npm run check # syntax check
npm run smoke # offline tests (stubbed fetch, no API key needed)
node test/integration.mjs # real stdio handshake against the local source
npm run test:plugin # plugin/marketplace metadata tests
npm run validate:plugin # claude plugin validate --strict (needs the claude CLI)
SITESHOT_API_KEY=yourkey npm start # run the server on stdioRequirements
Node.js ≥ 18 (uses the built-in fetch).
License
MIT
Available Tools
2 toolscapture_full_pageCapture full-page website screenshotA
Take a full-page (entire scrollable height) screenshot of a web page with Site-Shot and return it as an image. Convenience wrapper around capture_screenshot with full-page capture enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the web page to capture. A bare domain like example.com is accepted (https:// is assumed). | |
| width | No | Viewport width in pixels (default 1280). | |
| height | No | Viewport height in pixels (default 1024). | |
| format | No | Image format. Default: png. | |
| block_ads | No | Remove ads for a cleaner screenshot. Default: true. | |
| block_cookie_banners | No | Remove cookie-consent banners/popups. Default: true. | |
| country | No | Render through a proxy in this country, e.g. "Germany" (auto-sets IP, language, time zone, geolocation). | |
| language | No | Override browser language, e.g. "de". | |
| time_zone | No | Override time zone, e.g. "Europe/Berlin". | |
| geolocation | No | Override geolocation as "lat,lng". | |
| wait_ms | No | Milliseconds to wait after load before capturing (for SPAs/animations). | |
| max_height | No | Cap the captured height in pixels (max 20000). |
TDQS
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 describes the action as a wrapper but does not disclose side effects, output format details, or limitations beyond what the schema parameters cover.
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 sentences with no wasted words; the core purpose is front-loaded.
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?
Given the tool has 12 parameters (all well-described in schema) and no output schema, the description is adequate as a summary but lacks details on return format and additional behavioral context.
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% with detailed parameter descriptions, so the description adds little extra meaning. Baseline score of 3 is appropriate.
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 clearly states the tool takes a full-page screenshot and mentions it's a convenience wrapper around capture_screenshot with full-page capture enabled, distinguishing it from the sibling tool.
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 for full-page screenshots and references the sibling tool, but does not explicitly state when not to use it or provide alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
capture_screenshotCapture website screenshotB
Take a screenshot of a web page with Site-Shot and return it as an image. Renders in a real Chromium browser. Supports viewport/device sizing, full-page capture, country proxies, and automatic ad & cookie-banner removal (cleaner image, fewer vision tokens).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the web page to capture. A bare domain like example.com is accepted (https:// is assumed). | |
| width | No | Viewport width in pixels (default 1280). | |
| height | No | Viewport height in pixels (default 1024). | |
| format | No | Image format. Default: png. | |
| block_ads | No | Remove ads for a cleaner screenshot. Default: true. | |
| block_cookie_banners | No | Remove cookie-consent banners/popups. Default: true. | |
| country | No | Render through a proxy in this country, e.g. "Germany" (auto-sets IP, language, time zone, geolocation). | |
| language | No | Override browser language, e.g. "de". | |
| time_zone | No | Override time zone, e.g. "Europe/Berlin". | |
| geolocation | No | Override geolocation as "lat,lng". | |
| wait_ms | No | Milliseconds to wait after load before capturing (for SPAs/animations). | |
| max_height | No | Cap the captured height in pixels (max 20000). | |
| full_page | No | Capture the entire scrollable page instead of just the viewport. Default: false. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the tool renders in a real Chromium browser and automatically removes ads and cookie banners, which is helpful. However, it does not mention potential side effects, rate limits, execution time, or authentication requirements. It also does not clarify whether the screenshot is destructive or what happens to the browser instance after capture.
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?
The description is two sentences long, making it relatively concise. The first sentence states the core action, and the second lists major features. It avoids extraneous details but could be slightly more compact by combining the two sentences or trimming the feature list slightly.
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?
Given the complexity of the tool (13 parameters, no output schema), the description provides a high-level overview of capabilities but lacks detail on return format (e.g., image type, resolution), error handling, and how features like 'full_page' work in practice. It is adequate for an experienced user but incomplete for a novice.
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 input schema covers all 13 parameters with descriptions, achieving 100% coverage. The tool description reiterates some schema concepts (viewport sizing, full-page capture, country proxies) but does not add significant new meaning beyond what the schema already provides. For example, 'country' parameter is explained in the schema; the description only mentions 'country proxies' generically. Baseline 3 is appropriate.
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 clearly states it takes a screenshot of a web page using Site-Shot and returns an image. It mentions features like viewport sizing, full-page capture, and ad removal. However, it does not explicitly distinguish itself from the sibling tool 'capture_full_page', which may cause confusion.
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 lists features but provides no guidance on when to use this tool versus alternatives like 'capture_full_page'. It does not mention any prerequisites or conditions for use, nor does it explain when to use the 'full_page' parameter or when to prefer a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v1.0.1- Changed
capture_full_page3 fields changed- changed
Input schema / properties / url / descriptionPrevious value: -"The URL of the web page to capture."New value: +"The URL of the web page to capture. A bare domain like example.com is accepted (https:// is assumed)." - removed
Input schema / properties / url / formatRemoved value: -"uri" - added
Input schema / properties / url / minLengthAdded value: +1
- Changed
capture_screenshot3 fields changed- changed
Input schema / properties / url / descriptionPrevious value: -"The URL of the web page to capture."New value: +"The URL of the web page to capture. A bare domain like example.com is accepted (https:// is assumed)." - removed
Input schema / properties / url / formatRemoved value: -"uri" - added
Input schema / properties / url / minLengthAdded value: +1
2 tool updates
v0.1.1- First observed
capture_full_page - First observed
capture_screenshot
TDQS
Scored across 2 tools
The two tools are nearly identical; capture_full_page is explicitly a wrapper for capture_screenshot with full-page enabled. An agent would likely misuse them, as the difference is only a parameter.
Both use verb_noun pattern ('capture_screenshot', 'capture_full_page'), but 'full_page' is a qualifier while 'screenshot' is the resource; inconsistent because one tool name specifies a parameter in the name itself.
Two tools is minimal but arguably sufficient for a simple screenshot service. However, the duplication suggests one tool could have been omitted, making the surface slightly too heavy for the scope.
The set covers basic screenshot needs with features like viewport sizing, proxies, and ad removal. However, it lacks tools for specific device emulation or batch processing, which are common in screenshot services.
Maintenance
Related MCP Connectors
Generate images, GIFs, videos, and PDFs from HTML, URLs, or templates — from your AI agent.
Screenshot any website with one API call PNG, JPEG, WebP, or PDF. Custom viewports, device emulation, ad blocking, dark mode, and smart caching.
Desktop and mobile website screenshots plus page context for AI agents and automation workflows.
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
Related MCP Servers
- AlicenseBqualityBmaintenanceAn official MCP server implementation that allows AI assistants to capture website screenshots through the ScreenshotOne API, enabling visual context from web pages during conversations.113 npm36MIT
- AlicenseAqualityDmaintenanceCaptures screenshots of web pages using Puppeteer, allowing AI agents to visually verify web applications and see their progress when generating web apps.558MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to capture screenshots of web pages using automated browser sessions. Supports full-page and element-specific screenshots, device simulation, and JavaScript execution for comprehensive web testing and monitoring.65 npmMIT
- AlicenseCqualityDmaintenanceEnables taking screenshots of web pages with support for multiple devices (desktop, mobile, tablet), custom dimensions, full-page capture, and various image formats. Built with Playwright for reliable web page rendering and screenshot generation.1MIT