Skip to main content
Glama
sethbang

MCP Screenshot Server

by sethbang

Universal Screenshot MCP

npm version MCP Registry License

Ein MCP (Model Context Protocol)-Server, der KI-Assistenten Screenshot-Funktionen bereitstellt – sowohl für die Aufnahme von Webseiten über Puppeteer als auch für plattformübergreifende System-Screenshots mithilfe nativer Betriebssystem-Tools.

Funktionen

  • Webseiten-Screenshots — Erfassen Sie jede öffentliche URL mit einem Headless-Chromium-Browser

  • Plattformübergreifende System-Screenshots — Vollbild-, Fenster- oder Bereichsaufnahmen mit nativen OS-Tools (macOS screencapture, Linux maim/scrot/gnome-screenshot/etc., Windows PowerShell+.NET)

  • Sicherheitsorientiertes Design — SSRF-Prävention, Schutz vor Pfad-Traversal, Schutz vor DNS-Rebinding, Verhinderung von Befehlsinjektionen und DoS-Begrenzung

  • MCP-nativ — Integriert sich direkt in Claude Desktop, Cursor und jeden MCP-kompatiblen Client

Related MCP server: Chrome DevTools MCP

Anforderungen

  • Node.js >= 18.0.0

  • Chromium wird beim ersten Start automatisch von Puppeteer heruntergeladen

Plattformspezifische Anforderungen für take_system_screenshot

Plattform

Erforderliche Tools

Hinweise

macOS

screencapture (integriert)

Keine zusätzliche Installation erforderlich

Linux

Eines der folgenden: maim, scrot, gnome-screenshot, spectacle, grim oder import (ImageMagick)

maim oder scrot für volle Funktionsunterstützung empfohlen. Für die Aufnahme von Fenstern nach Namen zusätzlich xdotool installieren.

Windows

powershell (integriert)

Verwendet .NET System.Drawing — keine zusätzliche Installation erforderlich

Linux-Installationsbeispiele

# Ubuntu/Debian (recommended)
sudo apt install maim xdotool

# Fedora
sudo dnf install maim xdotool

# Arch Linux
sudo pacman -S maim xdotool

# Wayland (Sway, etc.)
sudo apt install grim

Nach der Installation können Sie Ihr Setup wie folgt überprüfen:

npx universal-screenshot-mcp --doctor

Dies untersucht den Host und gibt kopierbare Installationsbefehle für fehlende Tools aus, angepasst an Ihre erkannte Distribution.

Schnelleinstieg

Installation über npm

npm install -g universal-screenshot-mcp

Oder führen Sie es direkt mit npx aus:

npx universal-screenshot-mcp

Installation aus dem Quellcode

git clone https://github.com/sethbang/mcp-screenshot-server.git
cd mcp-screenshot-server
npm install
npm run build

Konfigurieren Sie Ihren MCP-Client

Fügen Sie den Server zur Konfiguration Ihres MCP-Clients hinzu. Für Claude Desktop bearbeiten Sie ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "screenshot-server": {
      "command": "npx",
      "args": ["-y", "universal-screenshot-mcp"]
    }
  }
}

Oder bei Installation aus dem Quellcode:

{
  "mcpServers": {
    "screenshot-server": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-screenshot-server/build/index.js"]
    }
  }
}

Für Claude Code registrieren Sie den Server mit dem Befehl claude mcp add:

# Project scope (current directory only)
claude mcp add screenshot-server -- npx -y universal-screenshot-mcp

# User scope (available across all projects)
claude mcp add --scope user screenshot-server -- npx -y universal-screenshot-mcp

Oder bei Installation aus dem Quellcode:

claude mcp add screenshot-server -- node /absolute/path/to/mcp-screenshot-server/build/index.js

Überprüfen Sie die Registrierung des Servers mit claude mcp list oder prüfen Sie den Live-Status innerhalb einer Sitzung mit /mcp.

Für Cursor oder andere MCP-Clients konsultieren Sie deren Dokumentation für die entsprechende Konfiguration.

Tools

Der Server stellt zwei MCP-Tools bereit:

take_screenshot

