CLI 코딩 도구에 최적화된 빠르고 효율적인 웹 페이지 스크린샷 캡처 도구입니다. 전체 페이지를 최적의 처리를 위해 자동으로 1072x1072 청크로 타일링합니다.
AI 비전 워크플로우를 위해 특별히 제작된 이 도구는 Claude Vision API 및 기타 AI 모델에서 최적으로 처리할 수 있도록 자동 해상도 제한 및 타일링 기능을 갖춘 고품질 스크린샷을 캡처합니다. 최대 호환성을 위해 스크린샷 크기를 1072x1072 픽셀(1.15 메가픽셀)로 완벽하게 조정합니다.
Related MCP server: Webshot MCP
📸 빠른 스크린샷 캡처: Puppeteer 헤드리스 브라우저 사용
🎯 Claude Vision 최적화: 자동 해상도 제한 (최적의 1.15 메가픽셀을 위한 1072x1072)
🔲 자동 타일링: 전체 페이지를 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) → 추가
"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 서버는 신뢰성 향상을 위해 기본적으로 자동 재시작 기능을 포함합니다:
충돌 시 서버 자동 재시작
처리되지 않은 예외 및 프로미스 거부 처리
지수 백오프 구현 (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 lintAI 비전 워크플로우를 위해 특별히 제작되었습니다:
Claude Vision API 최적화 - 1072x1072 픽셀(1.15 메가픽셀)로 자동 해상도 제한
자동 타일링 - AI 처리를 위해 전체 페이지를 완벽한 청크로 분할
항상 최신 상태 - 캐싱을 사용하지 않아 최신 콘텐츠 보장
MCP 네이티브 - AI 개발 도구와 일류 통합
간단한 API - 스크린샷 캡처를 위한 깔끔하고 직관적인 인터페이스
기여를 환영합니다! 다음 단계를 따라주세요:
저장소 포크
기능 브랜치 생성
새로운 기능에 대한 테스트 추가
풀 리퀘스트 제출
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.
