SnapAPI 的 MCP (Model Context Protocol) 服务器 — 可直接从 Claude Desktop、Cursor、Windsurf、Cline 和 Zed 等 AI 工具中截取屏幕截图、抓取网页、提取内容、生成 PDF、录制视频并分析页面。
此包运行一个本地 MCP 服务器，将您的 AI 助手连接到 SnapAPI 网络捕获 API。配置完成后，您的 AI 可以：
截取屏幕截图：支持任何 URL（全页、移动端、深色模式、元素选择、设备模拟）
抓取网页：使用真实浏览器获取干净的文本、HTML 或链接列表
提取内容：针对 LLM 使用进行优化（Markdown、文章、元数据、结构化数据）
生成 PDF：从 URL 或 HTML 生成
录制视频：录制浏览器会话，支持可选的交互场景
分析页面：通过 AI 进行分析（一次调用即可完成提取 + 分析）
检查使用情况：查看配额和账户统计信息
Related MCP server: Local-MCP-server
Node.js 18 或更高版本
SnapAPI API 密钥 — 请在 app.snapapi.pics 获取
添加到 ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 或 %APPDATA%\Claude\claude_desktop_config.json (Windows)：
{
"mcpServers": {
"snapapi": {
"command": "npx",
"args": ["-y", "snapapi-mcp"],
"env": {
"SNAPAPI_API_KEY": "sk_live_your_key_here"
}
}
}
}保存后重启 Claude Desktop。
添加到 ~/.cursor/mcp.json：
{
"mcpServers": {
"snapapi": {
"command": "npx",
"args": ["-y", "snapapi-mcp"],
"env": {
"SNAPAPI_API_KEY": "sk_live_your_key_here"
}
}
}
}添加到 ~/.codeium/windsurf/mcp_config.json：
{
"mcpServers": {
"snapapi": {
"command": "npx",
"args": ["-y", "snapapi-mcp"],
"env": {
"SNAPAPI_API_KEY": "sk_live_your_key_here"
}
}
}
}打开 Cline 设置 → MCP Servers → Add Server：
Command: npx
Args: -y snapapi-mcp
Environment: SNAPAPI_API_KEY=sk_live_your_key_here
添加到工作区（或用户设置）的 .vscode/mcp.json 中：
{
"servers": {
"snapapi": {
"command": "npx",
"args": ["-y", "snapapi-mcp"],
"env": {
"SNAPAPI_API_KEY": "sk_live_your_key_here"
}
}
}
}添加到 ~/.config/zed/settings.json：
{
"context_servers": {
"snapapi": {
"command": {
"path": "npx",
"args": ["-y", "snapapi-mcp"],
"env": {
"SNAPAPI_API_KEY": "sk_live_your_key_here"
}
}
}
}
}运行随附的辅助脚本：
# For Claude Desktop
./install-mcp.sh claude
# For Cursor
./install-mcp.sh cursor
# For Windsurf
./install-mcp.sh windsurf验证 SnapAPI 是否可达且您的 API 密钥有效。无需参数。
示例提示词： "Ping SnapAPI 以检查其是否正常工作"
截取任何 URL 的屏幕截图，并提供丰富的自定义选项。
参数：
参数 | 类型 | 必需 | 描述 |
| string | * | 要捕获的 URL |
| string | * | 要渲染的原始 HTML（URL 的替代方案） |
| string | * | 要渲染的 Markdown（URL 的替代方案） |
| string | 否 |
|
| number | 否 | jpeg/webp 的质量 1–100（默认：80） |
| number | 否 | 视口宽度（默认：1280） |
| number | 否 | 视口高度（默认：800） |
| boolean | 否 | 捕获整个可滚动页面 |
| string | 否 | 用于元素捕获的 CSS 选择器 |
| number | 否 | 页面加载后捕获前的等待时间（毫秒） |
| string | 否 |
|
| boolean | 否 | 深色配色方案 |
| boolean | 否 | 拦截广告网络 |
| boolean | 否 | 拦截 Cookie 弹窗 |
| string | 否 | 要注入的自定义 CSS |
| string | 否 | 要执行的自定义 JS |
| string | 否 | 设备预设（例如 |
| string[] | 否 | 捕获前要隐藏的元素 |
*必须提供 url, html 或 markdown 中的至少一个。
示例提示词：
"在深色模式下截取 https://example.com 的屏幕截图"
"在 iPhone 15 Pro 上截取 https://github.com"
"截取 https://news.ycombinator.com 的全页截图并拦截广告"
"将此 HTML 渲染为截图：<h1>Hello</h1>"
使用真实浏览器抓取网页内容（支持 JavaScript 渲染的页面）。
参数：
参数 | 类型 | 必需 | 描述 |
| string | 是 | 要抓取的 URL |
| string | 否 |
|
| number | 否 | 要跟踪的页面数，1–10（默认：1） |
| number | 否 | 页面加载后的额外等待时间（毫秒） |
| boolean | 否 | 拦截图像/媒体/字体以加快速度 |
| string | 否 | 浏览器区域设置（例如 |
| boolean | 否 | 使用住宅代理绕过拦截 |
示例提示词：
"抓取 https://example.com/blog 的文本内容"
"获取 https://news.ycombinator.com 的所有链接"
"以 HTML 格式抓取 https://example.com/pricing"
提取针对 LLM 优化的干净、结构化的内容。
参数：
参数 | 类型 | 必需 | 描述 |
| string | 是 | 要提取的 URL |
| string | 否 |
|
| string | 否 | 将提取范围限定为 CSS 元素 |
| string | 否 | 提取前等待 CSS 选择器 |
| number | 否 | 最大字符长度 |
| boolean | 否 | 移除噪音（默认：true） |
| boolean | 否 | 拦截广告网络 |
| boolean | 否 | 拦截 Cookie 弹窗 |
| object | 否 | 自定义字段提取映射 |
示例提示词：
"将 https://example.com/post 的文章内容提取为 markdown"
"从 https://example.com 获取元数据（标题、描述、OG 图像）"
"从 https://example.com/product 提取价格和评分"
从 URL 或 HTML 生成 PDF。
参数：
参数 | 类型 | 必需 | 描述 |
| string | * | 要转换为 PDF 的 URL |
| string | * | 要转换为 PDF 的 HTML（URL 的替代方案） |
| string | 否 |
|
| boolean | 否 | 横向模式 |
| boolean | 否 | 包含背景图形 |
| number | 否 | 缩放比例 0.1–2 |
| string | 否 | 上边距，例如 |
| string | 否 | 下边距 |
| string | 否 | 左边距 |
| string | 否 | 右边距 |
| number | 否 | 页面加载后的等待时间（毫秒） |
| string | 否 |
|
*必须提供 url 或 html 中的至少一个。
示例提示词：
"将 https://example.com/report 生成为横向 A4 PDF"
"将此 HTML 转换为带有 2cm 边距的 PDF"
在一次调用中从 URL 提取内容并使用 AI 模型进行分析。
参数：
参数 | 类型 | 必需 | 描述 |
| string | 是 | 要分析的 URL |
| string | 是 | AI 的分析指令 |
| string | 否 |
|
| number | 否 | 传递给 AI 的最大字符数（默认：20000） |
示例提示词：
"分析 https://example.com/article — 主要论点是什么？"
"从 https://example.com/product 提取所有产品规格"
"这篇新闻文章的情感倾向是什么：https://example.com/news"
将浏览器会话录制为视频 (WebM)。
参数：
参数 | 类型 | 必需 | 描述 |
| string | 是 | 要录制的 URL |
| number | 否 | 录制时长（秒），1–60（默认：5） |
| number | 否 | 视口宽度（默认：1280） |
| number | 否 | 视口高度（默认：800） |
| string | 否 | 录制期间运行的 JavaScript（滚动、点击等） |
| number | 否 | 开始录制前的等待时间（毫秒） |
| string | 否 |
|
| boolean | 否 | 深色配色方案 |
| boolean | 否 | 拦截广告网络 |
| boolean | 否 | 拦截 Cookie 弹窗 |
| string | 否 | 设备预设 — 使用 |
示例提示词：
"录制一段 10 秒的 https://example.com 向下滚动的视频"
"在 iPhone 15 Pro 上录制 https://example.com"
检查您的 SnapAPI 配额和月度统计信息。无需参数。
示例提示词：
"我这个月还剩多少 SnapAPI 请求？"
"显示我的 SnapAPI 使用情况"
列出所有可用于屏幕截图和视频模拟的设备预设。无需参数。
示例提示词： "有哪些可用于截图的设备预设？"
变量 | 必需 | 描述 |
| 是 | 您的 SnapAPI API 密钥 ( |
| 否 | API 基础 URL（默认： |
# Clone the repo
git clone https://github.com/Sleywill/snapapi-mcp.git
cd snapapi-mcp
# Install dependencies
npm install
# Build
npm run build
# Run locally (reads MCP protocol from stdin)
SNAPAPI_API_KEY=sk_live_your_key node dist/index.js"SNAPAPI_API_KEY environment variable is required"
确保 MCP 配置中的 env 块包含您的 API 密钥。检查它是否以 sk_live_ 开头。
工具未在 Claude Desktop 中显示 保存配置后重启 Claude Desktop。检查 MCP 日志：
macOS: ~/Library/Logs/Claude/mcp*.log
Windows: %APPDATA%\Claude\logs\mcp*.log
npx 首次运行时耗时过长
使用 "args": ["-y", "snapapi-mcp"] — -y 标志会自动确认安装提示，无需交互。
screenshot / scrape 返回错误
在 app.snapapi.pics/dashboard 验证您的 API 密钥是否有效
使用 get_usage 工具检查剩余配额
对于 JavaScript 繁重的页面，尝试添加 "waitUntil": "networkidle" 和 "delay" 值
analyze 工具返回错误
分析端点需要 SnapAPI 后端上的 Anthropic API 额度。使用 extract 工具作为回退方案来获取页面内容并自行分析。
MIT
Extract content from a URL and analyze it with an AI model. Returns AI-generated insights, summaries, sentiment, or custom analysis based on your prompt. Combines web extraction with LLM analysis in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to extract and analyze. | |
| prompt | Yes | The analysis instruction for the AI, e.g. 'Summarize the key points', 'Extract all product specifications', 'What is the overall sentiment?' | |
| extractType | No | How to extract the page content before analysis (default: article). | |
| maxLength | No | Maximum characters of extracted content to pass to the AI (default: 20000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses critical AI-model usage ('analyze it with an AI model', 'AI-generated insights') which explains the non-deterministic nature, but omits other behavioral traits like idempotency, latency implications, or cost/rate limits.
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?
Three tightly constructed sentences with zero waste. Front-loaded with the core action (extract+analyze), followed by return values, and ending with sibling differentiation. Every sentence earns its place.
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 no output schema, the description adequately covers return values ('AI-generated insights, summaries...'). Addresses the tool's complexity (AI processing) but could strengthen with mention of error conditions or latency expectations typical of LLM calls.
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 has 100% description coverage, establishing baseline 3. The description adds high-level context that the prompt drives 'custom analysis', but does not augment specific parameter semantics (formats, enum usage patterns) beyond what the schema already documents.
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 uses specific verbs ('Extract', 'analyze') with clear resource ('URL') and distinguishes from siblings like 'extract' and 'scrape' by explicitly stating 'Combines web extraction with LLM analysis in one call', clarifying the AI-powered differentiation.
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?
Implies when to use versus alternatives by emphasizing the combined extraction+analysis workflow ('in one call'), but lacks explicit guidance on when NOT to use it (e.g., 'use extract for raw content without AI processing').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract clean, structured content from a URL. Returns Markdown, plain text, article data (via Mozilla Readability), OG metadata, links, images, or custom structured fields. Optimized for feeding web content to LLMs without HTML noise.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to extract content from. | |
| type | No | Extraction mode (default: markdown). 'article' uses Mozilla Readability for article body extraction. 'structured' returns title, author, word count, and cleaned content. 'metadata' returns OG tags and meta fields. 'links' and 'images' return lists of URLs. | |
| selector | No | CSS selector to scope extraction to a specific element. | |
| waitFor | No | CSS selector to wait for before extracting. | |
| maxLength | No | Maximum character length of the returned content. | |
| cleanOutput | No | Remove excess whitespace and empty links (default: true). | |
| darkMode | No | Render the page with dark color scheme. | |
| blockAds | No | Block ad networks. | |
| blockCookieBanners | No | Block cookie consent popups. | |
| fields | No | Custom field extraction map: keys are field names, values describe what to extract. Example: {"price": "product price as a number", "rating": "star rating out of 5"}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable implementation context by noting the use of 'Mozilla Readability' and 'HTML noise' removal, but lacks disclosure on error handling, rate limiting, authentication requirements, or timeout behavior expected from a web extraction service.
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 consists of two efficient sentences with zero redundancy. It front-loads the core action ('Extract clean, structured content') and immediately follows with outputs and optimization purpose. Every word contributes to understanding.
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 10 parameters and no output schema, the description adequately covers return value types (Markdown, article data, metadata, etc.) and the custom structured fields capability. It appropriately delegates parameter details to the comprehensive schema while providing high-level use case context.
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?
While the input schema has 100% description coverage, the description adds crucial semantic context by framing the tool for 'LLM feeding,' which helps agents understand the intent behind parameters like cleanOutput, blockAds, maxLength, and the custom fields object. It explains the 'why' behind the extraction modes.
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 extracts 'clean, structured content from a URL' and specifically lists output formats (Markdown, article data via Mozilla Readability, OG metadata, etc.). The phrase 'without HTML noise' effectively distinguishes it from the sibling 'scrape' tool, while 'feeding web content to LLMs' differentiates it from 'screenshot'.
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 provides clear usage context by specifying it is 'Optimized for feeding web content to LLMs,' indicating when to use this tool. However, it does not explicitly state when NOT to use it or name specific sibling alternatives (e.g., 'use screenshot for visual captures').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your SnapAPI account usage, quota, and plan details for the current billing period. Shows requests used vs. limit, remaining quota, and monthly statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return content ('requests used vs. limit, remaining quota, and monthly statistics') but omits auth requirements, rate limits, caching behavior, or whether this counts against quota itself.
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?
Two sentences with zero waste: first establishes action and scope, second details specific return values. Front-loaded with the verb and appropriately sized.
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?
Adequate for a 0-parameter utility. Describes return values effectively (compensating for missing output schema), but lacks mention of authentication prerequisites or billing period calculation boundaries.
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?
Zero parameters present; baseline 4 per scoring rules. Schema is empty object with no properties requiring semantic elaboration.
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?
Specific verb 'Check' + resource 'SnapAPI account usage, quota, and plan details' + scope 'current billing period'. Clearly distinguishes from siblings (analyze, extract, screenshot, etc.) which are content/media processing tools rather than account metadata.
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?
No explicit when-to-use guidance, prerequisites, or alternatives mentioned. While the purpose is distinct from siblings, the description provides no contextual guidance on when to query usage versus performing other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available device presets for screenshot and video emulation. Each preset sets the correct viewport, device scale factor, and mobile flag (phones, tablets, desktops). Pass the device id to the screenshot or video tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses what each preset contains (viewport, device scale factor, mobile flag) and categorizes the devices (phones, tablets, desktops), but omits safety traits, rate limits, or caching behavior typical of read operations.
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?
Three sentences with zero waste: purpose statement, content explanation, and usage instruction. Information density is high with no redundancy.
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?
For a zero-parameter discovery tool without output schema, the description adequately explains the return concept (presets with IDs) and their relationship to consumer tools (screenshot, video). Covers necessary context for agent selection.
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?
Zero parameters present; baseline score applies per rubric. The description appropriately requires no additional parameter explanation given the empty input schema.
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?
Clear verb 'List' with specific resource 'device presets'. The scope is well-defined ('for screenshot and video emulation') and distinguishes from siblings like analyze or pdf by explicitly mentioning the screenshot/video domain.
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?
Explicitly states the output intent: 'Pass the device id to the screenshot or video tool.' This establishes the workflow (use before screenshot/video) and links to specific sibling tools, though it lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a PDF from a URL or HTML content. Supports page sizes, margins, landscape orientation, background graphics, and custom scaling.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The URL to convert to PDF. Required unless html is provided. | |
| html | No | Raw HTML to convert to PDF. Alternative to url. | |
| pdfOptions | No | PDF layout and formatting options. | |
| width | No | Viewport width in pixels (default: 1280). | |
| height | No | Viewport height in pixels (default: 800). | |
| delay | No | Milliseconds to wait after page load before generating PDF. | |
| waitUntil | No | When to consider the page ready (default: load). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists capabilities (page sizes, margins, scaling) hinting at the rendering engine complexity, but omits critical behavioral details: viewport emulation, dynamic content handling (delay/waitUntil parameters), error cases for invalid URLs, or output binary handling.
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?
Two compact sentences with zero waste. Front-loaded with the core action ('Generate a PDF'), followed by a feature summary. Every word earns its place.
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?
Covers primary PDF layout concerns but ignores the web-rendering nuances critical to this tool's function: viewport dimensions, network idle waiting, and delay mechanisms are absent despite being significant parameters for successful conversion.
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%, establishing baseline 3. The description maps features to the pdfOptions object ('page sizes', 'margins', 'landscape') and input modes, but does not add syntax clarification beyond the schema's existing documentation.
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?
Clear verb ('Generate') and resource ('PDF') with explicit input sources ('URL or HTML content'). However, it does not differentiate from sibling 'screenshot' or 'scrape' tools, leaving ambiguity about when to prefer PDF generation over image capture.
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?
Lacks explicit guidance on when to use this tool versus siblings like 'screenshot' or 'scrape'. The schema describes the url/html mutual exclusivity ('At least one...must be provided'), but the description gives no contextual 'when-to-use' advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that the SnapAPI service is reachable and the API key is valid. Returns the API status and current server time. Use this to verify your configuration before making other calls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Successfully mentions return values ('Returns the API status and current server time') and validation purpose. Could enhance by explicitly stating idempotency or safety for repeated calls, but covers core behavioral traits well for a simple health check.
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?
Three tightly constructed sentences: purpose, return values, and usage guidance. Front-loaded with action verb 'Check'. Zero redundancy or waste.
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?
Complete for a zero-parameter health check tool. Addresses purpose, returns, and usage context without requiring output schema elaboration. Sufficient complexity coverage given simple schema and lack of annotations.
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?
Zero parameters present, establishing baseline of 4. Description appropriately makes no parameter claims since schema confirms no inputs required.
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?
Specific verb 'Check' with clear resources (SnapAPI service, API key) and scope (reachability, validity). Distinguishes from operational siblings (analyze, extract, etc.) by positioning as a configuration verification tool rather than a data processing operation.
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?
Explicit when-to-use guidance: 'Use this to verify your configuration before making other calls.' Provides clear temporal context for invocation. Does not explicitly name alternative tools or 'when-not-to-use' exclusions, hence not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape a URL using a real browser and return page content as plain text (Markdown), raw HTML, or a list of links. Works on JavaScript-rendered pages.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to scrape. | |
| type | No | Return format: 'text' for Markdown-converted content, 'html' for raw HTML, 'links' for extracted hyperlinks (default: text). | |
| pages | No | Number of pages to follow and scrape, 1–10 (default: 1). | |
| waitMs | No | Extra wait time in ms after page load (0–30000, default: 0). | |
| blockResources | No | Block images, media, and fonts to speed up scraping (default: false). | |
| locale | No | Browser locale, e.g. en-US, de-DE (default: system). | |
| premiumProxy | No | Route through a residential proxy to bypass bot detection (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It successfully notes the browser-based execution and JavaScript support, but omits critical behavioral details: it doesn't explain the multi-page crawling capability (1-10 pages), anti-bot implications of premiumProxy, or performance characteristics like typical latency.
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?
Extremely efficient two-sentence structure. First sentence delivers the complete core value proposition (action + mechanism + outputs); second sentence adds the JavaScript capability differentiator. Zero redundancy, front-loaded with essential information.
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 (browser automation, pagination, proxy support) and lack of output schema, the description is minimally adequate. It covers the basic scraping contract but fails to contextualize advanced features like multi-page crawling or bot detection bypass, which are significant capabilities implied by the parameter schema.
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 coverage is 100%, establishing a baseline of 3. The description mentions output formats (aligning with the 'type' enum) but adds no semantic context for complex parameters like 'pages' (pagination behavior), 'blockResources' (performance impact), or 'premiumProxy' (use case) beyond what the schema already provides.
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 core action (scrape URL), mechanism (real browser), and output formats (Markdown text, raw HTML, links). It implies distinction from simple HTTP fetch tools via 'real browser' and 'JavaScript-rendered pages,' though it doesn't explicitly differentiate from siblings like 'extract' or 'screenshot.'
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?
Provides implicit guidance by noting it 'Works on JavaScript-rendered pages,' signaling use for dynamic content. However, it lacks explicit when-to-use guidance regarding the pagination feature ('pages' parameter) or when to prefer 'text' vs 'html' vs 'links' outputs, and doesn't mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of a URL or render HTML/Markdown and return the image. Supports full-page capture, device emulation, dark mode, element selection, custom CSS/JS injection, ad/cookie-banner blocking, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The URL to screenshot. Required unless html or markdown is provided. | |
| html | No | Raw HTML to render and screenshot. Alternative to url. | |
| markdown | No | Markdown to render and screenshot. Alternative to url. | |
| format | No | Output image format (default: png). | |
| quality | No | Image quality 1–100 for jpeg/webp (default: 80). | |
| width | No | Viewport width in pixels (default: 1280). | |
| height | No | Viewport height in pixels (default: 800). | |
| fullPage | No | Capture the full scrollable page (default: false). | |
| selector | No | CSS selector to capture a specific element. | |
| delay | No | Milliseconds to wait after page load before capture (0–30000). | |
| waitUntil | No | When to consider the page ready (default: load). Use networkidle for SPAs. | |
| darkMode | No | Render with dark color scheme (default: false). | |
| blockAds | No | Block ad networks (default: false). | |
| blockCookieBanners | No | Block cookie consent popups (default: false). | |
| css | No | Custom CSS to inject before capture. | |
| javascript | No | Custom JavaScript to execute before capture. | |
| device | No | Device preset (e.g. iphone-15-pro, macbook-pro-16, pixel-8). Overrides width, height, scale, and mobile settings. Use the list_devices tool to see all presets. | |
| hideSelectors | No | CSS selectors of elements to hide before capture. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses specific behavioral capabilities (ad/cookie-banner blocking, CSS/JS injection, device emulation, dark mode). However, it omits operational context like error handling, timeout behavior, or whether the tool makes external network requests.
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?
Two sentences efficiently structured: the first establishes core function and I/O, the second enumerates key capabilities. Every phrase earns its place; 'and more' is acceptable given the 18-parameter complexity without being overly verbose.
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 18 parameters, no annotations, and no output schema, the description adequately covers the essentials (input sources, output type, key features) but lacks detail on error scenarios, return value structure, or pagination. The 100% schema coverage compensates for parameter details, but behavioral gaps remain.
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%, establishing a baseline of 3. The description maps capabilities to parameters (e.g., 'full-page capture' to fullPage, 'device emulation' to device) but does not add semantic context beyond what the schema already provides regarding formats, ranges, or validation rules.
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 explicitly states the core action ('Take a screenshot') and resources ('URL', 'HTML/Markdown') with clear output ('return the image'). It effectively distinguishes from siblings like 'pdf', 'video', and 'scrape' by specifying image generation rather than document extraction or video production.
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 clarifies input alternatives (URL vs HTML vs Markdown) implying when to use each, but lacks explicit guidance on choosing this tool over siblings like 'scrape' (data extraction) or 'pdf' (document generation). No 'when-not-to-use' or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a browser session as a video (WebM). Optionally runs a JavaScript scenario (clicks, scrolls, form fills) before and during recording. Returns a URL to download the recorded video.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to record. | |
| width | No | Viewport width in pixels (default: 1280). | |
| height | No | Viewport height in pixels (default: 800). | |
| duration | No | Recording duration in seconds (1–60, default: 5). | |
| scenario | No | JavaScript to run inside the page during recording, e.g. scroll or click actions. | |
| waitUntil | No | When to start recording (default: load). | |
| delay | No | Milliseconds to wait after page load before starting the recording. | |
| darkMode | No | Record with dark color scheme (default: false). | |
| blockAds | No | Block ad networks during recording (default: false). | |
| blockCookieBanners | No | Block cookie consent popups (default: false). | |
| device | No | Device preset for recording (e.g. iphone-15-pro). Use the list_devices tool to see all presets. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Adds valuable context that JavaScript runs 'before and during' recording and that return is a URL. Missing: URL expiration/temporariness, headless vs visible browser, error handling for invalid JavaScript, or resource limits.
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?
Two sentences, zero fluff. Front-loaded with core action (Record) and format (WebM). Second sentence covers optional complexity (JS scenario) and return value. Every word earns its place.
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?
Adequate for an 11-parameter video tool with 100% schema coverage. Description compensates for missing output schema by stating return format (URL). Could strengthen with URL persistence details or error behavior, but functional coverage is complete.
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 coverage is 100%, establishing baseline 3. Description Adds significant value for complex 'scenario' parameter: elaborates timing ('before and during' vs schema's 'during'), and expands examples ('form fills' not in schema). Justifies elevation above baseline.
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?
Excellent specificity: 'Record a browser session as a video (WebM)' provides exact verb, resource, and format. Clearly distinguishes from sibling 'screenshot' (static image) and 'pdf' (document capture) through the motion/recording aspect.
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?
Implies use case through 'Optionally runs a JavaScript scenario' (dynamic interactions), but lacks explicit when-to-use vs alternatives (e.g., 'use screenshot for static pages, video for motion') or prerequisites. No mention of when NOT to use.
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.
v3.1.0analyzeextractget_usagelist_devicespdfpingscrapescreenshotvideoScored across 9 tools
Most tools are clearly distinct by output type (image, PDF, video, usage, devices), but scrape and extract overlap significantly—both return Markdown, plain text, and links from a URL. Descriptions help differentiate raw scraping from structured extraction, but an agent could still be uncertain which to choose.
Names are all lowercase and readable, but conventions are mixed: some are verb+object (get_usage, list_devices), some are bare verbs (scrape, extract, analyze, ping), and some are noun-like action commands (pdf, video, screenshot). There is no consistent verb_noun pattern, though the naming is still predictable enough to navigate.
Nine tools is a well-scoped set for a browser automation and web content API. Each tool covers a distinct core capability or supporting function, with no obvious bloat or redundancy that would make the surface feel heavy.
The tool surface covers the advertised SnapAPI capabilities thoroughly: scraping, structured extraction, screenshots, PDFs, video recording, AI analysis, device presets, usage checks, and connectivity verification. There are no obvious dead ends or missing core operations for this stateless, action-oriented API.
Screenshots, PDFs and Markdown from any URL or HTML for AI agents, via the SnapForge API
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, diff, audit and sitemap-capture any web page — 5 MCP tools for AI agents.
