How do I use GrabzIt 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., "@GrabzIt MCP Server Take a full-page screenshot of https://example.com and describe it." 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.

GrabzIt MCP Server

Official

by GrabzIt

Overview Schema Related Servers Score Discussions

JavaScript

Remote

GrabzIt MCP Server

The official Model Context Protocol (MCP) server for GrabzIt. This server allows AI assistants (like Claude, Cursor, and Windsurf) to dynamically capture website screenshots, generate PDF and DOCX documents, and scrape web data directly within your AI environment.

🚀 Quick Start

This server is published on npm and can be executed instantly without installation using npx.

You will need a GrabzIt Application Key and Secret, which you can get by creating an account at GrabzIt.

Configuration

Add the following configuration to your MCP-compatible client (e.g., claude_desktop_config.json). Replace <YOUR_APP_KEY> and <YOUR_APP_SECRET> with your actual GrabzIt credentials.

{
  "mcpServers": {
    "grabzit": {
      "command": "npx",
      "args": [
        "-y",
        "@grabzit/mcp-server"
      ],
      "env": {
        "GRABZIT_APP_KEY": "<YOUR_APP_KEY>",
        "GRABZIT_APP_SECRET": "<YOUR_APP_SECRET>"
      }
    }
  }
}

Related MCP server: Urlbox MCP Server

🛠️ Environment Variables

The server requires the following environment variables to authenticate with the GrabzIt API:

GRABZIT_APP_KEY - Your GrabzIt Application Key.
GRABZIT_APP_SECRET - Your GrabzIt Application Secret.

Tools

grabzit_inspect_url Captures a screenshot of a URL and returns it as an image that the AI can view directly in context. Supports full page captures, rendering delays for SPAs, element cropping via CSS selectors, and element stripping.
grabzit_scrape_html Extracts fully-rendered HTML from a target URL after JavaScript execution completes. Supports custom rendering delays.
grabzit_convert_url Converts a target URL to an image (png, jpg, svg, tiff), PDF, or DOCX document. Supports page orientation, paper sizing, element cropping/stripping, and rendering delays.
grabzit_convert_html Converts raw HTML string content into an image (png, jpg, svg, tiff), PDF, or DOCX document. Supports page orientation, paper sizing, element cropping/stripping, and rendering delays.

📝 Usage Examples

Once connected, you can ask your AI client prompts like:

"Inspect https://news.ycombinator.com using GrabzIt and tell me what you see in the screenshot."
"Scrape the rendered HTML of https://example.com after waiting 2000ms for dynamic content to load."
"Convert https://example.com into an A4 PDF in landscape orientation using GrabzIt."
"Take this HTML string invoice and convert it into a downloadable DOCX document."

📄 License

This project is open-source and available under the ISC License.

🔒 Privacy Policy

This MCP server acts as a secure bridge between your local AI environment and the GrabzIt API.

Your GRABZIT_APP_KEY and GRABZIT_APP_SECRET remain stored locally on your machine.
Any URLs or HTML data processed through this server are governed by the official GrabzIt Privacy Policy.

Available Tools

4 tools

grabzit_convert_htmlC

Converts raw HTML string to an Image, PDF, or DOCX.

ParametersJSON Schema

Name	Required	Description
`html`	Yes	The URL of the webpage to convert.
`delay`	No	Delay in milliseconds before capture (useful for dynamic SPAs or animations).
`format`	No	Output format. Defaults to 'jpg'.
`pageSize`	No	Paper size for PDF/DOCX formats.
`hideElement`	No	CSS selector of elements to strip out before capture (e.g. '.cookie-banner' or '#popup').
`orientation`	No	Page orientation for PDF/DOCX formats.
`targetElement`	No	CSS selector of a specific element to crop and capture (e.g. '#chart' or '.main-content').

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the basic conversion. It doesn't disclose behaviors like default format ('jpg'), delay handling, or possible limitations (e.g., output file type). Additionally, there is an internal inconsistency: description says 'raw HTML string' while schema says the 'html' parameter expects a URL.

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, front-loaded sentence with no filler. Every word contributes to stating the core function.

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?

