Быстрое и эффективное создание скриншотов веб-страниц — оптимизировано для инструментов разработки CLI. Автоматически разбивает полные страницы на фрагменты 1072x1072 для оптимальной обработки.
Этот инструмент, созданный специально для рабочих процессов компьютерного зрения ИИ, делает высококачественные скриншоты с автоматическим ограничением разрешения и разбивкой на фрагменты для оптимальной обработки Claude Vision API и другими моделями ИИ. Он гарантирует, что скриншоты имеют идеальный размер 1072x1072 пикселя (1,15 мегапикселя) для максимальной совместимости.
Related MCP server: Webshot MCP
📸 Быстрое создание скриншотов с использованием безголового браузера Puppeteer
🎯 Оптимизировано для Claude Vision с автоматическим ограничением разрешения (1072x1072 для оптимальных 1,15 мегапикселей)
🔲 Автоматическая разбивка на фрагменты — полные страницы автоматически делятся на фрагменты 1072x1072
🎬 Захват скринкастов — запись серии скриншотов с течением времени с настраиваемыми интервалами
🔄 Всегда свежий контент — отсутствие кэширования гарантирует получение актуальных скриншотов
📱 Настраиваемые области просмотра для адаптивного тестирования
⏱️ Стратегии ожидания для динамического контента (networkidle, пользовательские задержки)
📄 Захват всей страницы по умолчанию для получения полных скриншотов страницы
🎥 Экспорт в анимированный WebP — сохранение скринкастов в виде высококачественных анимированных файлов WebP
💉 Внедрение JavaScript — выполнение пользовательского JS перед захватом скринкаста
📦 Минимальные зависимости для быстрой установки через npm
🔌 Интеграция с MCP для бесшовных рабочих процессов ИИ
🪟 Запуск, совместимый с Windows, для использования MCP, установленного через npm
🔋 Эффективное использование ресурсов — автоматическая очистка браузера после 60 секунд бездействия
🧹 Управление памятью — страницы закрываются после каждого скриншота для предотвращения утечек
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=Настройки → Инструменты → AI Assistant → Model Context Protocol (MCP) → Добавить
Выберите "As JSON" и вставьте:
{"command":"npx","args":["-y","@just-every/mcp-screenshot-website-fast"]}{
"mcpServers": {
"screenshot-website-fast": {
"command": "npx",
"args": ["-y", "@just-every/mcp-screenshot-website-fast"]
}
}
}Добавьте это в файл mcp.json вашего клиента (например, .vscode/mcp.json, ~/.cursor/mcp.json или .mcp.json для Claude).
Node.js 20.x или выше
npm или npx
Chrome/Chromium (автоматически загружается Puppeteer)
После установки в вашей IDE будут доступны следующие инструменты:
take_screenshot — создает высококачественный скриншот веб-страницы
Параметры:
url (обязательно): URL HTTP/HTTPS для захвата
width (опционально): ширина области просмотра в пикселях (макс. 1072, по умолчанию: 1072)
height (опционально): высота области просмотра в пикселях (макс. 1072, по умолчанию: 1072)
fullPage (опционально): захват скриншота всей страницы с разбивкой на фрагменты (по умолчанию: true)
waitUntil (опционально): ждать события: load, domcontentloaded, networkidle0, networkidle2 (по умолчанию: domcontentloaded)
waitFor (опционально): дополнительное время ожидания в миллисекундах
directory (опционально): директория для сохранения скриншотов — возвращает пути к файлам вместо изображений в формате base64
capture_selector — создает скриншот конкретного DOM-элемента, найденного по CSS-селектору
Параметры:
url (обязательно): URL HTTP/HTTPS для захвата
selector (обязательно): CSS-селектор элемента для захвата
width (опционально): ширина области просмотра в пикселях (макс. 1072, по умолчанию: 1072)
height (опционально): высота области просмотра в пикселях (макс. 1072, по умолчанию: 1072)
waitUntil (опционально): ждать события: load, domcontentloaded, networkidle0, networkidle2 (по умолчанию: domcontentloaded)
waitForMS (опционально): дополнительное время ожидания в миллисекундах
selectorTimeoutMS (опционально): сколько ждать появления селектора перед ошибкой (по умолчанию: 5000)
Использование по умолчанию (возвращает изображения в base64):
take_screenshot(url="https://example.com")Сохранение в директорию (возвращает пути к файлам):
take_screenshot(url="https://example.com", directory="/path/to/screenshots")Захват конкретного элемента:
capture_selector(url="https://example.com", selector="#main")При использовании параметра directory:
Скриншоты сохраняются как PNG-файлы с метками времени
Вместо данных base64 возвращаются пути к файлам
Для скриншотов с разбивкой на фрагменты каждый фрагмент сохраняется как отдельный файл
Директория создается автоматически, если она не существует
Создает серию скриншотов с течением времени для создания скринкаста. Захватывает только верхний фрагмент (1072x1072) области просмотра.
url (обязательно): URL для захвата
duration (опционально): общая длительность в секундах (по умолчанию: 10)
interval (опционально): интервал между скриншотами в секундах (по умолчанию: 2)
jsEvaluate (опционально): JavaScript-код для выполнения в начале
waitUntil (опционально): стратегия ожидания: 'load', 'domcontentloaded', 'networkidle0', 'networkidle2'
waitForMS (опционально): дополнительное время ожидания перед началом
directory (опционально): сохранить как анимированный WebP в директорию (захватывает каждую 1 секунду)
Базовый скринкаст (5 кадров за 10 секунд):
take_screencast(url="https://example.com")Пользовательский тайминг:
take_screencast(url="https://example.com", duration=15, interval=3)С выполнением JavaScript:
take_screencast(
url="https://example.com",
jsEvaluate="document.body.style.backgroundColor = 'red';"
)Сохранение как анимированный WebP:
take_screencast(url="https://example.com", directory="/path/to/output")При использовании параметра directory:
Создается анимированный WebP с интервалом в 1 секунду
Отдельные кадры также сохраняются как PNG-файлы
Анимация по умолчанию зациклена бесконечно
WebP обеспечивает отличное качество:
Полная поддержка цвета (без ограничения в 256 цветов)
Эффективное сжатие для веб-анимаций
Идеально подходит для градиентных фонов и плавной анимации
Меньший размер файла по сравнению с GIF при лучшем качестве
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> — ширина области просмотра (макс. 1072, по умолчанию: 1072)
-h, --height <pixels> — высота области просмотра (макс. 1072, по умолчанию: 1072)
--no-full-page — отключить захват всей страницы и разбивку на фрагменты
--wait-until <event> — ждать события: load, domcontentloaded, networkidle0, networkidle2
--wait-for <ms> — дополнительное время ожидания в миллисекундах
-o, --output <path> — путь к выходному файлу (обязательно для вывода фрагментов)
MCP-сервер по умолчанию включает возможность автоматического перезапуска для повышения надежности:
Автоматически перезапускает сервер в случае сбоя
Обрабатывает необработанные исключения и отклоненные промисы
Реализует экспоненциальную задержку (макс. 10 попыток за 1 минуту)
Логирует все попытки перезапуска для мониторинга
Корректно обрабатывает сигналы завершения (SIGINT, SIGTERM)
Для разработки/отладки без автоматического перезапуска:
# 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 lintСоздан специально для рабочих процессов компьютерного зрения ИИ:
Оптимизировано для Claude Vision API — автоматическое ограничение разрешения до 1072x1072 пикселей (1,15 мегапикселя)
Автоматическая разбивка на фрагменты — полные страницы делятся на идеальные части для обработки ИИ
Всегда свежий контент — отсутствие кэширования гарантирует получение самого актуального контента
Нативный MCP — первоклассная интеграция с инструментами разработки ИИ
Простой API — чистый и понятный интерфейс для создания скриншотов
Приветствуются любые вклады! Пожалуйста:
Сделайте форк репозитория
Создайте ветку для новой функции
Добавьте тесты для нового функционала
Отправьте pull request
Убедитесь, что Chrome/Chromium может быть загружен
Проверьте настройки брандмауэра
Попробуйте установить PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true и предоставить собственный исполняемый файл
Настройте размеры области просмотра
Используйте соответствующие стратегии ожидания
Проверьте, требует ли сайт аутентификации
Увеличьте время ожидания с помощью флага --wait-for
Используйте другие стратегии --wait-until
Проверьте доступность сайта
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.
