快速、高效的网页截图捕获工具 - 专为 CLI 编码工具优化。自动将整页切分为 1072x1072 的块，以实现最佳处理效果。
本工具专为 AI 视觉工作流构建，通过自动分辨率限制和分块功能，捕获高质量截图，以供 Claude Vision API 和其他 AI 模型进行最佳处理。它确保截图大小精确控制在 1072x1072 像素（115 万像素），以实现最大兼容性。
Related MCP server: Webshot MCP
📸 快速截图捕获：使用 Puppeteer 无头浏览器
🎯 Claude Vision 优化：自动分辨率限制（1072x1072，实现最佳的 115 万像素）
🔲 自动分块：整页自动拆分为 1072x1072 的块
🎬 屏幕录制捕获：以可配置的时间间隔记录一系列截图
🔄 内容始终最新：无缓存机制，确保获取最新的截图
📱 可配置视口：用于响应式测试
⏱️ 等待策略：针对动态内容（networkidle，自定义延迟）
📄 默认整页捕获：用于获取完整的页面截图
🎥 动画 WebP 导出：将屏幕录制保存为高质量的动画 WebP 文件
💉 JavaScript 注入：在屏幕录制捕获前执行自定义 JS
📦 最小化依赖：实现快速 npm 安装
🔌 MCP 集成：实现无缝的 AI 工作流
🪟 Windows 兼容启动器：用于 npm 安装的 MCP 使用
🔋 资源高效：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 或 Claude 的 .mcp.json）。
Node.js 20.x 或更高版本
npm 或 npx
Chrome/Chromium（由 Puppeteer 自动下载）
安装到 IDE 后，可以使用以下工具：
take_screenshot - 捕获网页的高质量截图
参数：
url (必填): 要捕获的 HTTP/HTTPS URL
width (可选): 视口宽度（像素，最大 1072，默认：1072）
height (可选): 视口高度（像素，最大 1072，默认：1072）
fullPage (可选): 是否捕获整页截图并分块（默认：true）
waitUntil (可选): 等待事件：load, domcontentloaded, networkidle0, networkidle2（默认：domcontentloaded）
waitFor (可选): 额外的等待时间（毫秒）
directory (可选): 保存截图的目录 - 返回文件路径而非 base64 图像
capture_selector - 捕获由 CSS 选择器匹配的特定 DOM 元素截图
参数：
url (必填): 要捕获的 HTTP/HTTPS URL
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 秒捕获一次）
基础屏幕录制（10 秒内 5 帧）：
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 参数时：
创建 1 秒间隔的动画 WebP
单帧也会保存为 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 服务器默认包含自动重启功能，以提高可靠性：
如果服务器崩溃，自动重启
处理未捕获的异常和 Promise 拒绝
实现指数退避（1 分钟内最多尝试 10 次）
记录所有重启尝试以供监控
优雅地处理关闭信号（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专为 AI 视觉工作流构建：
针对 Claude Vision API 优化 - 自动分辨率限制为 1072x1072 像素（115 万像素）
自动分块 - 整页拆分为完美的块，供 AI 处理
始终新鲜 - 无缓存确保获取最新内容
MCP 原生 - 与 AI 开发工具的一流集成
简单 API - 简洁明了的截图捕获接口
欢迎贡献！请：
Fork 本仓库
创建功能分支
为新功能添加测试
提交 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.
