Why snapmcp exists
AI agents are excellent with text and blind to anything visual. Ask one to check a layout, read a chart, or confirm that a command actually printed what you expected, and it has to guess. That gap shows up constantly in real work: reviewing a UI, verifying a CLI’s output, or sanity-checking a rendered document.
snapmcp closes that gap. It is a Model Context Protocol server that hands agents a camera. Instead of describing what a screen looks like, an agent calls a tool and gets back an actual image it can reason about.
What it does
The server exposes 13 tools, each focused on one kind of visual capture. An agent picks the tool that matches the task, passes a few arguments, and receives an image (or a set of images) through MCP’s standard response channel. No glue code, no custom integration per host — if the host speaks MCP, it works.
The thirteen tools
| Tool | Captures | Typical use |
|---|---|---|
terminal | Shell output | Show what a command produced |
code | Source files | Render code with syntax highlighting |
browser | Web pages | Full-page screenshots of a URL |
markdown | Rendered Markdown | Preview documentation |
diff | Before/after | Visualize a change |
html | Raw markup | Inspect page structure |
pdf | PDF pages | Verify a document page by page |
file | Any file | Read and display a file |
batch | Mixed types | Capture several things at once |
sequence | Multi-step frames | Record a process as a series |
gif | Animated frames | Compile frames into a GIF |
document | Mixed captures | Build a multi-capture document |
hint | Configuration | Return setup tips for the host |
How it works
Each tool is a small, isolated handler that drives a shared Playwright/Chromium instance. Tools register themselves with the MCP SDK, so the host discovers them automatically and the surface stays easy to extend — adding a new capture type means adding one handler, not rewiring the server.
snapmcp/
├── src/
│ ├── tools/ # one handler per capture tool
│ ├── server.ts # MCP server entry point
│ └── types.ts # shared types
├── tests/ # full test suite
├── docker/ # multi-arch Dockerfile (amd64 + arm64)
└── package.json # Bun runtimeSecurity by default
A tool that renders arbitrary input is a liability if it is careless. snapmcp ships with SSRF protection (private IPs, localhost, and DNS-rebinding are blocked), path-traversal prevention, and strict input validation — so pointing it at content does not mean pointing it at your internal network.
Install and run
It ships two ways, so it fits both local and containerized setups:
# via npm (runs on Bun, zero config)
npx snapmcp
# via Docker (multi-arch: amd64 + arm64)
docker pull ghcr.io/reeinharddd/snapmcpQuality
The project is built to be trusted, not just to work. Every tool is covered by the test suite, and CI runs the full matrix across Linux, macOS, and Windows on each change. Releases publish to npm and to GitHub Container Registry from the same pipeline.
What’s next
MCP is still young and the surface is moving fast. The next steps are broader capture backends (beyond a single browser engine) and richer composition tools so an agent can assemble a full visual report in one call.