The tool has 7 parameters, 3 enums, and no output schema, but the description is too minimal to guide correct invocation. It doesn't mention key parameters, return behavior, or how to choose between output formats. A more detailed description is needed given the tool's complexity.

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

Parameters2/5

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

Schema description coverage is 100%, so baseline is 3, but the description introduces ambiguity by calling input 'raw HTML string' while the schema says it's a URL. This contradicts the parameter description and reduces clarity rather than adding value.

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 a specific verb ('Converts') and resource ('raw HTML string') with target formats ('Image, PDF, or DOCX'). It distinguishes from sibling tools like grabzit_convert_url by emphasizing raw HTML string input, though it doesn't explicitly compare to siblings.

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 guidance on when to use this tool versus alternatives like grabzit_convert_url or grabzit_scrape_html. The description implies usage for HTML string input but provides no context or exclusions.

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

grabzit_convert_urlC

Converts a URL to an Image, PDF, or DOCX.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The URL of the webpage to convert.
`delay`	No	Delay in milliseconds before capture (useful for dynamic SPAs or animations).
`format`	No	Output format. Defaults to 'jpg'.
`pageSize`	No	Paper size for PDF/DOCX formats.
`hideElement`	No	CSS selector of elements to strip out before capture (e.g. '.cookie-banner' or '#popup').
`orientation`	No	Page orientation for PDF/DOCX formats.
`targetElement`	No	CSS selector of a specific element to crop and capture (e.g. '#chart' or '.main-content').

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden for behavioral disclosure, but it only says 'Converts a URL'. It does not explain rendering behavior, potential delays, or how the output is returned. This is a significant gap for a conversion tool.

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, front-loaded sentence with zero wasted words. It perfectly adheres to conciseness, though it may be too terse for other dimensions.

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 no output schema and no annotations, the description should provide more context about the conversion process, return value, or limitations. It is inadequate for a tool with 7 parameters and multiple format options.

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 baseline is 3. The description adds no meaning beyond what the schema already states; even the output types are already covered by the 'format' parameter enum.

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 states a specific verb ('Converts') and resource ('a URL') with the output types (Image, PDF, DOCX). It clearly indicates what the tool does but does not differentiate it from siblings like grabzit_convert_html, so it falls short of a 5.

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 guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or preferred scenarios, leaving the agent to infer usage solely from the tool name.

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

grabzit_inspect_urlB

Captures a screenshot of a URL and returns it as an image that the AI can see.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The URL of the webpage to screenshot.
`delay`	No	Delay in milliseconds before capture (useful for dynamic SPAs or animations).
`fullPage`	No	True to capture the whole page length, False for viewport only.
`hideElement`	No	CSS selector of elements to strip out before capture (e.g. '.cookie-banner' or '#popup').
`targetElement`	No	CSS selector of a specific element to crop and capture (e.g. '#chart' or '.main-content').

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It mentions the output is an image the AI can see, but does not disclose any side effects, limitations (e.g., dynamic content failures), or whether it is a read-only operation. The description adds minimal behavioral context beyond the tool's name.

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 sentence that is clear and direct, with no wasted words. It conveys the essential purpose without unnecessary detail.

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?

For a simple screenshot tool, the description covers the purpose and return type. Although there are no annotations or additional context, the schema fully documents parameters, and the description provides enough to understand the tool's function. Minor gaps exist around edge cases and usage context, but overall it is largely complete.

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?

The schema provides full coverage (100%) for all five parameters, so the description need not elaborate. The description does not add any extra semantics about parameter usage, fitting 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?

The description clearly states it captures a screenshot of a URL and returns an image, using a specific verb and resource. This distinguishes it from sibling tools like grabzit_scrape_html (text scraping) and grabzit_convert_url (URL conversion).

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 guidance is provided on when to use this tool versus alternatives, such as when visual inspection is needed vs. textual extraction. There is no mention of alternatives, exclusions, or prerequisites.

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

grabzit_scrape_htmlA