Erfasst eine Webseite (oder ein spezifisches Element) über einen Headless-Puppeteer-Browser.

Parameter

Typ

Erforderlich

Beschreibung

url

string

✅

Zu erfassende URL (nur http/https)

width

number

—

Viewport-Breite (1–3840)

height

number

—

Viewport-Höhe (1–2160)

fullPage

boolean

—

Erfasst die gesamte scrollbare Seite

selector

string

—

CSS-Selektor zur Erfassung eines spezifischen Elements

waitForSelector

string

—

Vor der Aufnahme auf diesen Selektor warten

waitForTimeout

number

—

Verzögerung in Millisekunden (0–30000)

outputPath

string

—

Ausgabedateipfad (Standard: ~/Documents/screenshots)

Beispiel-Prompt:

Mache einen Screenshot von https://example.com mit 1920x1080

take_system_screenshot

Erfasst den Desktop, ein spezifisches Anwendungsfenster oder einen Bildschirmbereich mithilfe nativer OS-Tools. Funktioniert unter macOS, Linux und Windows.

Parameter

Typ

Erforderlich

Beschreibung

mode

enum

✅

fullscreen, window oder region

windowId

number

—

Fenster-ID für den Fenstermodus

windowName

string

—

App-Name (z. B. "Safari", "Firefox") für den Fenstermodus

region

object

—

{ x, y, width, height } für den Bereichsmodus

display

number

—

Display-Nummer für Multi-Monitor-Setups

includeCursor

boolean

—

Mauszeiger in die Aufnahme einbeziehen

format

enum

—

png (Standard) oder jpg

delay

number

—

Aufnahmeverzögerung in Sekunden (0–10)

outputPath

string

—

Ausgabedateipfad (Standard: ~/Documents/screenshots)

Plattformübergreifende Funktionsunterstützung

Funktion

macOS

Linux

Windows

Vollbild

✅

✅

✅

Bereich

✅

✅ (maim, scrot, grim, import)

✅

Fenster nach Name

✅

⚠️ X11 + xdotool

⚠️ best-effort

Fenster nach ID

✅

✅ nur X11

⚠️ HWND

Multi-Display

✅

⚠️ tool-abhängig

✅

Cursor einbeziehen

✅

⚠️ tool-abhängig

⚠️

Verzögerung

✅

✅

✅

Beispiel-Prompt:

Mache einen System-Screenshot des Safari-Fensters

Konfiguration

Umgebungsvariablen

Variable

Standard

Beschreibung

SCREENSHOT_OUTPUT_DIR

Documents/screenshots

Standard-Ausgabeverzeichnis relativ zu ~

ALLOW_LOCAL

false

Auf true setzen, um Screenshots von localhost/127.x.x.x/[::1] zu erlauben (nützlich für lokale Entwicklungsserver)

Ausgabeverzeichnisse

Screenshots werden standardmäßig unter ~/Documents/screenshots gespeichert (konfigurierbar über SCREENSHOT_OUTPUT_DIR). Benutzerdefinierte Ausgabepfade müssen in eines dieser erlaubten Verzeichnisse aufgelöst werden:

Verzeichnis

Beschreibung

~/Documents/screenshots

Standard-Ausgabeort (konfigurierbar)

~/Desktop/Screenshots

Ursprünglicher Standardort

~/Downloads

Benutzer-Download-Ordner

~/Documents

Benutzer-Dokumente-Ordner

/tmp

System-Temporärverzeichnis

Sicherheit

Dieser Server implementiert mehrere Ebenen der Sicherheitsabsicherung:

ID

Bedrohung

Gegenmaßnahme

SEC-001

SSRF / DNS-Rebinding

URLs werden gegen blockierte IP-Bereiche validiert; DNS wird vor der Anfrage aufgelöst mit IP-Pinning via --host-resolver-rules; Navigations-Redirects werden erneut validiert

SEC-003

Befehlsinjektion

Alle Subprozesse verwenden execFile (keine Shell); App-Namen werden gegen SAFE_APP_NAME_PATTERN validiert

SEC-004

Pfad-Traversal

Ausgabepfade werden mit fs.realpath() Symlink-Auflösung validiert; auf erlaubte Verzeichnisse beschränkt

