MCP Screenshot Server
MCP de captura de pantalla universal
Un servidor MCP (Model Context Protocol) que proporciona a los asistentes de IA capacidades de captura de pantalla, tanto de páginas web mediante Puppeteer como capturas de pantalla del sistema multiplataforma utilizando herramientas nativas del SO.
Características
Capturas de pantalla de páginas web — Capture cualquier URL pública utilizando un navegador Chromium sin interfaz gráfica (headless).
Capturas de pantalla del sistema multiplataforma — Captura de pantalla completa, ventana o región utilizando herramientas nativas del SO (macOS
screencapture, Linuxmaim/scrot/gnome-screenshot/etc., Windows PowerShell+.NET).Diseño centrado en la seguridad — Prevención de SSRF, protección contra recorrido de rutas, defensa contra rebinding de DNS, prevención de inyección de comandos y limitación de DoS.
Nativo de MCP — Se integra directamente con Claude Desktop, Cursor y cualquier cliente compatible con MCP.
Related MCP server: Chrome DevTools MCP
Requisitos
Node.js >= 18.0.0
Chromium se descarga automáticamente mediante Puppeteer en la primera ejecución.
Requisitos específicos de la plataforma para take_system_screenshot
Plataforma | Herramientas requeridas | Notas |
macOS |
| No requiere instalación adicional |
Linux | Una de: | Se recomienda |
Windows |
| Utiliza .NET |
Ejemplos de instalación en 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 grimDespués de instalar, puede verificar su configuración con:
npx universal-screenshot-mcp --doctorEsto analiza el host e imprime comandos de instalación que puede copiar y pegar para cualquier herramienta faltante, adaptados a su distribución detectada.
Inicio rápido
Instalar desde npm
npm install -g universal-screenshot-mcpO ejecútelo directamente con npx:
npx universal-screenshot-mcpInstalar desde el código fuente
git clone https://github.com/sethbang/mcp-screenshot-server.git
cd mcp-screenshot-server
npm install
npm run buildConfigure su cliente MCP
Añada el servidor a la configuración de su cliente MCP. Para Claude Desktop, edite ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"screenshot-server": {
"command": "npx",
"args": ["-y", "universal-screenshot-mcp"]
}
}
}O si se instaló desde el código fuente:
{
"mcpServers": {
"screenshot-server": {
"command": "node",
"args": ["/absolute/path/to/mcp-screenshot-server/build/index.js"]
}
}
}Para Claude Code, registre el servidor con el comando 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-mcpO si se instaló desde el código fuente:
claude mcp add screenshot-server -- node /absolute/path/to/mcp-screenshot-server/build/index.jsVerifique que el servidor se registró con claude mcp list, o compruebe el estado en vivo desde una sesión con /mcp.
Para Cursor u otros clientes MCP, consulte su documentación para la configuración equivalente.
Herramientas
El servidor expone dos herramientas MCP:
take_screenshot
Captura una página web (o un elemento específico) a través de un navegador Puppeteer sin interfaz gráfica.
Parámetro | Tipo | Requerido | Descripción |
| string | ✅ | URL a capturar (solo http/https) |
| number | — | Ancho del viewport (1–3840) |
| number | — | Alto del viewport (1–2160) |
| boolean | — | Capturar la página completa desplazable |
| string | — | Selector CSS para capturar un elemento específico |
| string | — | Esperar a este selector antes de capturar |
| number | — | Retraso en milisegundos (0–30000) |
| string | — | Ruta del archivo de salida (predeterminado: |
Ejemplo de prompt:
Toma una captura de pantalla de https://example.com a 1920x1080
take_system_screenshot
Captura el escritorio, una ventana de aplicación específica o una región de la pantalla utilizando herramientas nativas del SO. Funciona en macOS, Linux y Windows.
Parámetro | Tipo | Requerido | Descripción |
| enum | ✅ |
|
| number | — | ID de ventana para el modo ventana |
| string | — | Nombre de la aplicación (ej. |
| object | — |
|
| number | — | Número de pantalla para configuraciones multimonitor |
| boolean | — | Incluir el cursor del ratón en la captura |
| enum | — |
|
| number | — | Retraso de captura en segundos (0–10) |
| string | — | Ruta del archivo de salida (predeterminado: |
Soporte de funciones multiplataforma
Función | macOS | Linux | Windows |
Pantalla completa | ✅ | ✅ | ✅ |
Región | ✅ | ✅ (maim, scrot, grim, import) | ✅ |
Ventana por nombre | ✅ | ⚠️ X11 + xdotool | ⚠️ mejor esfuerzo |
Ventana por ID | ✅ | ✅ solo X11 | ⚠️ HWND |
Multimonitor | ✅ | ⚠️ depende de la herramienta | ✅ |
Incluir cursor | ✅ | ⚠️ depende de la herramienta | ⚠️ |
Retraso | ✅ | ✅ | ✅ |
Ejemplo de prompt:
Toma una captura de pantalla del sistema de la ventana de Safari
Configuración
Variables de entorno
Variable | Predeterminado | Descripción |
|
| Directorio de salida predeterminado relativo a |
|
| Establecer en |
Directorios de salida
Las capturas de pantalla se guardan en ~/Documents/screenshots de forma predeterminada (configurable mediante SCREENSHOT_OUTPUT_DIR). Las rutas de salida personalizadas deben resolverse en uno de estos directorios permitidos:
Directorio | Descripción |
| Ubicación de salida predeterminada (configurable) |
| Ubicación predeterminada original |
| Carpeta de descargas del usuario |
| Carpeta de documentos del usuario |
| Directorio temporal del sistema |
Seguridad
Este servidor implementa múltiples capas de refuerzo de seguridad:
ID | Amenaza | Mitigación |
SEC-001 | SSRF / Rebinding de DNS | URLs validadas contra rangos de IP bloqueados; DNS resuelto antes de la solicitud con fijación de IP mediante |
SEC-003 | Inyección de comandos | Todos los subprocesos utilizan |
SEC-004 | Recorrido de rutas | Rutas de salida validadas con resolución de enlace simbólico |
SEC-005 | Denegación de servicio | Instancias concurrentes de Puppeteer limitadas a 3 mediante semáforo |
Para obtener todos los detalles, consulte docs/security.md.
Desarrollo
Scripts
Comando | Descripción |
| Compilar TypeScript a |
| Recompilar ante cambios de archivo |
| Pruebas unitarias (rápidas, totalmente simuladas) |
| Pruebas de integración (DNS/sistema de archivos real) |
| Pruebas E2E (Puppeteer/herramientas nativas reales) |
| Todos los niveles de prueba juntos |
| E2E de Linux mediante Docker (requiere Docker) |
| Ejecutar pruebas en modo watch |
| Ejecutar pruebas con informe de cobertura |
| Analizar código fuente con ESLint |
| Iniciar el Inspector MCP para depuración |
Estructura del proyecto
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)Pruebas
Las pruebas utilizan Vitest en tres niveles:
Unitarias (
npm test) — Inyección de dependencias completa, sin E/S real. Bucle de retroalimentación rápido.Integración (
npm run test:integration) — Resolución de DNS real, sistema de archivos real con directorios temporales, Puppeteer real contra un servidor HTTP local.E2E (
npm run test:e2e) — Herramientas de captura de pantalla nativas reales. Las pruebas de macOS se ejecutan de forma nativa; las pruebas de Linux se ejecutan en Docker mediantenpm run test:linux.
npm test # Unit tests (~300ms)
npm run test:linux # Linux provider tests in Docker
npm run test:all # EverythingDepuración con el Inspector MCP
npm run inspectorEsto inicia el Inspector MCP conectado a su servidor compilado, lo que le permite invocar herramientas de forma interactiva.
Licencia
Apache-2.0 — Copyright 2026 Seth Bang
Available Tools
2 toolstake_screenshotB
Capture web page or element via headless browser. Saves to ~/Documents/screenshots by default (configurable via SCREENSHOT_OUTPUT_DIR env var).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to capture | |
| width | No | Viewport width | |
| height | No | Viewport height | |
| fullPage | No | Capture full page | |
| selector | No | CSS selector for element | |
| waitForSelector | No | Wait for selector | |
| waitForTimeout | No | Delay in ms | |
| outputPath | No | Absolute path, or relative to home dir |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | fullscreen=entire screen, window=specific app (requires windowName or windowId), region=coordinates | |
| windowId | No | Window ID (for window mode) | |
| windowName | No | App name like "Safari", "Firefox" (for window mode) | |
| region | No | Region {x,y,width,height} | |
| display | No | Display number | |
| includeCursor | No | Include cursor | |
| format | No | Image format (png or jpg) | |
| delay | No | Delay seconds | |
| outputPath | No | Absolute path, or relative to home dir |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v1.2.0- Changed
take_screenshot10 fields changed- added
Input schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - changed
Input schema / properties / fullPage / descriptionPrevious value: -"Capture full scrollable page"New value: +"Capture full page" - changed
Input schema / properties / height / descriptionPrevious value: -"Viewport height in pixels"New value: +"Viewport height" - changed
Input schema / properties / outputPath / descriptionPrevious value: -"Custom output path (optional)"New value: +"Absolute path, or relative to home dir" - added
Input schema / properties / selectorAdded value: +{ + "description": "CSS selector for element", + "type": "string" +} - changed
Input schema / properties / url / descriptionPrevious value: -"URL to capture (can be http://, https://, or file:///)"New value: +"URL to capture" - added
Input schema / properties / waitForSelectorAdded value: +{ + "description": "Wait for selector", + "type": "string" +} - added
Input schema / properties / waitForTimeoutAdded value: +{ + "description": "Delay in ms", + "maximum": 30000, + "minimum": 0, + "type": "number" +} - changed
Input schema / properties / width / descriptionPrevious value: -"Viewport width in pixels"New value: +"Viewport width"
- Added
take_system_screenshot
1 tool update
- First observed
take_screenshot
TDQS
Scored across 2 tools
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.
Both tools follow a consistent verb_noun pattern with snake_case (take_screenshot, take_system_screenshot), using the same 'take_' prefix.
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.
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
Related MCP Connectors
Browserless MCP — wraps the Browserless headless-Chromium REST API (browserless.io)
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
Clean PNG/JPEG screenshots via REST or MCP, with goal-driven multi-step navigation.
Screenshot, PDF, OG-image, and page extraction (markdown/JSON) over MCP. Bearer key or x402.
Related MCP Servers
- AlicenseAqualityDmaintenanceCaptures screenshots of web pages using Puppeteer, allowing AI agents to visually verify web applications and see their progress when generating web apps.557MIT
- AlicenseNot gradedqualityAmaintenanceEnables AI coding assistants to control and inspect a live Chrome browser through Chrome DevTools. Provides browser automation, performance analysis, debugging capabilities, and network request monitoring.1,060,051 npm53,197Apache 2.0
- AlicenseCqualityDmaintenanceEnables 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.1MIT
- AlicenseNot gradedqualityBmaintenanceEnables 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 npmMIT