Skip to main content
Glama
deenesjakoruzh
sethbang

MCP Screenshot Server

by sethbang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Universal Screenshot MCP

npm version MCP Registry License

AIアシスタントにスクリーンショット機能を提供するMCP (Model Context Protocol)サーバーです。PuppeteerによるWebページキャプチャと、ネイティブOSツールを使用したクロスプラットフォームのシステムスクリーンショットの両方に対応しています。

機能

  • Webページスクリーンショット — ヘッドレスChromiumブラウザを使用して、公開されているあらゆるURLをキャプチャ

  • クロスプラットフォームのシステムスクリーンショット — ネイティブOSツール（macOSのscreencapture、Linuxのmaim/scrot/gnome-screenshotなど、WindowsのPowerShell+.NET）を使用したフルスクリーン、ウィンドウ、または領域のキャプチャ

  • セキュリティ重視の設計 — SSRF防止、パストラバーサル保護、DNSリバインディング防御、コマンドインジェクション防止、DoS制限

  • MCPネイティブ — Claude Desktop、Cursor、およびMCP互換クライアントと直接統合

Related MCP server: Chrome DevTools MCP

要件

  • Node.js >= 18.0.0

  • Chromium は初回実行時にPuppeteerによって自動的にダウンロードされます

take_system_screenshot のプラットフォーム別要件

プラットフォーム

必要なツール

備考

macOS

screencapture (組み込み)

追加インストール不要

Linux

maim, scrot, gnome-screenshot, spectacle, grim, または import (ImageMagick) のいずれか

全機能サポートには maim または scrot を推奨。ウィンドウ名によるキャプチャには xdotool もインストールしてください。

Windows

powershell (組み込み)

.NET System.Drawing を使用 — 追加インストール不要

Linuxインストール例

# 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

インストール後、以下のコマンドでセットアップを確認できます：

npx universal-screenshot-mcp --doctor

これはホストを調査し、検出されたディストリビューションに合わせて不足しているツールのインストールコマンドを表示します。

クイックスタート

npmからインストール

npm install -g universal-screenshot-mcp

または npx で直接実行：

npx universal-screenshot-mcp

ソースからインストール

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

MCPクライアントの設定

MCPクライアントの設定にサーバーを追加します。Claude Desktopの場合、~/Library/Application Support/Claude/claude_desktop_config.json を編集します：

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

ソースからインストールした場合は以下：

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

Claude Codeの場合、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

ソースからインストールした場合は以下：

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

claude mcp list でサーバーが登録されたか確認するか、セッション内で /mcp を使用してライブステータスを確認してください。

Cursorやその他のMCPクライアントについては、それぞれのドキュメントで同等の設定方法を確認してください。

ツール

このサーバーは2つのMCPツールを公開しています：

take_screenshot

ヘッドレスPuppeteerブラウザを介してWebページ（または特定の要素）をキャプチャします。

パラメータ

型

必須

説明

url

string

✅

キャプチャするURL (http/httpsのみ)

width

number

—

ビューポートの幅 (1–3840)

height

number

—

ビューポートの高さ (1–2160)

fullPage

boolean

—

スクロール可能なページ全体をキャプチャ

selector

string

—

特定の要素をキャプチャするためのCSSセレクタ

waitForSelector

string

—

キャプチャ前にこのセレクタを待機する

waitForTimeout

number

—

ミリ秒単位の遅延 (0–30000)

outputPath

string

—

出力ファイルパス (デフォルト: ~/Documents/screenshots)

プロンプト例:

Take a screenshot of https://example.com at 1920x1080

take_system_screenshot

ネイティブOSツールを使用して、デスクトップ、特定のアプリケーションウィンドウ、または画面領域をキャプチャします。macOS、Linux、Windowsで動作します。

パラメータ

型

必須

説明

mode

enum

✅

fullscreen, window, または region

windowId

number

—

ウィンドウモード用のウィンドウID

windowName

string

—

ウィンドウモード用のアプリ名 (例: "Safari", "Firefox")

region

object

—

領域モード用の { x, y, width, height }

display

number

—

マルチモニター設定用のディスプレイ番号

includeCursor

boolean

—

キャプチャにマウスポインターを含める

format

enum

—