SEC-005

Denial of Service

Gleichzeitige Puppeteer-Instanzen auf 3 via Semaphor begrenzt

Für vollständige Details siehe docs/security.md.

Entwicklung

Skripte

Befehl

Beschreibung

npm run build

Kompiliert TypeScript nach build/

npm run watch

Rekompiliert bei Dateiänderungen

npm test

Unit-Tests (schnell, vollständig gemockt)

npm run test:integration

Integrationstests (echtes DNS/Dateisystem)

npm run test:e2e

E2E-Tests (echtes Puppeteer/native Tools)

npm run test:all

Alle Testebenen zusammen

npm run test:linux

Linux E2E via Docker (erfordert Docker)

npm run test:watch

Tests im Watch-Modus ausführen

npm run test:coverage

Tests mit Coverage-Bericht ausführen

npm run lint

Quellcode mit ESLint prüfen

npm run inspector

Startet MCP Inspector zum Debuggen

Projektstruktur

src/
├── index.ts                 # Entry point — stdio transport
├── server.ts                # MCP server factory
├── config/
│   ├── index.ts             # Static constants (limits, allowed dirs)
│   └── runtime.ts           # Singleton semaphore, default directory
├── tools/
│   ├── take-screenshot.ts   # Web page capture tool
│   └── take-system-screenshot.ts  # macOS system capture tool
├── types/
│   └── index.ts             # Shared TypeScript interfaces
├── utils/
│   ├── helpers.ts           # Response builders, file utilities
│   ├── screenshot-provider.ts # Cross-platform provider interface + factory
│   ├── macos-provider.ts    # macOS: screencapture wrapper
│   ├── linux-provider.ts    # Linux: maim/scrot/gnome-screenshot/etc.
│   ├── windows-provider.ts  # Windows: PowerShell + .NET System.Drawing
│   ├── macos.ts             # Window ID lookup via CoreGraphics
│   └── semaphore.ts         # Async concurrency limiter
└── validators/
    ├── path.ts              # Output path validation (SEC-004)
    └── url.ts               # URL/SSRF validation (SEC-001)

Testen

Tests verwenden Vitest in drei Ebenen:

  • Unit (npm test) — Vollständige Dependency Injection, kein echtes I/O. Schnelle Feedbackschleife.

  • Integration (npm run test:integration) — Echte DNS-Auflösung, echtes Dateisystem mit temporären Verzeichnissen, echtes Puppeteer gegen einen lokalen HTTP-Server.

  • E2E (npm run test:e2e) — Echte native Screenshot-Tools. macOS-Tests laufen nativ; Linux-Tests laufen in Docker via npm run test:linux.

npm test                 # Unit tests (~300ms)
npm run test:linux       # Linux provider tests in Docker
npm run test:all         # Everything

Debuggen mit dem MCP Inspector

npm run inspector

Dies startet den MCP Inspector, der mit Ihrem gebauten Server verbunden ist, sodass Sie Tools interaktiv aufrufen können.

Lizenz

Apache-2.0 — Copyright 2026 Seth Bang

Available Tools

2 tools
take_screenshotB

Capture web page or element via headless browser. Saves to ~/Documents/screenshots by default (configurable via SCREENSHOT_OUTPUT_DIR env var).

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL to capture
widthNoViewport width
heightNoViewport height
fullPageNoCapture full page
selectorNoCSS selector for element
waitForSelectorNoWait for selector
waitForTimeoutNoDelay in ms
outputPathNoAbsolute path, or relative to home dir

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only mentions method and save location; it omits critical behavioral traits like destructiveness, permission needs, or return value.

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?

Two concise sentences: first states purpose, second details save behavior. Front-loaded and no wasted words.

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

Completeness2/5

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

Despite 8 parameters and no output schema, the description omits return value, error handling, and other essential context, leaving significant gaps.

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

Parameters3/5

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

Schema covers all 8 parameters with descriptions, so baseline is 3. The description adds the default save path and env var override, providing marginal extra context.

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 uses specific verb 'capture' and resource 'web page or element' with method 'via headless browser', clearly distinguishing it from sibling 'take_system_screenshot' which captures system screens.

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