Extracts fully-rendered HTML from a URL after JavaScript executes.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL of the webpage to scrape.
`delay`	No	Milliseconds to wait for JS rendering before extracting the DOM.

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 must fully disclose behavior. It only mentions JavaScript execution, but does not state whether it makes network requests, is read-only, or how it handles failures. This is minimal behavioral disclosure.

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 sentence that front-loads the core purpose with no redundant or irrelevant information.

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 tool is simple with two parameters and no output schema. The description conveys the main function but omits details on return format, error handling, or when to prefer other tools. It is adequate but not fully complete.

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 parameter details. The schema already documents url and delay, and the description provides no extra semantic value.

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 extracts fully-rendered HTML after JavaScript executes, making the purpose specific and distinct from sibling tools like grabzit_convert_url or grabzit_inspect_url.

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 context of needing JS-rendered HTML is implied, but there is no explicit guidance on when not to use this tool or mention of alternatives. It lacks exclusions but provides a clear enough usage context.

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. Dates show when Glama detected each change.

4 tool updatesv1.0.1Jul 31, 2026
- First observedgrabzit_convert_html
- First observedgrabzit_convert_url
- First observedgrabzit_inspect_url
- First observedgrabzit_scrape_html

Install Server

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

TDQS

B3.4/5.0

Disambiguation4/5

The tools are mostly distinct: scrape_html extracts HTML, inspect_url captures a screenshot, and convert_url/convert_html convert to Image/PDF/DOCX. However, convert_url to image and inspect_url both produce images, which could cause minor confusion in tool selection.

Naming Consistency5/5

All tool names follow a consistent grabzit_<verb>_<object> pattern (scrape_html, inspect_url, convert_url, convert_html). The verbs and objects are uniform, making the naming highly predictable.

Tool Count5/5

With only 4 tools, the server is well-scoped for a web scraping and conversion service. Each tool covers a distinct conversion or extraction need without unnecessary bloat.

Completeness4/5

The tool set covers key operations: HTML scraping, URL inspection, and conversion from both URL and raw HTML. Minor gaps exist such as no explicit text extraction or batch processing, but the core workflow for the domain is well-covered.

Maintenance

ActivitySlowing

ResponsivenessNo issues

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

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
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
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
screenshot A
com.apiscreenshot
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
Browser Automation Image & Video Processing
2

Related MCP Servers

ScreenshotOne MCP Server
Browser Automation Web Scraping App Automation
mrgoonie
A
license
Not graded
quality
D
maintenance
Connects AI assistants to ScreenshotOne.com API for capturing website screenshots with customizable options including viewport size, full-page captures, and multiple output formats.
Updated 9 months ago (2025-11-24 10:08 UTC)
17
3
MIT
Urlbox MCP Serverofficial
Browser Automation Web Scraping Multimedia Processing
urlbox
A
license
B
quality
D
maintenance
Enables users to capture high-quality website screenshots, generate PDFs, and convert web content to HTML or markdown via the Urlbox API. It supports advanced features like ad-blocking, cookie banner removal, and metadata extraction directly through natural language prompts.
Updated a year ago (2025-10-17 10:24 UTC)
2
29
4
MIT
Junipr MCP Server
Web Scraping Browser Automation App Automation
junipr-labs
A
license
Not graded
quality
C
maintenance
Enables AI assistants to capture webpage screenshots, generate PDFs from URLs or HTML, and extract rich metadata like Open Graph and JSON-LD data. It provides tools for web-to-image/PDF conversion and structured data extraction through the Junipr API.
Updated 6 months ago (2026-03-12 06:23 UTC)
15
1
MIT
@rendershot/mcp-serverofficial
Browser Automation Image & Video Processing
Rendershot
A
license
A
quality
D
maintenance
Enables AI agents to capture screenshots and generate PDFs from URLs or HTML via the Rendershot API.
Updated 5 months ago (2026-04-19 00:38 UTC)
4
22
3
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/GrabzIt/GrabzIt.MCP'

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

GrabzIt MCP Server

🚀 Quick Start

Configuration

🛠️ Environment Variables

Tools

📝 Usage Examples

📄 License

🔒 Privacy Policy

Available Tools

TDQS

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

ScreenshotOne MCP Server

Urlbox MCP Serverofficial

Junipr MCP Server

@rendershot/mcp-serverofficial

Latest Blog Posts

MCP directory API