The Scrappey MCP Server provides browser-backed web automation and data extraction, enabling AI models to interact with websites, bypass bot-protection systems, and perform complex browser actions.
Session Management
Create persistent browser sessions maintaining cookies and localStorage
Destroy, list, and check status of active sessions
HTTP Requests
Send browser-backed GET, POST, PUT, DELETE, and PATCH requests
Automatically handle JavaScript challenge pages from Cloudflare, Datadome, Kasada, PerimeterX, Akamai, and Incapsula
Use custom headers, cookies, and proxy configurations
Intercept/block network requests and unwanted domains
Extract content via CSS selectors
Browser Automation
Click, type, hover, scroll, navigate, and press keyboard keys
Wait for selectors, load states, functions, or cookies
Execute arbitrary JavaScript
Select dropdowns, switch iframes, set viewport size
Use conditional (if) and loop (while) action flows
Simulate human-like mouse movements
Captcha & Challenge Solving
Automatically solve Cloudflare Turnstile, reCAPTCHA (v2/v3), hCaptcha, FunCaptcha/Arkose Labs, PerimeterX, MTCaptcha, and custom image captchas
Enable per-request bypass modes (e.g., cloudflareBypass, datadomeBypass, kasadaBypass)
Screenshots & Media
Take full-page or viewport screenshots
Record browser sessions as video
Generate PDFs of pages
Proxy Support
Use custom HTTP proxies, premium residential proxies, mobile carrier proxies, or country-specific proxies
Data Extraction & Customization
Extract inner text, links, and image URLs
Set custom user agents, headers, cookies, and browser locales
Automatically remove cookie banners and iframes
Track redirects and configure retry logic and timeouts
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Scrappey MCP Server create a session and scrape product prices from amazon.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.
A Model Context Protocol (MCP) server for interacting with Scrappey.com's browser-backed web automation and data-extraction capabilities. Try it out directly at smithery.ai/server/@pim97/mcp-server-scrappey.
This MCP server provides a bridge between AI models and Scrappey's web automation platform, allowing you to:
Create and manage browser sessions
Send HTTP requests through Scrappey's browser-backed infrastructure
Execute browser actions (clicking, typing, scrolling, etc.)
Render pages that rely on JavaScript challenge pages from common bot-management systems (Cloudflare, Datadome, Kasada, etc.)
Complete interactive challenge widgets when a page requires them (Turnstile, reCAPTCHA, hCaptcha, etc.)
Take screenshots and record videos
Intercept network requests
This server is intended for legitimate development use — application and integration testing, monitoring your own services, and collecting data you are authorized to access. See Responsible Use.
Related MCP server: MCP Operator
npm install
npm run buildGet your Scrappey API key from Scrappey.com
Set up your environment variable:
SCRAPPEY_API_KEY=your_api_key_hereAdd to your claude_desktop_config.json:
{
"mcpServers": {
"scrappey": {
"command": "node",
"args": ["path/to/dist/scrappey-mcp.js"],
"env": {
"SCRAPPEY_API_KEY": "your_api_key_here"
}
}
}
}Cursor supports MCP servers through its settings. Configure it in one of these ways:
Option 1: Via Cursor Settings UI
Open Cursor Settings (Ctrl+, or Cmd+,)
Search for "MCP" or "Model Context Protocol"
Add a new MCP server with:
Name: scrappey
Command: node
Args: ["C:\\Users\\pim_d\\Desktop\\scrappey.com\\mcp-smith\\mcp-server-scrappey\\dist\\scrappey-mcp.js"]
Environment Variables: Add SCRAPPEY_API_KEY with your API key
Option 2: Via Settings JSON
Open Cursor Settings (Ctrl+Shift+P or Cmd+Shift+P)
Type "Preferences: Open User Settings (JSON)"
Add the MCP server configuration:
{
"mcp.servers": {
"scrappey": {
"command": "node",
"args": ["C:\\Users\\pim_d\\Desktop\\scrappey.com\\mcp-smith\\mcp-server-scrappey\\dist\\scrappey-mcp.js"],
"env": {
"SCRAPPEY_API_KEY": "your_api_key_here"
}
}
}
}Note: Adjust the path to dist/scrappey-mcp.js based on where you installed the MCP server.
After configuration, restart Cursor to load the MCP server. You should see Scrappey tools available in the AI chat interface.
scrappey_create_session)Creates a new browser session that persists cookies and other state.
{
"proxy": "http://user:pass@ip:port",
"proxyCountry": "UnitedStates",
"premiumProxy": true,
"mobileProxy": false,
"browser": [{"name": "firefox", "minVersion": 120, "maxVersion": 130}],
"userAgent": "custom-user-agent"
}scrappey_destroy_session)Properly closes a browser session to free resources.
{
"session": "session_id_here"
}scrappey_list_sessions)List all active sessions for the current user.
{}Response:
{
"sessions": [{"session": "abc123", "lastAccessed": 1234567890}],
"open": 1,
"limit": 100
}scrappey_session_active)Check if a specific session is currently active.
{
"session": "session_id_here"
}scrappey_request)Send browser-backed HTTP requests, with automatic handling of JavaScript challenge pages.
{
"cmd": "request.get",
"url": "https://example.com",
"session": "session_id_here",
"postData": {"key": "value"},
"customHeaders": {"User-Agent": "custom-agent"},
"cookies": "session=abc123",
"proxyCountry": "Germany",
"premiumProxy": true,
"cloudflareBypass": true,
"datadomeBypass": true,
"automaticallySolveCaptchas": true,
"alwaysLoad": ["recaptcha", "hcaptcha"],
"screenshot": true,
"cssSelector": ".product-title",
"innerText": true,
"includeLinks": true,
"includeImages": true,
"interceptFetchRequest": "https://api.example.com/data",
"abortOnDetection": ["analytics.com", "tracking.js"],
"whitelistedDomains": ["example.com"],
"blockCookieBanners": true
}scrappey_browser_action)Execute browser automation actions.
{
"session": "session_id_here",
"url": "https://example.com",
"cmd": "request.get",
"browserActions": [
{"type": "wait_for_selector", "cssSelector": "#login-form"},
{"type": "type", "cssSelector": "#username", "text": "myuser"},
{"type": "type", "cssSelector": "#password", "text": "mypassword"},
{"type": "solve_captcha", "captcha": "turnstile"},
{"type": "click", "cssSelector": "#submit", "waitForSelector": ".dashboard"},
{"type": "execute_js", "code": "document.querySelector('.user-data').innerText"}
],
"mouseMovements": true
}Action | Description |
| Click on an element |
| Type text into an input field |
| Navigate to a URL |
| Wait for specified milliseconds |
| Wait for an element to appear |
| Wait for JavaScript condition to be true |
| Wait for page load state (domcontentloaded, networkidle, load) |
| Wait for a cookie to be set |
| Execute JavaScript code |
| Scroll to element or page bottom |
| Hover over an element |
| Press keyboard keys (enter, tab, etc.) |
| Select option from dropdown |
| Switch to an iframe |
| Change browser viewport size |
| Conditional action execution |
| Loop actions while condition is true |
| Solve various captcha types |
| Remove all iframes from page |
turnstile - Cloudflare Turnstile
recaptcha / recaptchav2 / recaptchav3 - Google reCAPTCHA
hcaptcha / hcaptcha_inside / hcaptcha_enterprise_inside - hCaptcha
funcaptcha - FunCaptcha/Arkose Labs
perimeterx - PerimeterX
mtcaptcha - MTCaptcha
custom - Custom image captcha
scrappey_screenshot)Take a screenshot of a webpage.
{
"url": "https://example.com",
"session": "optional_session_id",
"screenshotWidth": 1920,
"screenshotHeight": 1080,
"fullPage": true,
"browserActions": [
{"type": "wait", "wait": 2000}
],
"premiumProxy": true
}Many sites serve JavaScript challenge pages before returning content. Scrappey renders these in a real browser so your automated requests receive the final page. The server is compatible with challenge pages from common bot-management systems:
Cloudflare - Bot Management, Turnstile, Challenge pages
Datadome
PerimeterX
Kasada
Akamai - Bot Manager
Incapsula - Imperva
Enable handling for a specific system per request:
{
"cloudflareBypass": true,
"datadomeBypass": true,
"kasadaBypass": true
}The option keys above (
cloudflareBypass, etc.) are Scrappey API field names and are kept as-is for compatibility.
{
"proxy": "http://user:pass@ip:port",
"proxyCountry": "UnitedStates",
"premiumProxy": true,
"mobileProxy": true,
"noProxy": false
}Supported Countries: UnitedStates, UnitedKingdom, Germany, France, and many more.
The server provides detailed error information:
Code | Description |
CODE-0001 | Server capacity full, try again |
CODE-0002 | Cloudflare blocked |
CODE-0007 | Turnstile/Proxy error |
CODE-0010 | Datadome proxy blocked |
CODE-0024 | Proxy timeout |
CODE-0029 | Too many sessions open |
CODE-0032 | Turnstile captcha failed |
Create a session:
{"name": "scrappey_create_session"}Navigate and interact:
{
"name": "scrappey_browser_action",
"session": "returned_session_id",
"url": "https://example.com/login",
"cmd": "request.get",
"browserActions": [
{"type": "type", "cssSelector": "#username", "text": "myuser"},
{"type": "type", "cssSelector": "#password", "text": "mypass"},
{"type": "click", "cssSelector": "#login-btn", "waitForSelector": ".dashboard"}
]
}Extract data:
{
"name": "scrappey_request",
"cmd": "request.get",
"url": "https://example.com/data",
"session": "returned_session_id",
"cssSelector": ".product-list"
}Clean up:
{
"name": "scrappey_destroy_session",
"session": "returned_session_id"
}Reuse sessions for related requests to maintain state
Destroy sessions when done to free resources
Use premium proxies for more reliable connections
Enable automatic challenge handling for sites that serve challenge pages
Use appropriate wait times between actions so pages have time to load
Monitor session limits to avoid hitting limits
This server is a development tool for browser-based automation and data extraction. Use it only for lawful, authorized purposes, such as:
Testing and monitoring applications and integrations you own or operate
Collecting data you are permitted to access
When accessing third-party sites, follow each site's terms of service, robots directives, and rate limits, respect personal data and copyright, and comply with all applicable laws. You are responsible for how you use this server and your Scrappey account.
# Build
npm run build
# Deploy via Smithery CLI
npx @anthropic/smithery-cli deploydocker build -t scrappey-mcp .
docker run -e SCRAPPEY_API_KEY=your_key scrappey-mcpMIT License
Execute browser automation actions in a session. Supports clicking, typing, scrolling, waiting, JavaScript execution, captcha solving, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | Session ID to use | |
| url | Yes | URL to navigate to before actions | |
| cmd | Yes | HTTP method for initial navigation | |
| browserActions | Yes | Array of browser actions to execute sequentially | |
| proxy | No | Proxy in format http://user:pass@ip:port. Leave blank to use built-in proxy. | |
| proxyCountry | No | Request proxy from specific country (e.g., 'UnitedStates', 'Germany', 'UnitedKingdom') | |
| premiumProxy | No | Use premium residential-like proxies for better success rates | |
| mobileProxy | No | Use mobile carrier proxies | |
| noProxy | No | Disable proxy usage entirely | |
| cloudflareBypass | No | Enable Cloudflare-specific bypass | |
| datadomeBypass | No | Enable Datadome bypass using specialized solver | |
| kasadaBypass | No | Enable Kasada bypass | |
| disableAntiBot | No | Disable automatic antibot detection | |
| automaticallySolveCaptchas | No | Automatically detect and solve captchas on the page | |
| alwaysLoad | No | Always load specific captcha types: 'recaptcha', 'hcaptcha', 'turnstile' | |
| cssSelector | No | Extract content matching this CSS selector | |
| innerText | No | Include inner text of page elements | |
| includeImages | No | Include all image URLs in the response | |
| includeLinks | No | Include all link URLs in the response | |
| screenshot | No | Capture page screenshot | |
| screenshotWidth | No | Screenshot width in pixels | |
| screenshotHeight | No | Screenshot height in pixels | |
| filter | No | Return only specified fields: 'response', 'cookies', 'statusCode', 'innerText', etc. | |
| video | No | Record browser session as video | |
| No | Generate PDF of the page | ||
| interceptFetchRequest | No | URL pattern to intercept and return response data | |
| abortOnDetection | No | URL patterns to block (e.g., analytics, tracking scripts) | |
| whitelistedDomains | No | Only allow requests to these domains | |
| blackListedDomains | No | Block requests to these domains | |
| blockCookieBanners | No | Automatically block cookie consent banners | |
| mouseMovements | No | Enable human-like mouse movements | |
| forceMouseMovement | No | Force mouse movement simulation |
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 mentions supported actions but lacks critical behavioral details: it doesn't specify error handling (e.g., what happens if an action fails), performance characteristics (e.g., timeouts, rate limits), authentication needs, or side effects (e.g., whether actions are reversible). The list of actions is informative but insufficient for a tool with 32 parameters and complex automation capabilities.
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 is extremely concise and front-loaded: a single sentence that states the core purpose and enumerates key actions. Every word earns its place by conveying essential information without redundancy or fluff, making it efficient for quick comprehension.
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 high complexity (32 parameters, no annotations, no output schema), the description is inadequate. It lacks information on output format, error responses, session dependencies, and behavioral constraints. For a powerful automation tool with many configuration options, the description should provide more context about how actions are executed, what results to expect, and common pitfalls.
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%, so the schema already documents all 32 parameters thoroughly. The description adds minimal value beyond the schema by listing action types (e.g., 'clicking, typing, scrolling') but doesn't explain parameter interactions, defaults, or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
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's purpose: 'Execute browser automation actions in a session' with a list of supported actions (clicking, typing, etc.). It specifies the verb ('execute') and resource ('browser automation actions'), but doesn't explicitly differentiate from sibling tools like scrappey_request or scrappey_screenshot, which might 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.
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. It doesn't mention prerequisites (e.g., needing a session from scrappey_create_session), exclusions, or comparisons to sibling tools like scrappey_request (for simpler requests) or scrappey_screenshot (for just screenshots). Usage is implied by the action list but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new browser session in Scrappey. Sessions persist browser state (cookies, localStorage) across requests.
| Name | Required | Description | Default |
|---|---|---|---|
| proxy | No | Proxy in format http://user:pass@ip:port. Leave blank to use built-in proxy. | |
| proxyCountry | No | Request proxy from specific country (e.g., 'UnitedStates', 'Germany', 'UnitedKingdom') | |
| premiumProxy | No | Use premium residential-like proxies for better success rates | |
| mobileProxy | No | Use mobile carrier proxies | |
| noProxy | No | Disable proxy usage entirely | |
| browser | No | Browser specification: [{"name": "firefox", "minVersion": 120, "maxVersion": 130}] | |
| userAgent | No | Custom user agent string | |
| locales | No | Browser locale settings (e.g., ['en-US', 'en']) |
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 mentions that sessions 'persist browser state across requests,' which hints at statefulness, but doesn't cover critical aspects like authentication needs, rate limits, error handling, or what happens on failure. For a creation tool with zero annotation coverage, this is insufficient.
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 is two sentences, front-loaded with the core purpose and followed by a clarifying detail about session persistence. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly efficient and easy to parse.
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 complexity of creating a browser session with multiple configuration options (8 parameters) and no annotations or output schema, the description is incomplete. It lacks information on return values, error conditions, or how the session integrates with other tools, leaving significant gaps for the agent to operate effectively.
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%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3. It doesn't compensate for any gaps because there are none in the 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?
The description clearly states the specific action ('Create a new browser session') and resource ('in Scrappey'), with additional context about what sessions persist ('browser state like cookies, localStorage across requests'). It distinguishes from siblings like 'scrappey_destroy_session' and 'scrappey_list_sessions' by focusing on creation rather than management or listing.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when to choose this over other session-related tools, or any specific scenarios where creating a session is necessary versus using direct requests. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Destroy an existing browser session in Scrappey to free resources
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | Session ID to destroy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool destroys a session to free resources, indicating a destructive action, but doesn't mention behavioral traits like whether destruction is irreversible, what happens to associated data, error conditions, or rate limits. For a destructive tool with zero annotation coverage, this leaves significant gaps in understanding the operation's impact.
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 is a single, efficient sentence that directly states the tool's purpose and benefit ('to free resources'). It is front-loaded with the core action and avoids unnecessary details, making it highly concise and well-structured for quick 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 the tool's complexity (destructive action with one parameter) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but doesn't address return values, error handling, or resource implications. For a destructive tool, more context on outcomes or safety would improve completeness, but it meets a baseline level.
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%, with the single parameter 'session' documented as 'Session ID to destroy.' The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately defines the parameter without extra description needed.
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 action ('Destroy') and resource ('existing browser session in Scrappey'), making the purpose unambiguous. It distinguishes from siblings like 'scrappey_create_session' and 'scrappey_list_sessions' by focusing on termination rather than creation or listing. However, it doesn't explicitly contrast with 'scrappey_session_active' which might check session status.
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 implies usage when needing to 'free resources,' suggesting it's for cleanup after session use. However, it doesn't specify when to use this tool versus alternatives (e.g., whether to destroy vs. keep sessions active for reuse) or provide explicit exclusions. The context is clear but lacks detailed guidance on timing or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active sessions for the current user
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states it lists active sessions but doesn't mention what 'active' means, whether it's read-only or has side effects, or any rate limits or authentication requirements. This leaves significant gaps for an agent to understand the tool's behavior.
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 is a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action without redundancy or fluff.
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 has 0 parameters and no output schema, the description is minimally adequate by stating what it does. However, with no annotations and sibling tools present, it lacks details on behavior, usage context, and output format, making it incomplete for optimal agent understanding.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and a baseline of 4 is applied since it doesn't add unnecessary information beyond what the schema 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 action ('List all') and target resource ('active sessions for the current user'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'scrappey_session_active' which might serve a similar purpose, preventing a perfect score.
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 no guidance on when to use this tool versus alternatives like 'scrappey_session_active' or 'scrappey_destroy_session'. It lacks context about prerequisites, such as whether authentication is required, or any explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an HTTP request using Scrappey with antibot bypass capabilities. Supports GET, POST, PUT, DELETE, PATCH methods.
| Name | Required | Description | Default |
|---|---|---|---|
| cmd | Yes | HTTP method to use | |
| url | Yes | Target URL to request | |
| session | No | Session ID for session persistence | |
| postData | No | Data to send with POST/PUT/PATCH requests | |
| proxy | No | Proxy in format http://user:pass@ip:port. Leave blank to use built-in proxy. | |
| proxyCountry | No | Request proxy from specific country (e.g., 'UnitedStates', 'Germany', 'UnitedKingdom') | |
| premiumProxy | No | Use premium residential-like proxies for better success rates | |
| mobileProxy | No | Use mobile carrier proxies | |
| noProxy | No | Disable proxy usage entirely | |
| cloudflareBypass | No | Enable Cloudflare-specific bypass | |
| datadomeBypass | No | Enable Datadome bypass using specialized solver | |
| kasadaBypass | No | Enable Kasada bypass | |
| disableAntiBot | No | Disable automatic antibot detection | |
| automaticallySolveCaptchas | No | Automatically detect and solve captchas on the page | |
| alwaysLoad | No | Always load specific captcha types: 'recaptcha', 'hcaptcha', 'turnstile' | |
| cssSelector | No | Extract content matching this CSS selector | |
| innerText | No | Include inner text of page elements | |
| includeImages | No | Include all image URLs in the response | |
| includeLinks | No | Include all link URLs in the response | |
| screenshot | No | Capture page screenshot | |
| screenshotWidth | No | Screenshot width in pixels | |
| screenshotHeight | No | Screenshot height in pixels | |
| filter | No | Return only specified fields: 'response', 'cookies', 'statusCode', 'innerText', etc. | |
| video | No | Record browser session as video | |
| No | Generate PDF of the page | ||
| interceptFetchRequest | No | URL pattern to intercept and return response data | |
| abortOnDetection | No | URL patterns to block (e.g., analytics, tracking scripts) | |
| whitelistedDomains | No | Only allow requests to these domains | |
| blackListedDomains | No | Block requests to these domains | |
| blockCookieBanners | No | Automatically block cookie consent banners | |
| customHeaders | No | Custom HTTP headers to send | |
| cookies | No | Cookie string to set | |
| cookiejar | No | Cookie jar array format | |
| localStorage | No | LocalStorage data to set | |
| referer | No | HTTP Referer header value | |
| userAgent | No | Custom user agent string | |
| timeout | No | Request timeout in milliseconds | |
| retries | No | Number of retry attempts on failure | |
| fullPageLoad | No | Wait for full page load | |
| listAllRedirects | No | Track and return all redirect URLs | |
| removeIframes | No | Remove all iframes from page |
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. While it mentions 'antibot bypass capabilities,' it fails to describe critical behavioral traits: whether this is a read-only or destructive operation, authentication requirements, rate limits, error handling, or what the response format looks like. For a complex tool with 41 parameters, this is a significant gap in transparency.
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 is extremely concise and front-loaded: a single sentence that captures the core functionality. Every word earns its place with no redundancy or unnecessary elaboration. This is an excellent example of efficient communication for a tool with extensive schema documentation.
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 high complexity (41 parameters, no output schema, no annotations), the description is insufficiently complete. It doesn't address what the tool returns, error conditions, performance characteristics, or how it integrates with sibling tools. While the schema covers parameters well, the description fails to provide the broader context needed for effective tool selection and invocation.
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%, so the schema already documents all 41 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain parameter relationships, default behaviors, or practical examples. The baseline score of 3 reflects adequate coverage through the schema alone, with no extra value from the description.
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's purpose: 'Send an HTTP request using Scrappey with antibot bypass capabilities. Supports GET, POST, PUT, DELETE, PATCH methods.' This specifies the verb ('Send an HTTP request'), resource ('using Scrappey'), and key capability ('antibot bypass'). However, it doesn't explicitly differentiate from sibling tools like 'scrappey_browser_action' or 'scrappey_create_session', which likely have overlapping web interaction functionality.
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 no guidance on when to use this tool versus alternatives. It mentions 'antibot bypass capabilities' but doesn't explain when this is needed compared to simpler HTTP requests or other sibling tools. There are no usage prerequisites, exclusions, or named alternatives provided, leaving the agent with minimal contextual direction.
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 webpage. Optionally execute browser actions before capturing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to screenshot | |
| session | No | Optional session ID to use | |
| screenshotWidth | No | Screenshot width in pixels (default: 1920) | |
| screenshotHeight | No | Screenshot height in pixels (default: 1080) | |
| fullPage | No | Capture full page instead of viewport | |
| browserActions | No | Optional actions to execute before screenshot | |
| proxy | No | Proxy in format http://user:pass@ip:port. Leave blank to use built-in proxy. | |
| proxyCountry | No | Request proxy from specific country (e.g., 'UnitedStates', 'Germany', 'UnitedKingdom') | |
| premiumProxy | No | Use premium residential-like proxies for better success rates | |
| mobileProxy | No | Use mobile carrier proxies | |
| noProxy | No | Disable proxy usage entirely | |
| cloudflareBypass | No | Enable Cloudflare-specific bypass | |
| datadomeBypass | No | Enable Datadome bypass using specialized solver | |
| kasadaBypass | No | Enable Kasada bypass | |
| disableAntiBot | No | Disable automatic antibot detection |
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 optional browser actions capability but doesn't describe important behaviors: whether this is a read-only operation (likely, but not stated), what happens with sessions, rate limits, authentication needs, error handling, or what the output looks like (image format, size). The description is minimal for a tool with 15 parameters and complex functionality.
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 is perfectly concise with two sentences that each add value. First sentence states core functionality, second adds the key optional capability. No wasted words, front-loaded with the main purpose.
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 complex tool with 15 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (image data format? file? URL?), doesn't mention performance characteristics, error conditions, or practical constraints. The agent would need to infer too much from the parameter schema alone.
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%, so the schema already documents all 15 parameters thoroughly. The description adds no parameter-specific information beyond implying that 'browserActions' can be used before capturing. It doesn't explain parameter relationships, default behaviors, or practical usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: 'Take a screenshot of a webpage' (specific verb+resource). It adds 'Optionally execute browser actions before capturing' which distinguishes it from basic screenshot tools, though it doesn't explicitly differentiate from sibling tools like 'scrappey_browser_action' which might handle browser actions separately.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'scrappey_browser_action' (for actions without screenshot), 'scrappey_request' (for non-browser requests), or 'scrappey_create_session' (for session management). There's no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a specific session is currently active
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | Session ID to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks session activity but doesn't describe what 'active' means (e.g., browser session status, timeout behavior), response format (e.g., boolean, status details), error handling, or any rate limits. This leaves significant gaps for a tool that likely interacts with session management.
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 is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple check operation, making it easy for an agent to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'active' entails, the return value (e.g., true/false, status object), or error cases (e.g., invalid session ID). For a session management tool with no structured output, more context is needed to guide the agent effectively.
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?
The description doesn't add any parameter semantics beyond what the input schema provides. The schema has 100% description coverage, clearly documenting the single required 'session' parameter as a session ID to check. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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's purpose as checking if a specific session is active, using the verb 'check' and specifying the resource 'session'. It distinguishes from siblings like 'scrappey_list_sessions' (which lists sessions) and 'scrappey_destroy_session' (which destroys sessions), but doesn't explicitly differentiate from all siblings like 'scrappey_browser_action' or 'scrappey_request'.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid session ID), exclusions, or relationships with sibling tools like 'scrappey_list_sessions' (which might be used to get session IDs first). Usage context is implied but not explicit.
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.
v2.0.0scrappey_browser_actionscrappey_create_sessionscrappey_destroy_sessionscrappey_list_sessionsscrappey_requestscrappey_screenshotscrappey_session_activeScored across 7 tools
Each tool has a clearly distinct purpose with no ambiguity. scrappey_browser_action handles automation interactions, scrappey_request manages HTTP requests, scrappey_screenshot captures visual content, and the session tools (create, destroy, list, active) each manage specific session lifecycle aspects without overlap.
All tools follow a perfect 'scrappey_verb_noun' pattern with consistent snake_case throughout. The naming convention is predictable and uniform across all seven tools, making them easily identifiable as part of the same server.
Seven tools is well-scoped for a browser automation and web scraping server. Each tool earns its place by covering distinct aspects: session management, browser automation, HTTP requests, and screenshot capabilities without being overwhelming or insufficient.
The toolset provides complete coverage for browser automation and web scraping workflows. It includes full session lifecycle management (create, destroy, list, check), core automation actions, HTTP requests with antibot bypass, and screenshot functionality, leaving no obvious gaps for the domain.
Zenrows MCP server — Fetch, Extract, Batch, and Browser Sessions for AI coding assistants
Undetectable cloud browser sessions for AI agents and scrapers. Navigate, extract, click, captcha.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