Usage Guidelines3/5

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

The description implies usage for web screenshots but does not explicitly state when to use versus alternatives, nor does it mention prerequisites or exclusions.

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

take_system_screenshotA

Capture desktop, window, or region screenshot. Cross-platform: macOS (screencapture), Linux (maim/scrot/gnome-screenshot/etc.), Windows (PowerShell+.NET). Saves to ~/Documents/screenshots by default (configurable via SCREENSHOT_OUTPUT_DIR env var). For window mode, provide windowName (app name like "Safari") or windowId.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeYesfullscreen=entire screen, window=specific app (requires windowName or windowId), region=coordinates
windowIdNoWindow ID (for window mode)
windowNameNoApp name like "Safari", "Firefox" (for window mode)
regionNoRegion {x,y,width,height}
displayNoDisplay number
includeCursorNoInclude cursor
formatNoImage format (png or jpg)
delayNoDelay seconds
outputPathNoAbsolute path, or relative to home dir

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the full burden. It discloses the default save location and cross-platform tool dependencies but does not mention return behavior (e.g., file path or binary), permission requirements, or failure modes.

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?

The description is concise with 4 sentences, front-loading the main action. It effectively uses bullet-like information for cross-platform details and mode instructions, though it could be slightly more structured.

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

Completeness3/5

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

Given 9 parameters including a nested object and no output schema, the description covers default directory and platform support but omits return value, error handling, and comparison with the sibling tool. It is adequate but not fully complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds minor value by specifying default output directory and that windowName is an app name, but the schema already describes all parameters adequately.

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 'Capture desktop, window, or region screenshot' with specific verb and resource. It distinguishes from the sibling tool 'take_screenshot' by specifying cross-platform support and modes.

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

Usage Guidelines3/5

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

The description provides clear context for when to use each mode (fullscreen, window, region) and gives examples for window mode. However, it lacks guidance on when not to use this tool versus the sibling 'take_screenshot', missing explicit exclusion or alternative differentiation.

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. 2 tool updatesv1.2.0
    • Changedtake_screenshot10 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / fullPage / description
        Previous value: -"Capture full scrollable page"New value: +"Capture full page"
      • changedInput schema / properties / height / description
        Previous value: -"Viewport height in pixels"New value: +"Viewport height"
      • changedInput schema / properties / outputPath / description
        Previous value: -"Custom output path (optional)"New value: +"Absolute path, or relative to home dir"
      • addedInput schema / properties / selector
        Added value: +{
        +  "description": "CSS selector for element",
        +  "type": "string"
        +}
      • changedInput schema / properties / url / description
        Previous value: -"URL to capture (can be http://, https://, or file:///)"New value: +"URL to capture"
      • addedInput schema / properties / waitForSelector
        Added value: +{
        +  "description": "Wait for selector",
        +  "type": "string"
        +}
      • addedInput schema / properties / waitForTimeout
        Added value: +{
        +  "description": "Delay in ms",
        +  "maximum": 30000,
        +  "minimum": 0,
        +  "type": "number"
        +}
      • changedInput schema / properties / width / description
        Previous value: -"Viewport width in pixels"New value: +"Viewport width"
    • Addedtake_system_screenshot
  2. 1 tool update
    • First observedtake_screenshot

TDQS

A3.7/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are clearly distinct: one captures web pages/elements via headless browser, the other captures desktop/system screenshots. There is no overlap in functionality.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with snake_case (take_screenshot, take_system_screenshot), using the same 'take_' prefix.

Tool Count3/5

Only 2 tools for a screenshot server is minimal but still covers the core use cases. More tools might be expected for management or configuration, but the count is not severely inadequate.

Completeness4/5

The tool set covers the primary screenshot domains (web and system). Minor gaps exist, such as listing or deleting screenshots, but core functionality is well-covered.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    C
    quality
    D
    maintenance
    Enables 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.
    1
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to capture any public URL as PNG, JPEG, or PDF via REST API or MCP tools, including screenshot capture, page description, and PDF rendering.
    16 npm
    MIT