Skip to main content
Glama
deenesjakoruzh
just-every

Screenshot Website Fast

by just-every
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

@just-every/mcp-screenshot-website-fast

Fast, efficient screenshot capture of web pages - optimized for CLI coding tools. Automatically tiles full pages into 1072x1072 chunks for optimal processing.

npm version GitHub Actions

Overview

Built specifically for AI vision workflows, this tool captures high-quality screenshots with automatic resolution limiting and tiling for optimal processing by Claude Vision API and other AI models. It ensures screenshots are perfectly sized at 1072x1072 pixels (1.15 megapixels) for maximum compatibility.

Related MCP server: Webshot MCP

Features

  • 📸 Fast screenshot capture using Puppeteer headless browser

  • 🎯 Claude Vision optimized with automatic resolution limiting (1072x1072 for optimal 1.15 megapixels)

  • 🔲 Automatic tiling - Full pages are automatically split into 1072x1072 tiles

  • 🎬 Screencast capture - Record series of screenshots over time with configurable intervals

  • 🔄 Always fresh content - No caching ensures up-to-date screenshots

  • 📱 Configurable viewports for responsive testing

  • ⏱️ Wait strategies for dynamic content (networkidle, custom delays)

  • 📄 Full page capture by default for complete page screenshots

  • 🎥 Animated WebP export - Save screencasts as high-quality animated WebP files

  • 💉 JavaScript injection - Execute custom JS before screencast capture

  • 📦 Minimal dependencies for fast npm installs

  • 🔌 MCP integration for seamless AI workflows

  • 🪟 Windows-compatible launcher for npm-installed MCP usage

  • 🔋 Resource efficient - Automatic browser cleanup after 60 seconds of inactivity

  • 🧹 Memory management - Pages are closed after each screenshot to prevent leaks

Installation

Claude Code

claude mcp add screenshot-website-fast -s user -- npx -y @just-every/mcp-screenshot-website-fast

VS Code

code --add-mcp '{"name":"screenshot-website-fast","command":"npx","args":["-y","@just-every/mcp-screenshot-website-fast"]}'

Cursor

cursor://anysphere.cursor-deeplink/mcp/install?name=screenshot-website-fast&config=eyJzY3JlZW5zaG90LXdlYnNpdGUtZmFzdCI6eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIkBqdXN0LWV2ZXJ5L21jcC1zY3JlZW5zaG90LXdlYnNpdGUtZmFzdCJdfX0=

JetBrains IDEs

Settings → Tools → AI Assistant → Model Context Protocol (MCP) → Add

Choose "As JSON" and paste:

{"command":"npx","args":["-y","@just-every/mcp-screenshot-website-fast"]}

Raw JSON (works in any MCP client)

{
  "mcpServers": {
    "screenshot-website-fast": {
      "command": "npx",
      "args": ["-y", "@just-every/mcp-screenshot-website-fast"]
    }
  }
}

Drop this into your client's mcp.json (e.g. .vscode/mcp.json, ~/.cursor/mcp.json, or .mcp.json for Claude).

Prerequisites

  • Node.js 20.x or higher

  • npm or npx

  • Chrome/Chromium (automatically downloaded by Puppeteer)

Quick Start

MCP Server Usage

Once installed in your IDE, the following tools are available:

Available Tools

  • take_screenshot - Captures a high-quality screenshot of a webpage

    • Parameters:

      • url (required): The HTTP/HTTPS URL to capture

      • width (optional): Viewport width in pixels (max 1072, default: 1072)

      • height (optional): Viewport height in pixels (max 1072, default: 1072)

      • fullPage (optional): Capture full page screenshot with tiling (default: true)

      • waitUntil (optional): Wait until event: load, domcontentloaded, networkidle0, networkidle2 (default: domcontentloaded)

      • waitFor (optional): Additional wait time in milliseconds

      • directory (optional): Directory to save screenshots - returns file paths instead of base64 images

  • capture_selector - Captures a screenshot of a specific DOM element matched by a CSS selector

    • Parameters:

      • url (required): The HTTP/HTTPS URL to capture

      • selector (required): CSS selector for the element to capture

      • width (optional): Viewport width in pixels (max 1072, default: 1072)

      • height (optional): Viewport height in pixels (max 1072, default: 1072)

      • waitUntil (optional): Wait until event: load, domcontentloaded, networkidle0, networkidle2 (default: domcontentloaded)

      • waitForMS (optional): Additional wait time in milliseconds

      • selectorTimeoutMS (optional): How long to wait for the selector to appear before failing (default: 5000)

Usage Examples

Default usage (returns base64 images):

take_screenshot(url="https://example.com")

Save to directory (returns file paths):

take_screenshot(url="https://example.com", directory="/path/to/screenshots")

Capture a specific element:

capture_selector(url="https://example.com", selector="#main")

When using the directory parameter:

  • Screenshots are saved as PNG files with timestamps

  • File paths are returned instead of base64 data

  • For tiled screenshots, each tile is saved as a separate file

  • Directory is created automatically if it doesn't exist

take_screencast

