caido-screenshot
This server captures formatted screenshots of Caido Replay request/response pairs using the Screenshot Mode plugin, saving them as PNG files.
Capture screenshots of the current Replay session or a specific session by name (e.g.,
GET /login) or exact ID.Specify output path for the PNG; defaults to
~/Downloads/caido-screenshot-<timestamp>.png.Select sessions inside collections – provide a collection name and session name; the collection is expanded automatically.
Require a rendered response (optional, default true) to avoid capturing request-only sessions or stale previews.
Return the image inline in the tool result (optional, large payload).
Verify session integrity – rejects stale previews and mismatched hosts/paths, normalizing common format variations.
Works as an MCP server for Claude Code, Codex, and any MCP-compatible client.
Includes CLI utilities –
caido-screenshot shot.png,doctor, andlaunchfor starting Caido with the debug port.Use together with other Caido MCP tools – send a request via another server, match the session ID, then capture evidence.
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., "@caido-screenshotscreenshot the current Caido replay session"
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.
caido-screenshot-mcp
An MCP server that captures formatted screenshots of Caido Replay request/response pairs, by driving the Screenshot Mode plugin.
Caido has no screenshot API — Screenshot Mode is a frontend-only plugin that renders the DOM to a PNG in the browser. This server reaches it over the Chrome DevTools Protocol, clicks the plugin's own export, and intercepts the resulting image before Electron can open a save dialog. The output is the plugin's real output, written straight to disk.
Requirements
Node >= 22 (uses the built-in
WebSocket; there are no npm dependencies)Caido desktop
The Screenshot Mode plugin installed in Caido
Caido launched with
--remote-debugging-port(see below)
Related MCP server: MCP Browser Screenshot Server
Install
git clone <this-repo> caido-screenshot-mcp
cd caido-screenshot-mcp
npm link # optional: puts `caido-screenshot` on your PATHNo npm install step — there are no dependencies.
Start Caido with the debug port
The plugin renders inside Caido's window, so the server needs to talk to that window. Launching Caido normally leaves the port closed and every call will fail.
caido-screenshot launch # quits nothing; starts Caido with the port openOr manually:
# macOS
open -a Caido --args --remote-debugging-port=9222
# Linux
caido --remote-debugging-port=9222
# Windows
"%LOCALAPPDATA%\Programs\Caido\Caido.exe" --remote-debugging-port=9222Check everything at once:
caido-screenshot doctorUse with Claude Code
claude mcp add caido-screenshot --scope user -- node /absolute/path/to/caido-screenshot-mcp/src/server.mjsRestart Claude Code. Then just ask: "screenshot the current Caido replay session".
Use with any MCP client
{
"mcpServers": {
"caido-screenshot": {
"command": "node",
"args": ["/absolute/path/to/caido-screenshot-mcp/src/server.mjs"]
}
}
}Tool: caido_screenshot
Parameter | Type | Description |
| string | Where to save the PNG. Default |
| string | Replay collection containing the session. It is expanded automatically. |
| string | Replay session to select first, by sidebar name (e.g. |
| string | Exact Replay session ID. Preferred because it is unambiguous. |
| boolean | Reject request-only sessions and stale previews. Default |
| boolean | Also return the image in the result (large). Default |
Examples
Once the server is registered you never name the tool. Describe what you want in plain English and the agent picks it up.
Just capture what's on screen
screenshot the current Caido replay request
The agent calls caido_screenshot and replies with the saved path:
Saved /Users/you/Downloads/caido-screenshot-2026-08-22T13-40-11-002Z.png (438 KB)Send a request, then capture it
This is the common one. Pair it with the official Caido MCP server, which can send requests — this server captures the result.
send a GET to https://httpbin.org/get in Caido replay and screenshot it
The agent sends the request, maps its returned Replay entry to the populated session, and captures that exact session ID:
Step | Tool | Server |
1 |
| caido |
2 |
| caido |
3 |
| caido-screenshot |
Match caido_send_request.entryId to caido_list_replay_sessions[].activeEntryId.
Do not create a new session from requestSourceId for response evidence: Caido seeds the
request template but does not copy the completed response.
Send a raw request you wrote
Paste the raw HTTP and say what you want:
send this in Caido replay and screenshot it:
POST /post HTTP/1.1 Host: httpbin.org Content-Type: application/json {"user":"demo","token":"abc123"}
Pick a specific session
Sessions are named after the request line in Caido's sidebar, so GET /, POST /login
and so on:
screenshot the "POST /login" replay session
That becomes caido_screenshot(session: "POST /login"). Every capture uses Side by Side.
For reliable automation, use the session ID:
caido_screenshot(session_id: "67", require_response: true)
If the session is inside a different or collapsed collection, name both:
screenshot "01 admin create private conversation" from the "OBS AI Assistant IDOR - Fresh Evidence" collection
That becomes caido_screenshot(collection: "OBS AI Assistant IDOR - Fresh Evidence", session: "01 admin create private conversation"). The tool expands the collection before selecting the session and captures it Side by Side.
Heads up:
caido_send_requestauto-names sessions from the request line, so several targets can all end up calledGET /. Rename a session in Caido before capturing if you need to refer to it unambiguously.
Save somewhere specific
screenshot it and save to ~/reports/login-flow.png
Using it from Codex
Start an interactive session and ask the same way:
codex
> screenshot the current Caido replay sessionCodex asks for approval the first time. To skip the prompt for this tool, add to
~/.codex/config.toml:
[mcp_servers.caido-screenshot.tools.caido_screenshot]
approval_mode = "auto" # auto | prompt | writes | approvecodex exec (non-interactive) will not work — it forces approval: never and refuses
all MCP tool calls, regardless of per-tool settings. Use an interactive session.
CLI
caido-screenshot # current session -> ~/Downloads
caido-screenshot shot.png # explicit path
caido-screenshot shot.png --session "GET /login"
caido-screenshot shot.png --session-id 67
caido-screenshot shot.png --collection "Fresh Evidence" --session "01 admin request"
caido-screenshot doctor
caido-screenshot launchEnvironment
Variable | Default | Description |
|
| Caido's remote debugging port |
|
| Per-call CDP timeout |
Known limitations
These are properties of the plugin, not of this server:
Long content is cut off. Caido's editors are CodeMirror, which only renders the visible lines. Anything taller than the Caido window is not in the DOM and cannot be captured. Very long responses can come out blank; the server errors instead of writing a near-empty file.
Headers can be dropped. The DOM-to-image render sometimes omits lines, with visible gaps in the line numbers. Treat these images as illustrative, not as byte-exact evidence — use Caido's own request export when precision matters.
The layout is fixed to Side by Side. The server deliberately exposes no layout or arrangement option so every evidence screenshot has the same report-ready format.
Screenshots are not redacted. Whatever is on screen —
Authorization,Cookie,Set-Cookie— is captured in full. Review before sharing.Request-only Replay sessions are rejected by default. Screenshot Mode can retain its previous preview when the selected session has no response. Pass
--allow-no-responseonly when a request-only screenshot is intentional.
Troubleshooting
Message | Cause |
| Caido not launched with |
| Click Connect on your local instance in the Caido window. |
| No Replay session open, or the Screenshot Mode plugin isn't installed/enabled. |
| Use the exact collection name shown in the Replay sidebar. |
| The tool expands |
| The selected session was seeded from a request or has not completed. Capture the session whose |
| Screenshot Mode showed a different host/path (or a conflicting visible query). Nothing was saved; retry using the populated |
| Content too long to render. Capture a shorter request/response. |
License
MIT
Available Tools
1 toolcaido_screenshotA
Capture a formatted screenshot of a Caido Replay request/response using the Screenshot Mode plugin. Requires Caido running with --remote-debugging-port (default 9222) and a Replay session open. Uses one consistent Side by Side layout, verifies the selected session, requires a rendered response by default, rejects stale previews, then saves a PNG and returns its path plus the verified request metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| inline | No | Also return the image in the tool result (large). Default false. | |
| session | No | Replay session to select first, by the name shown in the sidebar (e.g. 'GET /login') | |
| out_path | No | Where to save the PNG. Defaults to ~/Downloads/caido-screenshot-<timestamp>.png | |
| collection | No | Replay collection containing the session. The collection is expanded automatically. | |
| session_id | No | Exact Replay session ID. Preferred over session name because it is unambiguous. | |
| require_response | No | Reject sessions without a rendered response to prevent stale evidence. Default true. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of transparency. It discloses multiple behavioral traits: uses a specific layout, verifies the selected session, requires a rendered response by default, rejects stale previews, saves a PNG, and returns path plus metadata. This gives the agent a strong understanding of what happens during execution.
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 concise and well-structured, opening with the core action and then efficiently enumerating prerequisites and key behaviors. It avoids unnecessary verbosity while covering all essential aspects, making it easy for an agent to parse quickly.
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 (multiple preconditions, specific layout, output behavior), the description provides sufficient context for an agent to decide when to use it. It clearly states the environment requirements, what is verified, and what is returned, without needing an output schema. The description is complete enough for operational use.
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 schema provides 100% coverage with detailed descriptions for each parameter, so the baseline is 3. The tool description does not add additional insight beyond the schema's parameter explanations; it merely references the default behavior of require_response without expanding on relationships or interdependencies.
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 captures a formatted screenshot of a Caido Replay request/response using the Screenshot Mode plugin, specifying the exact resource and action. It also distinguishes itself by mentioning the Side by Side layout and the plugin, which sets it apart from generic screenshot tools.
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 provides explicit preconditions for use (Caido running with --remote-debugging-port, Replay session open) and mentions key behaviors (requires rendered response, rejects stale previews). While it doesn't explicitly contrast with alternatives, the specific prerequisites and layout make the intended use case clear.
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.
1 tool update
v1.2.1- First observed
caido_screenshot
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion between tools. The tool has a single, clearly defined purpose (capturing a screenshot of a Caido Replay session), so an agent cannot misselect it.
The single tool follows a consistent snake_case naming convention (caido_screenshot), which is clear and predictable. There is no mix of styles or verbs to create inconsistency.
The server provides only one tool, which feels thin for a typical MCP server. However, the tool targets a very specific, narrow use case (Caido Replay screenshot capture), so the count may be appropriate for that focused purpose, but it is borderline.
The tool covers the core workflow of capturing a formatted screenshot from a Replay session, including verification and metadata return. There are minor gaps (e.g., no options for custom layout or output format), but for its stated purpose, it is essentially complete.
Maintenance
Related MCP Connectors
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
- GrabbitOAuthlive.grabbit
Screenshot any URL as a hosted image. No local browser; handles bot walls and full-page captures.
Capture batches of public web pages in a real browser and download the screenshots as a zip.
Capture screenshots, detect visual regressions between page versions, and analyze with AI.
Related MCP Servers
- AlicenseAqualityAmaintenanceEnables capturing screenshots of web pages and local HTML files through a simple MCP tool interface using Puppeteer with configurable options for dimensions and output paths.2464 npm30Apache 2.0
- 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.68 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
- AlicenseNot gradedqualityCmaintenanceCaptures webpage screenshots via ScreenshotOne API, offering desktop, mobile, and element-specific views.1MIT