get_screenshotsLABSCO SUMMARY
Retrieval hands back a manifest, and that is the whole design.
Returning paths and metadata instead of image bytes means the client reads only the screenshots it decides it needs, which keeps a stack of a dozen captures from flooding a context window. Deletion being a separate explicit step follows from the same instinct: retrieval never destroys, so an assistant re-reading the stack cannot quietly consume it. Everything stays on loopback and on disk, which is the right posture for something whose contents are pictures of whatever you had open.
What it is
An always-on local server that receives captures from a companion browser extension, writes them to a folder on disk, and serves them to an MCP client. It listens only on the loopback address, so images never leave the machine. Capture and retrieval are decoupled by the folder itself, which is why the same stack is reachable over two different transports.
What you get
- Pending captures listed as a JSON manifest — a stable two-digit number, the absolute path, dimensions and metadata, with no image bytes and no deletion; pass specific numbers to list only those —
get_screenshots - Captures deleted explicitly: name numbers to remove some, or omit them to clear the stack, after which numbering restarts —
clear_screenshots - A count of pending captures without retrieving anything —
count_screenshots - A separation worth relying on: two of the three tools are read-only, and only the clear tool destroys anything
- Each capture stored as an image file plus a twin JSON holding url, title, timestamp and dimensions, so the context of a screenshot survives alongside it
- Two transports over the same on-disk stack: register the HTTP endpoint if the server is running, or let the client spawn the stdio front-end
Requirements
The companion browser extension, which does the capturing — this server alone does nothing. Node.js 18 or higher, and an MCP client speaking either streamable HTTP or stdio. Install with npm i -g snapstack-server, then snapstack enable registers it as a background service that starts on login, restarts on crash and updates itself on launch; running snapstack alone reports service and server health and checks for updates. On Windows use an Administrator terminal, or the global install and service registration may be rejected. Published as snapstack-server (1.2.3), MIT licensed.
Setup effort
Follow the published steps
USE CASES
01
Showing an assistant what you are looking at
Capture the tab with the extension, then have the assistant list the stack and read the ones it needs by path.
02
Working through several screens in order
Capture a sequence, and rely on the stable capture-order numbering to refer to specific shots.
03
Keeping the context window under control
Read the manifest first and open only the images that matter, rather than pushing every capture into the conversation.
04
Clearing the stack when you are done
Delete specific captures or wipe the lot, deliberately, as a separate step from reading them.
3 tools
Listed in project docs. Your client may show a different list.
clear_screenshotscount_screenshotsBEFORE YOU INSTALL
What to know first
Tools you get
3 tools named in the project's documentation.
Requires
Node.js ≥ 18
Where it runs
The documented client runs the server on your machine.
INSTALLATION
Connect your client
Server setup
Node.js >= 18 required; on Windows use an Administrator terminal
TERMINAL
npm i -g snapstack-serversnapstack enable (registers the background service; auto-starts on login, restarts on crash, self-updates)
Register the server with your MCP client — HTTP: { "type": "http", "url": "http://127.0.0.1:4123/mcp" }, or stdio: { "command": "npx", "args": ["-y", "-p", "snapstack-server", "snapstack", "mcp"] }
Load the companion browser extension from https://github.com/bgaze/snapstack-extension
MCP Clients
Any MCP client
ANY MCP CLIENT · JSON
{
"mcpServers": {
"snapstack-server": {
"type": "http",
"url": "http://127.0.0.1:4123/mcp"
}
}
}
