How do I use @rendershot/mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@rendershot/mcp-server Take a screenshot of https://example.com" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@rendershot/mcp-server

Official

by Rendershot

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@rendershot/mcp-server

Model Context Protocol (MCP) server for the Rendershot screenshot and PDF generation API. Lets AI agents (Claude, Cursor, etc.) capture screenshots and generate PDFs directly as tool calls.

Source: github.com/Rendershot/rendershot-mcp-server

Quick start

No installation needed — run with npx:

RENDERSHOT_API_KEY=your_key npx @rendershot/mcp-server

Related MCP server: RendShot MCP Server

Claude Desktop setup

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "rendershot": {
      "command": "npx",
      "args": ["-y", "@rendershot/mcp-server"],
      "env": {
        "RENDERSHOT_API_KEY": "your_api_key_here"
      }
    }
  }
}

Cursor / VS Code setup

Add to your MCP settings:

{
  "rendershot": {
    "command": "npx",
    "args": ["-y", "@rendershot/mcp-server"],
    "env": {
      "RENDERSHOT_API_KEY": "your_api_key_here"
    }
  }
}

Environment variables

Variable	Required	Default	Description
`RENDERSHOT_API_KEY`	Yes	—	Your Rendershot API key
`RENDERSHOT_BASE_URL`	No	`https://api.rendershot.io`	API base URL (override for self-hosting)

Tools

`take_screenshot`

Capture a screenshot of a URL or HTML string. Returns a base64-encoded image.

Parameter	Type	Default	Description
`url`	string	—	Page URL to screenshot (one of url/html required)
`html`	string	—	Raw HTML to render (one of url/html required)
`format`	`png` \| `jpeg`	`png`	Output image format
`quality`	1–100	`85`	JPEG quality (ignored for PNG)
`viewport_width`	1–3840	`1280`	Viewport width in pixels
`viewport_height`	1–2160	`720`	Viewport height in pixels
`full_page`	boolean	`false`	Capture the full scrollable page
`wait_for`	string	`dom_content_loaded`	`load` \| `dom_content_loaded` \| `network_idle` \| `commit` \| CSS selector
`delay_ms`	0–10000	`0`	Extra delay after page load (ms)
`ai_cleanup`	`fast` \| `thorough`	—	Remove cookie banners/popups before capture. `fast` uses JS heuristics (1 credit); `thorough` adds an LLM pass (3 credits)
`headers`	`{ [name]: value }`	—	Custom HTTP headers sent with the render request. Max 30, values ≤ 2 KB. `Host` / `Cookie` / `Content-Length` / `Sec-*` / `Connection` rejected
`cookies`	array	—	Session cookies to inject. Each needs `name`, `value`, and one of `domain` / `url`. Optional: `path`, `expires`, `http_only`, `secure`, `same_site` (`Lax` \| `Strict` \| `None`). Max 50
`basic_auth`	`{ username, password }`	—	HTTP Basic auth. Sent on 401 challenge

`generate_pdf`

Generate a PDF from a URL or HTML string. Returns the PDF as a base64-encoded string.

Parameter	Type	Default	Description
`url`	string	—	Page URL (one of url/html required)
`html`	string	—	Raw HTML (one of url/html required)
`format`	`A3` \| `A4` \| `Letter` \| `Legal`	`A4`	Paper size
`orientation`	`portrait` \| `landscape`	`portrait`	Page orientation
`print_background`	boolean	`true`	Print background graphics/colors
`wait_for`	string	`dom_content_loaded`	Same as screenshot
`delay_ms`	0–10000	`0`	Extra delay after page load (ms)
`ai_cleanup`	`fast` \| `thorough`	—	Same as screenshot
`headers`	`{ [name]: value }`	—	Same as screenshot
`cookies`	array	—	Same as screenshot
`basic_auth`	`{ username, password }`	—	Same as screenshot

`bulk_render`

Submit up to 20 screenshot or PDF jobs in one call. All jobs run in parallel and results include base64 output per job.

Parameter	Type	Description
`jobs`	array (1–20)	Array of job objects, each with `type: "screenshot"` or `type: "pdf"` plus the same fields as the individual tools

Returns a JSON object with credits_used, credits_remaining, and a results array containing index, result (base64), and any error per job.

`check_balance`

Check remaining API credits and plan details. No parameters.

Notes

All render calls use async mode internally and poll until the job completes (up to 5 minutes).
Screenshots return MCP image content — agents can display them inline.
PDFs return base64-encoded text; agents can save them to disk or pass them on.
Errors from the API (rate limits, credit exhaustion, invalid URLs) surface as MCP errors with the original error code.

Requirements

Node.js 18+

License

MIT

Available Tools

4 tools

bulk_renderA

Submit up to 20 screenshot or PDF render jobs in a single request. Returns results for all jobs including base64-encoded output.

ParametersJSON Schema

