Schnelle, effiziente Erstellung von Webseiten-Screenshots – optimiert für CLI-Coding-Tools. Kachelt vollständige Seiten automatisch in 1072x1072-Blöcke für eine optimale Verarbeitung.
Dieses Tool wurde speziell für KI-Vision-Workflows entwickelt und erstellt hochwertige Screenshots mit automatischer Auflösungsbegrenzung und Kachelung für eine optimale Verarbeitung durch die Claude Vision API und andere KI-Modelle. Es stellt sicher, dass Screenshots für maximale Kompatibilität perfekt auf 1072x1072 Pixel (1,15 Megapixel) skaliert sind.
Related MCP server: Webshot MCP
📸 Schnelle Screenshot-Erstellung mit dem Puppeteer Headless-Browser
🎯 Optimiert für Claude Vision mit automatischer Auflösungsbegrenzung (1072x1072 für optimale 1,15 Megapixel)
🔲 Automatische Kachelung – Vollständige Seiten werden automatisch in 1072x1072-Kacheln unterteilt
🎬 Screencast-Aufnahme – Aufzeichnung von Screenshot-Serien über Zeiträume mit konfigurierbaren Intervallen
🔄 Immer aktuelle Inhalte – Kein Caching stellt sicher, dass die Screenshots aktuell sind
📱 Konfigurierbare Viewports für Responsive-Tests
⏱️ Wartestrategien für dynamische Inhalte (networkidle, benutzerdefinierte Verzögerungen)
📄 Vollständige Seitenaufnahme standardmäßig für komplette Webseiten-Screenshots
🎥 Animierter WebP-Export – Speichern von Screencasts als hochwertige animierte WebP-Dateien
💉 JavaScript-Injektion – Ausführen von benutzerdefiniertem JS vor der Screencast-Aufnahme
📦 Minimale Abhängigkeiten für schnelle npm-Installationen
🔌 MCP-Integration für nahtlose KI-Workflows
🪟 Windows-kompatibler Launcher für die Nutzung von per npm installierten MCPs
🔋 Ressourceneffizient – Automatische Browser-Bereinigung nach 60 Sekunden Inaktivität
🧹 Speicherverwaltung – Seiten werden nach jedem Screenshot geschlossen, um Lecks zu vermeiden
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=Einstellungen → Tools → AI Assistant → Model Context Protocol (MCP) → Hinzufügen
Wählen Sie "As JSON" und fügen Sie Folgendes ein:
{"command":"npx","args":["-y","@just-every/mcp-screenshot-website-fast"]}{
"mcpServers": {
"screenshot-website-fast": {
"command": "npx",
"args": ["-y", "@just-every/mcp-screenshot-website-fast"]
}
}
}Fügen Sie dies in die mcp.json Ihres Clients ein (z. B. .vscode/mcp.json, ~/.cursor/mcp.json oder .mcp.json für Claude).
Node.js 20.x oder höher
npm oder npx
Chrome/Chromium (wird automatisch von Puppeteer heruntergeladen)
Sobald die Installation in Ihrer IDE erfolgt ist, stehen folgende Tools zur Verfügung:
take_screenshot – Erstellt einen hochwertigen Screenshot einer Webseite
Parameter:
url (erforderlich): Die HTTP/HTTPS-URL für die Aufnahme
width (optional): Viewport-Breite in Pixeln (max. 1072, Standard: 1072)
height (optional): Viewport-Höhe in Pixeln (max. 1072, Standard: 1072)
fullPage (optional): Screenshot der gesamten Seite mit Kachelung (Standard: true)
waitUntil (optional): Warten bis Ereignis: load, domcontentloaded, networkidle0, networkidle2 (Standard: domcontentloaded)
waitFor (optional): Zusätzliche Wartezeit in Millisekunden
directory (optional): Verzeichnis zum Speichern der Screenshots – gibt Dateipfade anstelle von base64-Bildern zurück
capture_selector – Erstellt einen Screenshot eines spezifischen DOM-Elements, das durch einen CSS-Selektor gefunden wird
Parameter:
url (erforderlich): Die HTTP/HTTPS-URL für die Aufnahme
selector (erforderlich): CSS-Selektor für das aufzunehmende Element
width (optional): Viewport-Breite in Pixeln (max. 1072, Standard: 1072)
height (optional): Viewport-Höhe in Pixeln (max. 1072, Standard: 1072)
waitUntil (optional): Warten bis Ereignis: load, domcontentloaded, networkidle0, networkidle2 (Standard: domcontentloaded)
waitForMS (optional): Zusätzliche Wartezeit in Millisekunden
selectorTimeoutMS (optional): Wie lange auf das Erscheinen des Selektors gewartet werden soll, bevor abgebrochen wird (Standard: 5000)
Standardnutzung (gibt base64-Bilder zurück):
take_screenshot(url="https://example.com")In Verzeichnis speichern (gibt Dateipfade zurück):
take_screenshot(url="https://example.com", directory="/path/to/screenshots")Ein spezifisches Element aufnehmen:
capture_selector(url="https://example.com", selector="#main")Bei Verwendung des directory-Parameters:
Screenshots werden als PNG-Dateien mit Zeitstempeln gespeichert
Dateipfade werden anstelle von base64-Daten zurückgegeben
Bei gekachelten Screenshots wird jede Kachel als separate Datei gespeichert
Das Verzeichnis wird automatisch erstellt, falls es nicht existiert
Erstellt eine Serie von Screenshots über einen Zeitraum, um einen Screencast zu erzeugen. Erfasst nur die oberste Kachel (1072x1072) des Viewports.
url (erforderlich): Die URL für die Aufnahme
duration (optional): Gesamtdauer in Sekunden (Standard: 10)
interval (optional): Intervall zwischen Screenshots in Sekunden (Standard: 2)
jsEvaluate (optional): JavaScript-Code, der zu Beginn ausgeführt werden soll
waitUntil (optional): Wartestrategie: 'load', 'domcontentloaded', 'networkidle0', 'networkidle2'
waitForMS (optional): Zusätzliche Wartezeit vor dem Start
directory (optional): Als animiertes WebP im Verzeichnis speichern (erfasst jede Sekunde)
Einfacher Screencast (5 Frames über 10 Sekunden):
take_screencast(url="https://example.com")Benutzerdefiniertes Timing:
take_screencast(url="https://example.com", duration=15, interval=3)Mit JavaScript-Ausführung:
take_screencast(
url="https://example.com",
jsEvaluate="document.body.style.backgroundColor = 'red';"
)Als animiertes WebP speichern:
take_screencast(url="https://example.com", directory="/path/to/output")Bei Verwendung des directory-Parameters:
Ein animiertes WebP wird mit 1-Sekunden-Intervallen erstellt
Einzelne Frames werden ebenfalls als PNG-Dateien gespeichert
Die Animation läuft standardmäßig in einer Endlosschleife
WebP bietet exzellente Qualität:
Volle Farbuntersützung (keine 256-Farben-Beschränkung)
Effiziente Komprimierung für Web-Animationen
Perfekt für Verlaufs-Hintergründe und flüssige Animationen
Kleinere Dateigrößen im Vergleich zu GIF bei besserer Qualität
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 <pixels> - Viewport-Breite (max. 1072, Standard: 1072)
-h, --height <pixels> - Viewport-Höhe (max. 1072, Standard: 1072)
--no-full-page - Deaktiviert die Aufnahme der gesamten Seite und die Kachelung
--wait-until <event> - Warten bis Ereignis: load, domcontentloaded, networkidle0, networkidle2
--wait-for <ms> - Zusätzliche Wartezeit in Millisekunden
-o, --output <path> - Ausgabedateipfad (erforderlich für gekachelte Ausgabe)
Der MCP-Server enthält standardmäßig eine automatische Neustartfunktion für verbesserte Zuverlässigkeit:
Startet den Server automatisch neu, wenn er abstürzt
Behandelt unbehandelte Ausnahmen und Promise-Rejections
Implementiert exponentielles Backoff (max. 10 Versuche in 1 Minute)
Protokolliert alle Neustartversuche zur Überwachung
Behandelt Shutdown-Signale (SIGINT, SIGTERM) ordnungsgemäß
Für Entwicklung/Debugging ohne automatischen Neustart:
# 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 lintSpeziell für KI-Vision-Workflows entwickelt:
Optimiert für Claude Vision API - Automatische Auflösungsbegrenzung auf 1072x1072 Pixel (1,15 Megapixel)
Automatische Kachelung - Vollständige Seiten werden für die KI-Verarbeitung in perfekte Blöcke unterteilt
Immer frisch - Kein Caching stellt sicher, dass Sie die neuesten Inhalte erhalten
MCP-nativ - Erstklassige Integration in KI-Entwicklungstools
Einfache API - Saubere, unkomplizierte Schnittstelle für die Screenshot-Erstellung
Beiträge sind willkommen! Bitte:
Forken Sie das Repository
Erstellen Sie einen Feature-Branch
Fügen Sie Tests für neue Funktionen hinzu
Senden Sie einen Pull Request
Stellen Sie sicher, dass Chrome/Chromium heruntergeladen werden kann
Überprüfen Sie die Firewall-Einstellungen
Versuchen Sie, PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true zu setzen und eine benutzerdefinierte ausführbare Datei anzugeben
Passen Sie die Viewport-Dimensionen an
Verwenden Sie geeignete Wartestrategien
Prüfen Sie, ob die Seite eine Authentifizierung erfordert
Erhöhen Sie die Wartezeit mit dem --wait-for-Flag
Verwenden Sie andere --wait-until-Strategien
Prüfen Sie, ob die Seite erreichbar ist
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.