png (デフォルト) または jpg

delay

number

—

秒単位のキャプチャ遅延 (0–10)

outputPath

string

—

出力ファイルパス (デフォルト: ~/Documents/screenshots)

クロスプラットフォーム機能サポート

機能

macOS

Linux

Windows

フルスクリーン

✅

✅

✅

領域

✅

✅ (maim, scrot, grim, import)

✅

ウィンドウ名指定

✅

⚠️ X11 + xdotool

⚠️ ベストエフォート

ウィンドウID指定

✅

✅ X11のみ

⚠️ HWND

マルチディスプレイ

✅

⚠️ ツール依存

✅

カーソルを含める

✅

⚠️ ツール依存

⚠️

遅延

✅

✅

✅

プロンプト例:

Take a system screenshot of the Safari window

設定

環境変数

変数

デフォルト

説明

SCREENSHOT_OUTPUT_DIR

Documents/screenshots

~ からの相対パスによるデフォルト出力ディレクトリ

ALLOW_LOCAL

false

localhost/127.x.x.x/[::1] のスクリーンショットを許可するには true に設定 (ローカル開発サーバーで便利)

出力ディレクトリ

スクリーンショットはデフォルトで ~/Documents/screenshots に保存されます（SCREENSHOT_OUTPUT_DIR で設定可能）。カスタム出力パスは、以下の許可されたディレクトリのいずれかに解決される必要があります：

ディレクトリ

説明

~/Documents/screenshots

デフォルトの出力場所 (設定可能)

~/Desktop/Screenshots

元のデフォルトの場所

~/Downloads

ユーザーのダウンロードフォルダ

~/Documents

ユーザーのドキュメントフォルダ

/tmp

システム一時ディレクトリ

セキュリティ

このサーバーは複数のセキュリティ強化レイヤーを実装しています：

ID

脅威

緩和策

SEC-001

SSRF / DNSリバインディング

ブロックされたIP範囲に対してURLを検証。--host-resolver-rules を介したIP固定でリクエスト前にDNSを解決。ナビゲーションリダイレクトを再検証

SEC-003

コマンドインジェクション

すべてのサブプロセスで execFile を使用 (シェルなし)。アプリ名を SAFE_APP_NAME_PATTERN に対して検証

SEC-004

パス・トラバーサル

fs.realpath() シンボリックリンク解決で出力パスを検証。許可されたディレクトリに制限

SEC-005

サービス拒否 (DoS)

セマフォにより同時Puppeteerインスタンスを3つに制限

詳細は docs/security.md を参照してください。

開発

スクリプト

コマンド

説明

npm run build

TypeScriptを build/ にコンパイル

npm run watch

ファイル変更時に再コンパイル

npm test

ユニットテスト (高速、完全にモック化)

npm run test:integration

統合テスト (実際のDNS/ファイルシステム)

npm run test:e2e

E2Eテスト (実際のPuppeteer/ネイティブツール)

npm run test:all

すべてのテスト階層をまとめて実行

npm run test:linux

Docker経由のLinux e2e (Dockerが必要)

npm run test:watch

ウォッチモードでテストを実行

npm run test:coverage

カバレッジレポート付きでテストを実行

npm run lint

ESLintでソースをリント

npm run inspector

デバッグ用にMCP Inspectorを起動

プロジェクト構造

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)

テスト

テストは Vitest を使用し、3つの階層で行われます：

  • ユニット (npm test) — 完全な依存関係注入、実際のI/Oなし。高速なフィードバックループ。

  • 統合 (npm run test:integration) — 実際のDNS解決、一時ディレクトリを使用した実際のファイルシステム、ローカルHTTPサーバーに対する実際のPuppeteer。

  • E2E (npm run test:e2e) — 実際のネイティブスクリーンショットツール。macOSテストはネイティブで実行。Linuxテストは npm run test:linux を介してDockerで実行。

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

MCP Inspectorによるデバッグ

npm run inspector

これにより、ビルドされたサーバーに接続された MCP Inspector が起動し、対話的にツールを呼び出すことができます。

ライセンス

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
Deploy Server
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

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

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Webshot MCP

    bingal
    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

  • Screenshot API

    raphy78626
    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.
    10 npm
    MIT

Appeared in Searches