Captures a series of screenshots over time to create a screencast. Only captures the top tile (1072x1072) of the viewport.

Parameters

  • url (required): The URL to capture

  • duration (optional): Total duration in seconds (default: 10)

  • interval (optional): Interval between screenshots in seconds (default: 2)

  • jsEvaluate (optional): JavaScript code to execute at the start

  • waitUntil (optional): Wait strategy: 'load', 'domcontentloaded', 'networkidle0', 'networkidle2'

  • waitForMS (optional): Additional wait time before starting

  • directory (optional): Save as animated WebP to directory (captures every 1 second)

Usage Examples

Basic screencast (5 frames over 10 seconds):

take_screencast(url="https://example.com")

Custom timing:

take_screencast(url="https://example.com", duration=15, interval=3)

With JavaScript execution:

take_screencast(
  url="https://example.com",
  jsEvaluate="document.body.style.backgroundColor = 'red';"
)

Save as animated WebP:

take_screencast(url="https://example.com", directory="/path/to/output")

When using the directory parameter:

  • An animated WebP is created with 1-second intervals

  • Individual frames are also saved as PNG files

  • The animation loops forever by default

  • WebP provides excellent quality:

    • Full color support (no 256 color limitation)

    • Efficient compression for web animations

    • Perfect for gradient backgrounds and smooth animations

    • Smaller file sizes compared to GIF with better quality

Development Usage

Install

npm install
npm run build

Capture screenshot

# 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

CLI Options

  • -w, --width <pixels> - Viewport width (max 1072, default: 1072)

  • -h, --height <pixels> - Viewport height (max 1072, default: 1072)

  • --no-full-page - Disable full page capture and tiling

  • --wait-until <event> - Wait until event: load, domcontentloaded, networkidle0, networkidle2

  • --wait-for <ms> - Additional wait time in milliseconds

  • -o, --output <path> - Output file path (required for tiled output)

Auto-Restart Feature

The MCP server includes automatic restart capability by default for improved reliability:

  • Automatically restarts the server if it crashes

  • Handles unhandled exceptions and promise rejections

  • Implements exponential backoff (max 10 attempts in 1 minute)

  • Logs all restart attempts for monitoring

  • Gracefully handles shutdown signals (SIGINT, SIGTERM)

For development/debugging without auto-restart:

# Run directly without restart wrapper
npm run serve:dev

Architecture

mcp-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

Development

# 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

Why This Tool?

Built specifically for AI vision workflows:

  1. Optimized for Claude Vision API - Automatic resolution limiting to 1072x1072 pixels (1.15 megapixels)

  2. Automatic tiling - Full pages split into perfect chunks for AI processing

  3. Always fresh - No caching ensures you get the latest content

  4. MCP native - First-class integration with AI development tools

  5. Simple API - Clean, straightforward interface for capturing screenshots

Contributing

Contributions are welcome! Please:

  1. Fork the repository

  2. Create a feature branch

  3. Add tests for new functionality

  4. Submit a pull request

Troubleshooting

Puppeteer Issues

  • Ensure Chrome/Chromium can be downloaded

  • Check firewall settings

  • Try setting PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true and provide custom executable

Screenshot Quality

  • Adjust viewport dimensions

  • Use appropriate wait strategies

  • Check if site requires authentication

Timeout Errors

  • Increase wait time with --wait-for flag

  • Use different --wait-until strategies

  • Check if site is accessible

License

MIT

Available Tools

3 tools
capture_consoleA
Read-only

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesHTTP/HTTPS URL to capture console from
jsCommandNoOptional JavaScript command to execute on the page
durationNoDuration to capture console output in seconds
waitUntilNoWait until event: load, domcontentloaded, networkidle0, networkidle2domcontentloaded

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

take_screencastA
Read-only

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesHTTP/HTTPS URL to capture
durationNoTotal duration of screencast in seconds
widthNoViewport width in pixels (max 1072)
heightNoViewport height in pixels (max 1072)
jsEvaluateNoJavaScript code to execute. String: single instruction after first screenshot. Array: takes screenshot before each instruction, then continues capturing until duration ends.
waitUntilNoWait until event: load, domcontentloaded, networkidle0, networkidle2domcontentloaded
directoryNoSave screencast to directory. Specify format with "format" parameter.
formatNoOutput format when using directory: "png" for individual PNG files, "webp" for animated WebP (default)webp
qualityNoWebP quality level (only applies when format is "webp"): low (50), medium (75), high (90)medium

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

take_screenshotA
Read-only

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesHTTP/HTTPS URL to capture
widthNoViewport width in pixels (max 1072)
fullPageNoCapture full page screenshot with tiling. If false, only the viewport is captured.
waitUntilNoWait until event: load, domcontentloaded, networkidle0, networkidle2domcontentloaded
waitForMSNoAdditional wait time in milliseconds
directoryNoSave tiled screenshots to a local directory (returns file paths instead of base64)

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityActive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/just-every/mcp-screenshot-website-fast'

If you have feedback or need assistance with the MCP directory API, please join our Discord server