caido-screenshot
caido-screenshot-mcp
Caido Replay 요청/응답 쌍의 형식화된 스크린샷을 캡처하는 MCP 서버로, Screenshot Mode 플러그인을 구동합니다.
Caido에는 스크린샷 API가 없습니다. Screenshot Mode는 브라우저에서 DOM을 PNG로 렌더링하는 프론트엔드 전용 플러그인입니다. 이 서버는 Chrome DevTools Protocol을 통해 해당 플러그인에 접근하고, 플러그인의 자체 내보내기 기능을 클릭한 다음, Electron이 저장 대화상자를 열기 전에 결과 이미지를 가로챕니다. 출력은 플러그인의 실제 출력물이며, 디스크에 직접 기록됩니다.
요구 사항
Node >= 22 (내장
WebSocket사용, npm 의존성 없음)Caido 데스크톱
Caido에 Screenshot Mode 플러그인 설치
--remote-debugging-port로 Caido 실행 (아래 참조)
Related MCP server: Webshot MCP
설치
git clone <this-repo> caido-screenshot-mcp
cd caido-screenshot-mcp
npm link # optional: puts `caido-screenshot` on your PATHnpm install 단계 없음 — 의존성이 없습니다.
디버그 포트로 Caido 시작
플러그인은 Caido 창 내부에서 렌더링되므로, 서버는 해당 창과 통신해야 합니다. Caido를 일반적으로 실행하면 포트가 닫혀 있어 모든 호출이 실패합니다.
caido-screenshot launch # quits nothing; starts Caido with the port open또는 수동으로:
# macOS
open -a Caido --args --remote-debugging-port=9222
# Linux
caido --remote-debugging-port=9222
# Windows
"%LOCALAPPDATA%\Programs\Caido\Caido.exe" --remote-debugging-port=9222모든 것을 한 번에 확인:
caido-screenshot doctorClaude Code와 함께 사용
claude mcp add caido-screenshot --scope user -- node /absolute/path/to/caido-screenshot-mcp/src/server.mjsClaude Code를 다시 시작하세요. 그런 다음 간단히 요청하세요: "현재 Caido replay 세션 스크린샷 찍어줘".
다른 MCP 클라이언트와 함께 사용
{
"mcpServers": {
"caido-screenshot": {
"command": "node",
"args": ["/absolute/path/to/caido-screenshot-mcp/src/server.mjs"]
}
}
}도구: caido_screenshot
매개변수 | 유형 | 설명 |
| string | PNG를 저장할 위치. 기본값 |
| string | 세션을 포함하는 Replay 컬렉션. 자동으로 확장됩니다. |
| string | 사이드바 이름으로 먼저 선택할 Replay 세션 (예: |
| string | 정확한 Replay 세션 ID. 모호함이 없어 선호됩니다. |
| boolean | 요청 전용 세션과 오래된 미리보기를 거부합니다. 기본값 |
| boolean | 결과에 이미지도 포함합니다 (용량 큼). 기본값 |
예시
서버가 등록되면 도구 이름을 직접 지정할 필요가 없습니다. 원하는 것을 평범한 영어로 설명하면 에이전트가 알아서 처리합니다.
화면에 있는 것만 캡처
현재 Caido replay 요청 스크린샷 찍어줘
에이전트가 caido_screenshot을 호출하고 저장된 경로로 답변합니다:
Saved /Users/you/Downloads/caido-screenshot-2026-08-22T13-40-11-002Z.png (438 KB)요청을 보낸 다음 캡처
이것이 일반적인 사용법입니다. 공식 Caido MCP 서버와 함께 사용하세요. 해당 서버는 요청을 보낼 수 있고, 이 서버는 결과를 캡처합니다.
Caido replay에서 https://httpbin.org/get에 GET 요청 보내고 스크린샷 찍어줘
에이전트는 요청을 보내고, 반환된 Replay 항목을 채워진 세션에 매핑한 다음, 해당 정확한 세션 ID를 캡처합니다:
단계 | 도구 | 서버 |
1 |
| caido |
2 |
| caido |
3 |
| caido-screenshot |
caido_send_request.entryId를 caido_list_replay_sessions[].activeEntryId와 일치시키세요. 응답 증거를 위해 requestSourceId에서 새 세션을 만들지 마세요. Caido는 요청 템플릿을 시드하지만 완료된 응답은 복사하지 않습니다.
직접 작성한 원시 요청 보내기
원시 HTTP를 붙여넣고 원하는 것을 말하세요:
이것을 Caido replay에 보내고 스크린샷 찍어줘:
POST /post HTTP/1.1 Host: httpbin.org Content-Type: application/json {"user":"demo","token":"abc123"}
특정 세션 선택
세션은 Caido 사이드바의 요청 라인 이름을 따르므로, GET /, POST /login 등으로 표시됩니다:
"POST /login" replay 세션 스크린샷 찍어줘
이것은 caido_screenshot(session: "POST /login")이 됩니다. 모든 캡처는 Side by Side 레이아웃을 사용합니다.
안정적인 자동화를 위해 세션 ID를 사용하세요:
caido_screenshot(session_id: "67", require_response: true)
세션이 다른 컬렉션이나 접힌 컬렉션 안에 있다면 둘 다 지정하세요:
"OBS AI Assistant IDOR - Fresh Evidence" 컬렉션에서 "01 admin create private conversation" 스크린샷 찍어줘
이것은 caido_screenshot(collection: "OBS AI Assistant IDOR - Fresh Evidence", session: "01 admin create private conversation")이 됩니다. 도구는 세션을 선택하기 전에 컬렉션을 확장하고 Side by Side로 캡처합니다.
참고:
caido_send_request는 요청 라인에서 세션 이름을 자동으로 생성하므로, 여러 대상이 모두GET /로 이름이 지정될 수 있습니다. 모호함 없이 참조해야 한다면 캡처 전에 Caido에서 세션 이름을 바꾸세요.
특정 위치에 저장
스크린샷 찍어서 ~/reports/login-flow.png에 저장해줘
Codex에서 사용
대화형 세션을 시작하고 같은 방식으로 요청하세요:
codex
> screenshot the current Caido replay sessionCodex는 처음에 승인을 요청합니다. 이 도구에 대한 프롬프트를 건너뛰려면 ~/.codex/config.toml에 추가하세요:
[mcp_servers.caido-screenshot.tools.caido_screenshot]
approval_mode = "auto" # auto | prompt | writes | approvecodex exec(비대화형)는 작동하지 않습니다 — approval: never를 강제하고 도구별 설정과 관계없이 모든 MCP 도구 호출을 거부합니다. 대화형 세션을 사용하세요.
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 launch환경
변수 | 기본값 | 설명 |
|
| Caido의 원격 디버깅 포트 |
|
| 호출당 CDP 타임아웃 |
알려진 제한 사항
이것들은 플러그인의 속성이며, 이 서버의 문제가 아닙니다:
긴 콘텐츠는 잘립니다. Caido의 편집기는 CodeMirror로, 보이는 줄만 렌더링합니다. Caido 창보다 높은 콘텐츠는 DOM에 없으므로 캡처할 수 없습니다. 매우 긴 응답은 비어 있을 수 있습니다. 서버는 거의 빈 파일을 쓰는 대신 오류를 반환합니다.
헤더가 누락될 수 있습니다. DOM-to-image 렌더링은 때때로 줄을 생략하며, 줄 번호에 눈에 띄는 간격이 생깁니다. 이러한 이미지는 예시용으로 취급하고, 정밀함이 중요할 때는 바이트 단위 정확한 증거로 사용하지 마세요 — Caido의 자체 요청 내보내기를 사용하세요.
레이아웃은 Side by Side로 고정됩니다. 서버는 의도적으로 레이아웃이나 배열 옵션을 노출하지 않으므로 모든 증거 스크린샷이 동일한 보고서 준비 형식을 갖습니다.
스크린샷은 수정되지 않습니다. 화면에 있는 모든 것 —
Authorization,Cookie,Set-Cookie— 이 전체가 캡처됩니다. 공유 전에 검토하세요.요청 전용 Replay 세션은 기본적으로 거부됩니다. 선택한 세션에 응답이 없으면 Screenshot Mode가 이전 미리보기를 유지할 수 있습니다. 요청 전용 스크린샷이 의도된 경우에만
--allow-no-response를 전달하세요.
문제 해결
메시지 | 원인 |
| Caido가 |
| Caido 창에서 로컬 인스턴스의 Connect를 클릭하세요. |
| Replay 세션이 열려 있지 않거나 Screenshot Mode 플러그인이 설치/활성화되지 않았습니다. |
| Replay 사이드바에 표시된 정확한 컬렉션 이름을 사용하세요. |
| 도구는 |
| 선택한 세션이 요청에서 시드되었거나 완료되지 않았습니다. |
| Screenshot Mode가 다른 호스트/경로(또는 충돌하는 보이는 쿼리)를 표시했습니다. 저장된 것은 없습니다. 채워진 |
| 렌더링하기에 콘텐츠가 너무 깁니다. 더 짧은 요청/응답을 캡처하세요. |
라이선스
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
Capture website screenshots, run bulk captures, and manage screenshot schedules and history.
1Clean PNG/JPEG screenshots via REST or MCP, with goal-driven multi-step navigation.
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
Full-page website screenshots and visual diffs between two captures. Pay per capture on Apify.
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.2111 npm35Apache 2.0
- 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
- AlicenseNot gradedqualityCmaintenanceCaptures screenshots of web URLs or local HTML files using Playwright Chromium and exposes them as resources.14 npmMIT