Name	Required	Description	Default
`jobs`	Yes	Array of 1–20 screenshot or PDF jobs to render.
`output_dir`	No	Directory to save all rendered files into. Files are named automatically: 001_screenshot.png, 002_pdf.pdf, etc. If omitted, results are returned as base64 in the response.

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions returning base64-encoded output but does not disclose potential side effects, rate limits, authentication requirements, or whether the tool is read-only or destructive. Does not mention that output_dir saves files to the filesystem.

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?

Single sentence containing all essential information: batch size limit, supported render types, and return format. No unnecessary words or redundant details.

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?

The description is minimal given the tool's complexity (nested jobs with many options). No output schema exists, and the description does not explain the return structure beyond base64 encoding (e.g., per-job status, errors). The schema covers input params adequately but the description could provide more context about the response format.

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% with detailed descriptions for each parameter and nested object. The description adds no new meaning beyond what is already in the schema, meeting the baseline of 3.

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?

Description clearly states it submits up to 20 screenshot or PDF render jobs in a single request and returns base64-encoded results. This distinguishes it from siblings like take_screenshot and generate_pdf which are singular operations.

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?

Implicitly suggests usage for batch operations by mentioning 'up to 20 jobs in a single request', but lacks explicit guidance on when to use this tool versus the singular alternatives. No when-not or exclusion criteria.

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

check_balanceA

Check the remaining API credits and current plan details for the configured API key.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states it checks credits and plan details, which is a read-only operation, but does not explicitly confirm no side effects. For a simple check tool, this is minimally adequate.

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 a single, clear sentence with no wasted words. It is front-loaded with the action and resource.

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

Completeness5/5

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

Given the tool has zero parameters, no output schema, and is a simple status check, the description is complete. It tells the agent what the tool does and what information it returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%. The description does not need to add parameter meaning as there are none. Baseline of 4 is appropriate.

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 uses a specific verb 'check' and identifies the resources 'remaining API credits' and 'current plan details', clearly distinguishing it from sibling tools like bulk_render and generate_pdf which are for generating PDFs and screenshots.

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 checking credits and plan, but does not explicitly state when to use or not use this tool versus alternatives. However, given the siblings are unrelated, the usage context is clear enough.

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

generate_pdfC

Generate a PDF from a web page or HTML content. Returns the PDF as a base64-encoded string.

ParametersJSON Schema

Name	Required	Description	Default
`url`	No	URL of the page to render. Exactly one of url or html is required.
`html`	No	Raw HTML to render. Exactly one of url or html is required.
`format`	No	Paper size.	A4
`orientation`	No	Page orientation.	portrait
`print_background`	No	Print background graphics and colors.
`wait_for`	No	When to consider the page loaded: load \| dom_content_loaded \| network_idle \| commit \| CSS selector.	dom_content_loaded
`delay_ms`	No	Extra delay in milliseconds after page load before capturing.
`ai_cleanup`	No	Remove cookie banners/popups before capture. 'fast' uses JS heuristics (1 credit). 'thorough' adds an LLM pass (3 credits; requires Anthropic key on the server).
`headers`	No	Custom HTTP headers to send with the render request. Use for Bearer tokens, X-Tenant-Id, etc. Host / Cookie / Content-Length / Sec-* / Connection are rejected server-side. Max 30 headers, values ≤ 2 KB.
`cookies`	No	Session cookies to inject before page navigation. Each cookie needs either 'domain' or 'url'. Max 50 per request.
`basic_auth`	No	HTTP Basic auth credentials. Forwarded to the headless browser on a 401 challenge.
`output_path`	No	Absolute or relative path to save the PDF file (e.g. /tmp/invoice.pdf). If omitted, the PDF is returned as base64 in the response.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the basic output format (base64) but omits important details such as maximum page size, render timeouts, or that the 'ai_cleanup' parameter consumes credits. The description lacks transparency about side effects or constraints.

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 very concise: two sentences that front-load the core functionality. No unnecessary words or repetition.

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

Completeness2/5

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

Given the tool's complexity (12 parameters, enums, nested objects, no output schema, no annotations), the description is too sparse. It fails to explain return values when 'output_path' is omitted, credit costs, or error conditions. A more complete description would include these details.

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 description does not need to add much. The description only restates the tool's purpose and does not elaborate on parameter meaning beyond what the schema already provides. This meets the baseline for high 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 function: generate a PDF from a web page or HTML and returns it as base64. While it distinguishes from siblings like 'take_screenshot' (different output format) and 'check_balance' (unrelated), it does not explicitly differentiate from 'bulk_render' which may have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'bulk_render' or 'take_screenshot'. It does not mention prerequisites, limitations, or context for choosing one tool over another.

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

take_screenshotB

Capture a screenshot of a web page or HTML content. Returns a base64-encoded PNG or JPEG image.

ParametersJSON Schema

