What can you do with this server?

The SnapStack Server captures, stores, and manages browser screenshots locally, serving them to MCP-compatible AI clients via the Model Context Protocol (MCP). * Capture & store screenshots: Receive browser captures from the SnapStack extension and store them on disk as images (WebP/PNG/JPG) with rich metadata (URL, page title, timestamp, dimensions, format, file size). * List screenshots (get_screenshots): Retrieve a manifest of pending captures — their stable number, absolute file path, dimensions, and metadata — without transmitting image bytes over the network. Optionally filter by specific capture numbers. * Count screenshots (count_screenshots): Get the total number of pending screenshots without retrieving or deleting any. * Clear screenshots (clear_screenshots): Delete specific screenshots by number or clear the entire stack at once; numbering resets to 01 after a full clear. * Configure capture settings: Adjust image format, quality, max width, and max full-page slices via an API, applied globally to all connected extensions. * Operate locally and securely: Listens exclusively on 127.0.0.1, keeping all data on the user's machine. Supports MCP over HTTP or stdio transports. * Run as a managed background service: Installs as a global CLI tool with support for auto-start on login, and can be started, stopped, or restarted as needed.

How do I use SnapStack Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SnapStack Server Show me the latest screenshots" 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.

SnapStack Server

by bgaze

Overview Schema Related Servers Score Discussions

JavaScript

Local

The SnapStack server is a single always-on Node process: it receives browser captures from the extension, stacks them on disk, and serves them to any MCP-capable LLM client over Streamable HTTP. It listens only on 127.0.0.1 — nothing ever leaves your machine.

New here? The full install + usage guide lives in the extension README: snapstack-extension. This page is the technical reference.

Architecture

One always-on process serves both the extension (capture) and your MCP client, decoupled by a folder on disk.

[MV3 extension]  --POST /push (bytes) ┐
                                      ▼
                              [SnapStack server - 127.0.0.1:4123]   
                                 ├─ writes           →  stack on disk
                                 └─ MCP /mcp (HTTP)  ←  MCP client

Capture — the extension encodes the shot as WebP (PNG fallback), downscales it, and POSTs it here.
Stack — one image file (.webp/.png) plus a twin .json (url, title, timestamp, dimensions) per capture, named NN <timestamp>: a stable two-digit number (assigned in capture order, restarts at 01 when the stack empties) plus a timestamp, under ~/.snapstack/.
Retrieval — get_screenshots returns a JSON manifest (number, absolute path, dimensions, metadata — no image bytes); the client reads only the files it needs, by path. Deletion is a separate, explicit clear_screenshots step. Retrieval never deletes.

Related MCP server: MCP-URL2SNAP

Requirements

Node.js ≥ 18 (tested on Node 20). No git needed at runtime.
An MCP-capable LLM client speaking the HTTP (Streamable HTTP) or stdio transport.
The snapstack-extension loaded in your browser.

Install & run

On Windows, use an Administrator terminal, otherwise the global npm install and the scheduled-task registration may get rejected.

The server ships on npm and installation is straightforward on macOS, Linux and Windows:

Install globally: npm i -g snapstack-server
Enable background service: snapstack enable

SnapStack auto-starts on login, restarts on crash, and updates itself on each launch.
To check its status or if an update is available, simply run snapstack in your terminal.

Available commands:

snapstack                            # status report: service + server health, update check
snapstack start | stop | restart     # control the running service (this session)
snapstack update                     # update the CLI (npm i -g) + restart the server on the latest
snapstack run                        # run the daemon in the foreground (no auto-start)

The daemon self-updates on each (re)start/login; the global CLI (the snapstack command) does not. Run snapstack update to bring both to the latest in one go.

The full end-to-end walkthrough (idiomatic install paths, MCP client registration, the extension) is in the extension README.

MCP

SnapStack speaks two MCP transports over the same on-disk stack — pick whichever your client supports:

// HTTP (server already running) — register http://127.0.0.1:4123/mcp; copy deploy/mcp.json
{ "type": "http", "url": "http://127.0.0.1:4123/mcp" }

// stdio (the client spawns the process)
{ "command": "npx", "args": ["-y", "-p", "snapstack-server", "snapstack", "mcp"] }

The HTTP /mcp endpoint is stateless (a fresh server + transport per request); the stdio front-end (snapstack mcp) is spawned on demand and reads the same ~/.snapstack stack.
Capture intake (/push) always stays in the running server, independent of either MCP front-end.

