Captura rápida y eficiente de capturas de pantalla de páginas web, optimizada para herramientas de codificación CLI. Divide automáticamente las páginas completas en fragmentos de 1072x1072 para un procesamiento óptimo.
Diseñada específicamente para flujos de trabajo de visión por IA, esta herramienta captura capturas de pantalla de alta calidad con limitación automática de resolución y mosaicos para un procesamiento óptimo por parte de la API de Claude Vision y otros modelos de IA. Asegura que las capturas de pantalla tengan un tamaño perfecto de 1072x1072 píxeles (1.15 megapíxeles) para una máxima compatibilidad.
Related MCP server: Webshot MCP
📸 Captura rápida de pantalla usando el navegador headless Puppeteer
🎯 Optimizado para Claude Vision con limitación automática de resolución (1072x1072 para 1.15 megapíxeles óptimos)
🔲 Mosaico automático - Las páginas completas se dividen automáticamente en mosaicos de 1072x1072
🎬 Captura de screencast - Graba series de capturas de pantalla a lo largo del tiempo con intervalos configurables
🔄 Contenido siempre fresco - Sin caché para asegurar capturas de pantalla actualizadas
📱 Viewports configurables para pruebas responsivas
⏱️ Estrategias de espera para contenido dinámico (networkidle, retrasos personalizados)
📄 Captura de página completa por defecto para capturas de pantalla completas
🎥 Exportación WebP animada - Guarda screencasts como archivos WebP animados de alta calidad
💉 Inyección de JavaScript - Ejecuta JS personalizado antes de la captura del screencast
📦 Dependencias mínimas para instalaciones rápidas de npm
🔌 Integración MCP para flujos de trabajo de IA fluidos
🪟 Lanzador compatible con Windows para uso de MCP instalado vía npm
🔋 Eficiente en recursos - Limpieza automática del navegador después de 60 segundos de inactividad
🧹 Gestión de memoria - Las páginas se cierran después de cada captura de pantalla para evitar fugas
claude mcp add screenshot-website-fast -s user -- npx -y @just-every/mcp-screenshot-website-fastcode --add-mcp '{"name":"screenshot-website-fast","command":"npx","args":["-y","@just-every/mcp-screenshot-website-fast"]}'cursor://anysphere.cursor-deeplink/mcp/install?name=screenshot-website-fast&config=eyJzY3JlZW5zaG90LXdlYnNpdGUtZmFzdCI6eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIkBqdXN0LWV2ZXJ5L21jcC1zY3JlZW5zaG90LXdlYnNpdGUtZmFzdCJdfX0=Configuración → Herramientas → Asistente de IA → Protocolo de Contexto de Modelo (MCP) → Agregar
Elija "Como JSON" y pegue:
{"command":"npx","args":["-y","@just-every/mcp-screenshot-website-fast"]}{
"mcpServers": {
"screenshot-website-fast": {
"command": "npx",
"args": ["-y", "@just-every/mcp-screenshot-website-fast"]
}
}
}Coloque esto en el archivo mcp.json de su cliente (por ejemplo, .vscode/mcp.json, ~/.cursor/mcp.json, o .mcp.json para Claude).
Node.js 20.x o superior
npm o npx
Chrome/Chromium (descargado automáticamente por Puppeteer)
Una vez instalado en su IDE, las siguientes herramientas están disponibles:
take_screenshot - Captura una captura de pantalla de alta calidad de una página web
Parámetros:
url (obligatorio): La URL HTTP/HTTPS a capturar
width (opcional): Ancho del viewport en píxeles (máx 1072, por defecto: 1072)
height (opcional): Alto del viewport en píxeles (máx 1072, por defecto: 1072)
fullPage (opcional): Captura de pantalla de página completa con mosaicos (por defecto: true)
waitUntil (opcional): Esperar hasta el evento: load, domcontentloaded, networkidle0, networkidle2 (por defecto: domcontentloaded)
waitFor (opcional): Tiempo de espera adicional en milisegundos
directory (opcional): Directorio para guardar capturas de pantalla - devuelve rutas de archivo en lugar de imágenes base64
capture_selector - Captura una captura de pantalla de un elemento DOM específico coincidente con un selector CSS
Parámetros:
url (obligatorio): La URL HTTP/HTTPS a capturar
selector (obligatorio): Selector CSS para el elemento a capturar
width (opcional): Ancho del viewport en píxeles (máx 1072, por defecto: 1072)
height (opcional): Alto del viewport en píxeles (máx 1072, por defecto: 1072)
waitUntil (opcional): Esperar hasta el evento: load, domcontentloaded, networkidle0, networkidle2 (por defecto: domcontentloaded)
waitForMS (opcional): Tiempo de espera adicional en milisegundos
selectorTimeoutMS (opcional): Cuánto tiempo esperar a que aparezca el selector antes de fallar (por defecto: 5000)
Uso predeterminado (devuelve imágenes base64):
take_screenshot(url="https://example.com")Guardar en directorio (devuelve rutas de archivo):
take_screenshot(url="https://example.com", directory="/path/to/screenshots")Capturar un elemento específico:
capture_selector(url="https://example.com", selector="#main")Al usar el parámetro directory:
Las capturas de pantalla se guardan como archivos PNG con marcas de tiempo
Se devuelven rutas de archivo en lugar de datos base64
Para capturas de pantalla en mosaico, cada mosaico se guarda como un archivo separado
El directorio se crea automáticamente si no existe
Captura una serie de capturas de pantalla a lo largo del tiempo para crear un screencast. Solo captura el mosaico superior (1072x1072) del viewport.
url (obligatorio): La URL a capturar
duration (opcional): Duración total en segundos (por defecto: 10)
interval (opcional): Intervalo entre capturas de pantalla en segundos (por defecto: 2)
jsEvaluate (opcional): Código JavaScript a ejecutar al inicio
waitUntil (opcional): Estrategia de espera: 'load', 'domcontentloaded', 'networkidle0', 'networkidle2'
waitForMS (opcional): Tiempo de espera adicional antes de comenzar
directory (opcional): Guardar como WebP animado en el directorio (captura cada 1 segundo)
Screencast básico (5 fotogramas en 10 segundos):
take_screencast(url="https://example.com")Temporización personalizada:
take_screencast(url="https://example.com", duration=15, interval=3)Con ejecución de JavaScript:
take_screencast(
url="https://example.com",
jsEvaluate="document.body.style.backgroundColor = 'red';"
)Guardar como WebP animado:
take_screencast(url="https://example.com", directory="/path/to/output")Al usar el parámetro directory:
Se crea un WebP animado con intervalos de 1 segundo
Los fotogramas individuales también se guardan como archivos PNG
La animación se repite para siempre por defecto
WebP proporciona una calidad excelente:
Soporte de color completo (sin limitación de 256 colores)
Compresión eficiente para animaciones web
Perfecto para fondos degradados y animaciones suaves
Tamaños de archivo más pequeños en comparación con GIF con mejor calidad
npm install
npm run build# Full page with automatic tiling (default)
npm run dev capture https://example.com -o screenshot.png
# Viewport-only screenshot
npm run dev capture https://example.com --no-full-page -o screenshot.png
# Wait for specific conditions
npm run dev capture https://example.com --wait-until networkidle0 --wait-for 2000 -o screenshot.png-w, --width <píxeles> - Ancho del viewport (máx 1072, por defecto: 1072)
-h, --height <píxeles> - Alto del viewport (máx 1072, por defecto: 1072)
--no-full-page - Deshabilitar la captura de página completa y el mosaico
--wait-until <evento> - Esperar hasta el evento: load, domcontentloaded, networkidle0, networkidle2
--wait-for <ms> - Tiempo de espera adicional en milisegundos
-o, --output <ruta> - Ruta del archivo de salida (obligatorio para salida en mosaico)
El servidor MCP incluye capacidad de reinicio automático por defecto para una mayor fiabilidad:
Reinicia automáticamente el servidor si falla
Maneja excepciones no controladas y rechazos de promesas
Implementa retroceso exponencial (máx 10 intentos en 1 minuto)
Registra todos los intentos de reinicio para monitoreo
Maneja con elegancia las señales de apagado (SIGINT, SIGTERM)
Para desarrollo/depuración sin reinicio automático:
# Run directly without restart wrapper
npm run serve:devmcp-screenshot-website-fast/
├── src/
│ ├── internal/ # Core screenshot capture logic
│ ├── utils/ # Logger and utilities
│ ├── index.ts # CLI entry point
│ ├── serve.ts # MCP server entry point
│ └── serve-restart.ts # Auto-restart wrapper# Run in development mode
npm run dev capture https://example.com -o screenshot.png
# Build for production
npm run build
# Run tests
npm test
# Type checking
npm run typecheck
# Linting
npm run lintDiseñada específicamente para flujos de trabajo de visión por IA:
Optimizado para la API de Claude Vision - Limitación automática de resolución a 1072x1072 píxeles (1.15 megapíxeles)
Mosaico automático - Páginas completas divididas en fragmentos perfectos para el procesamiento de IA
Siempre fresco - Sin caché para asegurar que obtenga el contenido más reciente
Nativo de MCP - Integración de primera clase con herramientas de desarrollo de IA
API simple - Interfaz limpia y directa para capturar capturas de pantalla
¡Las contribuciones son bienvenidas! Por favor:
Bifurque el repositorio
Cree una rama de características
Agregue pruebas para la nueva funcionalidad
Envíe una solicitud de extracción (pull request)
Asegúrese de que Chrome/Chromium se pueda descargar
Verifique la configuración del firewall
Intente establecer PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true y proporcione un ejecutable personalizado
Ajuste las dimensiones del viewport
Use estrategias de espera apropiadas
Verifique si el sitio requiere autenticación
Aumente el tiempo de espera con la bandera --wait-for
Use diferentes estrategias --wait-until
Verifique si el sitio es accesible
MIT
Capture console output from a web page. Accepts a URL, optional JS command to run, and duration to wait (default 4 seconds). Returns all console messages during that time.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTP/HTTPS URL to capture console from | |
| jsCommand | No | Optional JavaScript command to execute on the page | |
| duration | No | Duration to capture console output in seconds | |
| waitUntil | No | Wait until event: load, domcontentloaded, networkidle0, networkidle2 | domcontentloaded |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and open-world traits, but the description adds valuable behavioral context: it specifies that the tool captures console messages over a duration, returns all messages during that time, and includes defaults (e.g., 4 seconds). This enhances understanding beyond annotations without contradiction.
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 front-loaded with the core purpose in the first sentence, followed by key parameters and return behavior in a second sentence. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
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 the tool's moderate complexity, rich annotations, and full schema coverage, the description is mostly complete. It covers purpose, key parameters, and output behavior, though it lacks details on error handling or specific use cases. With no output schema, it adequately explains returns, but could be slightly enhanced for full completeness.
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?
With 100% schema description coverage, the schema fully documents all parameters. The description adds minimal semantics by mentioning the URL, optional JS command, and duration with default, but does not provide additional meaning beyond what the schema already covers, such as explaining the waitUntil parameter or JS command usage.
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 the specific action ('capture console output'), target resource ('from a web page'), and distinguishes from siblings by focusing on console messages rather than visual captures like take_screencast or take_screenshot. It uses precise language that defines the tool's unique function.
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 capturing console output from web pages but does not explicitly state when to use this tool versus alternatives like take_screencast or take_screenshot. It provides some context with parameters but lacks explicit guidance on scenarios or exclusions, leaving usage somewhat inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a series of screenshots of a web page over time, producing a screencast. Uses adaptive frame rates: 100ms intervals for ≤5s, 200ms for 5-10s, 500ms for >10s. PNG format: individual frames. WebP format: animated WebP with 4-second pause at end for looping.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTP/HTTPS URL to capture | |
| duration | No | Total duration of screencast in seconds | |
| width | No | Viewport width in pixels (max 1072) | |
| height | No | Viewport height in pixels (max 1072) | |
| jsEvaluate | No | JavaScript code to execute. String: single instruction after first screenshot. Array: takes screenshot before each instruction, then continues capturing until duration ends. | |
| waitUntil | No | Wait until event: load, domcontentloaded, networkidle0, networkidle2 | domcontentloaded |
| directory | No | Save screencast to directory. Specify format with "format" parameter. | |
| format | No | Output format when using directory: "png" for individual PNG files, "webp" for animated WebP (default) | webp |
| quality | No | WebP quality level (only applies when format is "webp"): low (50), medium (75), high (90) | medium |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and destructiveHint=false, indicating safe operation. The description adds valuable behavioral context beyond annotations: adaptive frame rates (100ms, 200ms, 500ms intervals), output formats (PNG as individual frames, WebP as animated with 4-second pause), and format-specific details. It does not contradict annotations, as 'capture' aligns with read-only behavior.
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 appropriately sized and front-loaded, starting with the core purpose. It efficiently covers key behavioral traits in two sentences without redundancy. However, it could be slightly more structured by separating format details into distinct points for clarity.
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 the tool's complexity (9 parameters, no output schema) and rich annotations, the description is mostly complete. It explains adaptive frame rates and format behaviors, which are critical for usage. However, it does not cover all contextual aspects like error handling or performance implications, leaving minor 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 description coverage is 100%, so the schema fully documents all 9 parameters. The description adds minimal parameter semantics, mentioning PNG and WebP formats and adaptive frame rates, which relate to 'format' and 'duration' parameters but do not provide significant additional meaning beyond the schema. Baseline 3 is appropriate given high schema coverage.
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 the tool's purpose: 'Capture a series of screenshots of a web page over time, producing a screencast.' It specifies the verb ('capture'), resource ('web page'), and output ('screencast'), distinguishing it from sibling tools like 'take_screenshot' (single screenshot) and 'capture_console' (different resource).
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 through details like adaptive frame rates and format options, suggesting when to use it for time-based captures. However, it lacks explicit guidance on when to choose this tool over alternatives like 'take_screenshot' or 'capture_console', and does not 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.
Fast, efficient screenshot capture of web pages - optimized for CLI coding tools. Use this after performing updates to web pages to ensure your changes are displayed correctly. Automatically tiles full pages into 1072x1072 chunks for optimal processing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTP/HTTPS URL to capture | |
| width | No | Viewport width in pixels (max 1072) | |
| fullPage | No | Capture full page screenshot with tiling. If false, only the viewport is captured. | |
| waitUntil | No | Wait until event: load, domcontentloaded, networkidle0, networkidle2 | domcontentloaded |
| waitForMS | No | Additional wait time in milliseconds | |
| directory | No | Save tiled screenshots to a local directory (returns file paths instead of base64) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral context beyond annotations by specifying tiling behavior (1072x1072 chunks), optimization for CLI tools, and the purpose of verifying web page updates, though it doesn't cover rate limits or auth needs.
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 front-loaded with the core purpose, followed by usage guidelines and technical details, all in three concise sentences with zero wasted words, making it easy to scan and understand quickly.
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 the tool's moderate complexity, rich annotations, and full schema coverage, the description is mostly complete. It lacks details on output format (e.g., base64 vs. file paths) since there's no output schema, but otherwise covers purpose, usage, and key behaviors adequately.
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 schema fully documents all 6 parameters. The description adds minimal parameter semantics by mentioning tiling and optimization, but doesn't provide additional details beyond what the schema already covers, meeting the baseline for high schema coverage.
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 the tool's purpose with specific verbs ('capture', 'tiles') and resources ('web pages'), distinguishing it from sibling tools like capture_console and take_screencast by focusing on static screenshot functionality rather than console logs or video recordings.
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?
It explicitly states when to use this tool ('after performing updates to web pages to ensure your changes are displayed correctly') and provides context about its optimization for CLI coding tools, giving clear guidance without mentioning alternatives directly but implying its niche use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
capture_consoletake_screencasttake_screenshotScored across 3 tools
Each tool has a clearly distinct purpose: capture_console focuses on console output, take_screencast produces animated sequences, and take_screenshot captures static images. There is no overlap in functionality, making it easy for an agent to select the right tool based on the desired outcome.
All tool names follow a consistent verb_noun pattern (capture_console, take_screencast, take_screenshot) with clear, descriptive verbs. The naming is uniform and predictable, enhancing usability and reducing confusion.
With 3 tools, the server is well-scoped for its purpose of capturing different aspects of web pages (console output, screencasts, screenshots). Each tool earns its place by covering a distinct capture method, avoiding bloat or insufficiency.
The tool set provides comprehensive coverage for web page capture: console output, animated screencasts, and static screenshots. There are no obvious gaps, as these tools cover the main use cases for capturing web content in various formats and contexts.
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
Screenshot, PDF and HTML-to-image rendering API so Claude and Cursor can see any web page.
Screenshot, PDF and HTML-to-image rendering API so Claude and Cursor can see any web page.
Screenshot any URL as a hosted image. No local browser; handles bot walls and full-page captures.
