Skip to main content
Glama
enesjakozh
screenshotone

ScreenshotOne MCP Server

Official
by screenshotone
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ScreenshotOne MCP Server

An official implementation of an MCP (Model Context Protocol) server for ScreenshotOne.

A few more words about why it was built and some thoughts about the future of MCP.

ScreenshotOne also offers an official hosted MCP server. See the ScreenshotOne MCP integration for setup instructions and the latest updates.

Tools

  • render-website-screenshot: Render a website screenshot and return temporary screenshot, content, and slice URLs as requested.

  • extract-website-markdown: Render a website and return its cleaned Markdown directly as text.

  • get-usage: Get ScreenshotOne API quota and concurrency usage.

The screenshot tool exposes these focused options:

  • url

  • block_banners (defaults to true)

  • block_ads (defaults to true)

  • image_quality (defaults to 80)

  • full_page (defaults to false)

  • full_page_slices (defaults to false; requires full_page=true)

  • metadata_content (defaults to false)

  • metadata_content_format (html or markdown; requires metadata_content=true)

The option names and values for metadata content and full-page slices match the ScreenshotOne API. The tool does not expose response-type or cache controls; it always requests a JSON response with API caching disabled.

Set metadata_content=true and metadata_content_format=markdown to receive a temporary Markdown content URL with the screenshot. Set full_page=true and full_page_slices=true to receive smaller vertical screenshot URLs. Slices are preferred when an AI agent needs to analyze a long page that may not be handled reliably as one large image.

A successful capture returns the requested URLs as text and structured content:

{
    "url": "https://<screenshotone-cache-domain>/...",
    "content": {
        "url": "https://<screenshotone-cache-domain>/...",
        "expires": "Sun, 07 Sep 2026 12:00:00 GMT",
        "format": "markdown"
    },
    "slices": [
        {
            "index": 0,
            "offset_y": 0,
            "width": 1280,
            "height": 4000,
            "url": "https://<screenshotone-cache-domain>/..."
        }
    ]
}

The URLs are temporary. The screenshot URL is available for up to four hours, while metadata content includes its exact expiration time. Download any artifact you need to keep.

extract-website-markdown accepts only url. It is a focused shortcut for ScreenshotOne's format=markdown API request and returns the resulting Markdown directly in one MCP text response. Use it when the agent needs to read or analyze page content without a screenshot.

Related MCP server: PuppeteerMCP Server

Usage

Build it

Always install dependencies and build it first:

npm install && npm run build

Get your ScreenshotOne API key

Sign up at ScreenshotOne and get your API key.

Run with npx

Run the CLI directly from the npm package without cloning the repository:

SCREENSHOTONE_API_KEY=your_api_key npx --yes @screenshotone/mcp

With Claude for Desktop

Add the following to your ~/Library/Application\ Support/Claude/claude_desktop_config.json:

{
    "mcpServers": {
        "screenshotone": {
            "command": "npx",
            "args": ["--yes", "@screenshotone/mcp"],
            "env": {
                "SCREENSHOTONE_API_KEY": "<your api key>"
            }
        }
    }
}

Standalone or for other projects

SCREENSHOTONE_API_KEY=your_api_key node build/index.js

License

ScreenshotOne MCP Server is licensed under the MIT License.

Available Tools

1 tool
render-website-screenshotB

Renders a screenshot of a website and returns it as an image or a JSON with the cache URL (preferred for full-page screenshots).

ParametersJSON Schema
NameRequiredDescriptionDefault
block_adsNoBlock ads
block_bannersNoBlock cookie, GDPR, and other banners and popups
cacheNoCache the screenshot to get the cache URL
cache_keyNoCache key to generate a new cache URL for each screenshot, e.g. timestamp
full_pageNoRender the full page screenshot of the website
image_qualityNoImage quality
response_typeNoResponse type: JSON (when the cache URL is needed) or the image itselfby_format
urlYesURL of the website to screenshot

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'returns' outputs but doesn't describe what happens during rendering (e.g., page loading, timeout behavior, error handling), whether it's idempotent, or any rate limits. The description adds minimal context beyond the basic operation, leaving significant behavioral gaps for a tool with 8 parameters.

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 a single, efficient sentence that front-loads the core purpose and key output options. It avoids redundancy and wastes no words, though it could be slightly more structured by separating purpose from usage guidance. Every part earns its place, making it highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, no output schema, no annotations), the description is minimally complete. It covers the basic operation and output types but lacks details on error conditions, performance characteristics, or example usage. Without annotations or output schema, more behavioral context would be helpful, but it's adequate for a starting point.

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 already documents all parameters thoroughly. The description adds marginal value by hinting at the relationship between 'full_page' and cache URL preference, but doesn't provide additional syntax, format details, or usage examples beyond what the schema specifies. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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: 'Renders a screenshot of a website' with the specific verb 'renders' and resource 'website screenshot'. It distinguishes the output options (image or JSON with cache URL) but doesn't need sibling differentiation since no sibling tools exist. The purpose is specific and unambiguous.

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 provides implied usage guidance by mentioning 'preferred for full-page screenshots' for the cache URL option, suggesting when to choose JSON over image output. However, it lacks explicit when/when-not instructions or alternatives, and doesn't address prerequisites like network access or authentication needs. With no sibling tools, this is adequate but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedrender-website-screenshot
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap with other tools. The tool's purpose is clearly defined and distinct by default.

Naming Consistency5/5

A single tool inherently has consistent naming, as there are no other tools to compare against. The name 'render-website-screenshot' follows a clear verb-noun pattern.

Tool Count2/5

A single tool is too few for most server purposes, as it limits functionality and flexibility. While it might suffice for a minimal screenshot service, it feels thin and under-scoped for typical agent workflows.

Completeness3/5

The tool covers the core action of rendering website screenshots, but there are notable gaps such as configuration options (e.g., viewport size, quality settings) or management functions (e.g., listing cached screenshots). This could lead to agent workarounds for advanced use cases.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Screenshot MCP

    upnorthmedia
    A
    license
    B
    quality
    B
    maintenance
    An MCP server that enables capturing website screenshots with full-page, element-specific, and device-responsive capabilities through natural language commands.
    3
    16 npm
    61
    MIT

Appeared in Searches