Exposed tools

Tool	Description
`get_screenshots`	Lists pending captures as a JSON manifest (stable number, absolute path, dimensions, metadata) — no image bytes, no deletion. Pass `numbers` (e.g. `[1,3]`) to list only those.
`clear_screenshots`	Deletes captures. Pass `numbers` to delete specific ones; omit to clear the whole stack. Numbering restarts at `01` once empty.
`count_screenshots`	Number of pending captures, without retrieving them.

get_screenshots and count_screenshots are read-only; only clear_screenshots is destructive.

Configuration

Environment variables (infrastructure)

Variable	Default	Purpose
`SNAPSTACK_DIR`	`~/.snapstack`	Stack folder.
`SNAPSTACK_PORT`	`4123`	Listening port (always on `127.0.0.1`).

Capture policy (shared across your browsers)

The encoding/capture settings are owned by the server and stored in ~/.snapstack/config.json, so a single edit applies to every browser running the extension. They are edited from the extension's options page — not an environment variable — and fetched by the extension before each capture.

Key	Default	Meaning
`format`	`webp`	Image format: `webp`, `png` or `jpg`.
`quality`	`0.85`	Lossy quality (`0`–`1`; the extension UI shows it as a percentage).
`maxWidth`	`1568`	Downscale captures wider than this to this width in px (`0` = no resize).
`maxSlices`	`50`	Full-page capture: hard cap on stitched slices.

Two endpoints back it: GET /config returns the effective policy; POST /config validates and replaces it (host- + CORS-guarded like every capture route). The file is a non-image, so a stack clear never touches it; deleting it just restores the defaults above.

Troubleshooting

Capture server not started message in the extension: run snapstack start (or snapstack run in the foreground), or check the auto-start with snapstack. Test: curl http://127.0.0.1:4123/health.
Port already in use (EADDRINUSE): set SNAPSTACK_PORT to another value.
snapstack: command not found after switching Node version (nvm, fnm, volta, Laravel Herd, nvm-windows): npm i -g drops the snapstack command in the global bin of the Node version that was active at install time only, so switching versions hides it. This is how npm globals work, not a SnapStack bug — the background service is unaffected and keeps capturing; only the CLI command disappears. Fix: re-run npm i -g snapstack-server under the current Node version (or switch back to the one used at install).
The client doesn't see the tools: the server must run before the MCP client starts; check the config (type: "http", correct URL). Direct test: curl http://127.0.0.1:4123/count.
Inspect the stack: ls ~/.snapstack (image files + human-readable .json).

Support

A question or an idea? → GitHub Discussions
Found a bug? → open an issue

License

MIT — see LICENSE.

Available Tools

3 tools

clear_screenshotsClear screenshotsA

Delete pending screenshots from the stack. Pass "numbers" to delete only specific captures (e.g. [1] or [2,3]); omit to clear the whole stack. Once the stack is empty, numbering restarts at 01.

ParametersJSON Schema

Name	Required	Description	Default
`numbers`	No	Capture numbers to delete (e.g. [2,3]). Omit to clear all.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description provides behavioral details like the numbering restart after stack clears. It explains the optional parameter behavior but does not mention any other side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no wasted words. The first sentence states the purpose; the second adds key usage details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description covers behavior, parameter usage, and an edge case (numbering restart). It is fully adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds value beyond the schema by explaining the parameter's effect (delete specific captures) and the default behavior (omit to clear all).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (delete) and resource (pending screenshots from the stack). It distinguishes from siblings count_screenshots and get_screenshots by focusing on deletion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (to delete screenshots) and how to specify numbers or clear all. It implicitly differentiates from siblings but does not explicitly state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

count_screenshotsCount screenshotsA

Return the number of pending screenshots in the stack without retrieving or clearing them.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It clearly states the tool is non-destructive and read-only, but does not specify any other behavioral details like response format. Still, it adequately discloses the core behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no superfluous words, efficiently conveying the tool's purpose and constraints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description could be more explicit about the return format, but 'return the number' is sufficient for a simple count tool. It adequately covers the tool's functionality.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so baseline score of 4 applies. The description adds no parameter info, but none is needed since the input schema is empty and coverage is 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns the number of pending screenshots without side effects, using a specific verb and resource. It distinguishes from siblings by explicitly noting it does not retrieve or clear screenshots.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts with sibling tools by stating 'without retrieving or clearing them', indicating when to use this tool (for counting only) vs the alternatives (get_screenshots, clear_screenshots).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_screenshotsGet screenshotsA