Name	Required	Description	Default
`url`	No	URL of the page to screenshot. Exactly one of url or html is required.
`html`	No	Raw HTML to render. Exactly one of url or html is required.
`format`	No	Image format.	png
`quality`	No	JPEG quality (1–100). Ignored for PNG.
`viewport_width`	No	Viewport width in pixels.
`viewport_height`	No	Viewport height in pixels.
`full_page`	No	Capture the full scrollable page.
`wait_for`	No	When to consider the page loaded: load \| dom_content_loaded \| network_idle \| commit \| CSS selector.	dom_content_loaded
`delay_ms`	No	Extra delay in milliseconds after page load before capturing.
`ai_cleanup`	No	Remove cookie banners/popups before capture. 'fast' uses JS heuristics (1 credit). 'thorough' adds an LLM pass (3 credits; requires Anthropic key on the server).
`headers`	No	Custom HTTP headers to send with the render request. Use for Bearer tokens, X-Tenant-Id, etc. Host / Cookie / Content-Length / Sec-* / Connection are rejected server-side. Max 30 headers, values ≤ 2 KB.
`cookies`	No	Session cookies to inject before page navigation. Each cookie needs either 'domain' or 'url'. Max 50 per request.
`basic_auth`	No	HTTP Basic auth credentials. Forwarded to the headless browser on a 401 challenge.
`output_path`	No	Absolute or relative path to save the image file (e.g. /tmp/shot.png). If omitted, the image is returned as base64 in the response.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. It doesn't mention non-destructiveness, credit consumption, or failure modes. Only states basic function.

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?

Two sentences with key information front-loaded. No fluff, but could be slightly more structured.

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

Completeness2/5

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

Description omits crucial context like requirement for exactly one of url or html, optional save to file, and cookie handling. Given 14 parameters and no output schema, more context is needed.

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 coverage is 100% with detailed descriptions; description adds nothing beyond stating the return format. Baseline 3 is appropriate.

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?

Description clearly states verb 'capture' and resource 'screenshot of a web page or HTML content', and mentions return format. Distinguishes from siblings by specifying both URL and HTML content options.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives like bulk_render or generate_pdf. The description does not compare or contrast with siblings.

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

A3.7/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: bulk_render for batch jobs, check_balance for credits, generate_pdf and take_screenshot for single outputs. No overlap.

Naming Consistency5/5

All tools use consistent snake_case with verb_noun pattern (bulk_render, check_balance, generate_pdf, take_screenshot).

Tool Count5/5

4 tools is well-scoped for a focused rendering server, covering single and batch operations plus balance checking without unnecessary extras.

Completeness4/5

Covers core rendering tasks (screenshot, PDF, batch) and account monitoring. Minor gap: no way to manage or cancel batch jobs, but results are returned immediately.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcp A
io.github.pictify-io
Generate images, GIFs, and PDFs from HTML, URLs, or templates — from your AI agent.
Image & Video Processing Multimedia Processing
262
snapforge A
org.snapforge
Screenshots, PDFs and Markdown from any URL or HTML for AI agents, via the SnapForge API
Browser Automation Web Scraping
42
Handiworks A
io.github.Lukehal
MCP tools for AI agents: render URLs to image/PDF, check link health, convert HTML/CSV/JSON.
Browser Automation Developer Tools Agent Orchestration
32
Pagewatch A
dev.pagelens
Read a URL as clean markdown, screenshot a website, url to PDF. Web access for agents, no signup.
Browser Automation Web Scraping
52

Related MCP Servers

rendex-mcp
Browser Automation Web Scraping Image & Video Processing
copperline-labs
A
license
A
quality
B
maintenance
Capture screenshots, generate PDFs, and render HTML to images via AI agents. Supports batch capture, geo-targeting, async webhooks, and CSS/JS injection.
Updated 21 days ago (2026-08-14 00:27 UTC)
11
90
7
MIT
RendShot MCP Server
Image & Video Processing Design Tools App Automation
RendShotTeam
F
license
Not graded
quality
D
maintenance
Enables AI agents to generate images from HTML/CSS, capture URL screenshots, and manage reusable templates through the RendShot API. Provides tools for rendering visual content programmatically within AI workflows.
Updated 5 months ago (2026-04-15 03:25 UTC)
14
snapforge-mcp
Browser Automation Image & Video Processing
sporty303
A
license
A
quality
B
maintenance
Enables AI agents to capture screenshots and generate PDFs from URLs or HTML via the SnapForge API.
Updated a month ago (2026-08-03 12:39 UTC)
3
57
MIT
Screenshot API
Browser Automation Web Scraping
raphy78626
A
license
Not graded
quality
B
maintenance
Enables AI agents to capture any public URL as PNG, JPEG, or PDF via REST API or MCP tools, including screenshot capture, page description, and PDF rendering.
Updated a month ago (2026-08-07 10:50 UTC)
17
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Rendershot/rendershot-mcp-server'

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