List the pending browser screenshots as a manifest — NO image data. The stack is the local folder where the SnapStack browser extension pushes captures. Each entry has a stable two-digit "number", the absolute local "path", "width"/"height", and metadata (url, title, capturedAt, format, bytes). Read the file at "path" yourself only if you need the pixels. This tool does NOT delete anything — use clear_screenshots to remove captures. Pass "numbers" to list only specific captures (e.g. [1] or [1,3]); omit to list them all.

ParametersJSON Schema

Name	Required	Description	Default
`numbers`	No	Capture numbers to include (e.g. [1] or [1,3,5]). Omit to include all.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`screenshots`	Yes
`missing`	Yes

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses critical behaviors: no image data, no deletion, describes manifest fields, and explains the source stack. With no annotations, this fully covers needed context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with main purpose, then details. Slightly verbose but every sentence adds value. Could be trimmed slightly but still effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers parameter behavior, return structure, and differentiation from siblings. Output schema exists, so return details are not needed. Complete for this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% with description. Tool description adds usage examples and clarifies optionality, enhancing understanding beyond schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it lists pending browser screenshots as a manifest without image data. Distinct purpose from sibling tools by specifying what it does not do (delete).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use (list captures) and when not (to get pixels, read the file directly). Names alternative tool clear_screenshots for deletion.

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. Dates show when Glama detected each change.

3 tool updatesJun 15, 2026
- First observedclear_screenshots
- First observedcount_screenshots
- First observedget_screenshots

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a distinct purpose: clearing, counting, and listing screenshots. There is no overlap in functionality, and the descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (clear_screenshots, count_screenshots, get_screenshots), making them predictable and easy to understand.

Tool Count5/5

Three tools are appropriate for the narrow domain of managing a screenshot stack. Each tool provides essential functionality without redundancy or unnecessary complexity.

Completeness5/5

The tool set covers the core operations needed to manage pending screenshots: listing metadata, counting, and clearing. Since capture is handled externally by a browser extension, the server's surface is complete.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

screenshot A
com.apiscreenshot
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
Browser Automation Image & Video Processing
2
Skillforge Render API A
com.skillforge99
Screenshot, PDF, OG-image, and page extraction (markdown/JSON) over MCP. Bearer key or x402.
Image & Video Processing Multimedia Processing Marketing
41
snapforge A
org.snapforge
Screenshots, PDFs and Markdown from any URL or HTML for AI agents, via the SnapForge API
Browser Automation Web Scraping
42
saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82

Related MCP Servers

MCP Screenshot Server
Browser Automation Web Scraping
sethbang
A
license
A
quality
A
maintenance
Enables 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.
Updated 12 days ago (2026-08-24 11:21 UTC)
2
464
30
Apache 2.0
MCP-URL2SNAP
Browser Automation Web Scraping Agent Orchestration
Abhi5h3k
F
license
A
quality
D
maintenance
A lightweight Model Context Protocol (MCP) server that enables your LLM to capture screenshots of any specified URL and return only the access URL for the captured image. This tool simplifies the process of generating and sharing webpage snapshots, making it perfect for integrating visual capture ca
Updated a year ago (2025-07-17 11:35 UTC)
1
2
-
Screen MCP
Image & Video Processing OS Automation
jeandelest
F
license
A
quality
D
maintenance
Enables LLMs to capture screenshots and screen recordings through MCP with chunked session-based transfers for reliable image consumption. Supports multi-monitor selection, timeline capture, and compatibility with both vision and non-vision language models.
Updated 5 months ago (2026-04-04 00:16 UTC)
11
1
-
SnapAPI MCP Server
Browser Automation Web Scraping
Sleywill
A
license
A
quality
D
maintenance
MCP server for the SnapAPI web capture API. Take screenshots, scrape pages, extract structured data, generate PDFs, record videos, and run AI analysis on any URL — all from Claude, Cursor, VS Code, or any MCP client. 9 tools, 30+ device presets, ad/cookie blocking. Install: npx snapapi-mcp
Updated 5 months ago (2026-04-02 08:54 UTC)
9
13
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bgaze/snapstack-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server