Provides Baidu search results via the Scrapingdog API, with support for Chinese-language restriction and pagination.
Provides DuckDuckGo search results via the Scrapingdog API, with options for region, date filtering, and pagination.
Provides Google search results via the Scrapingdog API, including organic results, ads, knowledge graph, and SERP features, with support for JSON or HTML output.
Click on "Install 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., "@scrapingdog-mcp Scrape the Hacker News homepage and summarize the top stories."
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 server that exposes the Scrapingdog scraping APIs as tools for MCP-compatible clients (Claude Desktop, Claude Code, and others).
Communicates over stdio. Built with TypeScript and the official MCP SDK.
Nine tools, each wrapping one Scrapingdog endpoint:
Tool | Endpoint | What it returns |
|
| Raw HTML of any URL (JS rendering, premium proxies, geotargeting, sessions, stealth, wait) |
|
| Page screenshot metadata (png/jpg/webp, full-page, viewport, quality) |
|
| Google organic results, ads, knowledge graph, SERP features (JSON or HTML) |
|
| Bing search results (market/geo/pagination/safe-search) |
|
| DuckDuckGo results (region, date filter, pagination token) |
|
| Baidu results (Chinese-language restriction, pagination) |
|
| X (Twitter) profile data (name, handle, follower counts, bio) |
|
| X (Twitter) post (tweet) data |
| (forward proxy) | Connection details + ready-to-paste curl/Python for |
Every tool accepts an optional api_key argument to override the configured key for that call.
Related MCP server: spider-cloud-mcp
Node.js ≥ 18.17 (tested on 20.x).
A Scrapingdog API key — get one from your Scrapingdog dashboard after signing up.
npm install
npm run build # outputs to dist/The key is resolved in this order (first wins):
The api_key argument on an individual tool call.
The SCRAPINGDOG_API_KEY environment variable.
A .env file containing SCRAPINGDOG_API_KEY=... in the working directory,
~/.scrapingdog.env, or ~/.env.
Option 2 (env var) is recommended — the key never touches disk beyond your MCP client config, and nothing ends up in tool-call logs.
claude_desktop_config.json){
"mcpServers": {
"scrapingdog": {
"command": "node",
"args": ["/absolute/path/to/scrcpy/dist/index.js"],
"env": {
"SCRAPINGDOG_API_KEY": "your-key-here"
}
}
}
}Published as @0pen1/scrapingdog-mcp. Run directly with npx (no install):
npx @0pen1/scrapingdog-mcpThe server reads SCRAPINGDOG_API_KEY from the environment. Pick your CLI below for a one-line setup.
claude mcp add scrapingdog --scope user \
--env SCRAPINGDOG_API_KEY=your-key-here \
-- npx -y @0pen1/scrapingdog-mcp--scope user makes it available in all your projects (use local or project to scope it tighter).
codex mcp add scrapingdog \
--env SCRAPINGDOG_API_KEY=your-key-here \
-- npx -y @0pen1/scrapingdog-mcpThis writes to ~/.codex/config.toml. The equivalent TOML block is:
[mcp_servers.scrapingdog]
command = "npx"
args = ["-y", "@0pen1/scrapingdog-mcp"]
[mcp_servers.scrapingdog.env]
SCRAPINGDOG_API_KEY = "your-key-here"gemini mcp add scrapingdog \
--env SCRAPINGDOG_API_KEY=your-key-here \
-- npx -y @0pen1/scrapingdog-mcpFor clients that use a JSON config file, add this block. Typical locations:
Claude Desktop — ~/Library/Application Support/Claude/claude_desktop_config.json (macOS)
Cursor — ~/.cursor/mcp.json (or .cursor/mcp.json per-project)
Windsurf — ~/.codeium/windsurf/mcp_config.json
{
"mcpServers": {
"scrapingdog": {
"command": "npx",
"args": ["-y", "@0pen1/scrapingdog-mcp"],
"env": { "SCRAPINGDOG_API_KEY": "your-key-here" }
}
}
}Replace
your-key-herewith your Scrapingdog API key from the dashboard. After editing a JSON config, restart the client so it picks up the server.
SCRAPINGDOG_API_KEY=your-key node dist/index.jsIt speaks JSON-RPC over stdio, so you can pipe messages to it directly.
scrape { "url": "https://example.com", "dynamic": true, "country": "us" }
google_search { "query": "best espresso machines 2026", "results": "10", "country": "us" }
bing_search { "query": "site:github.com mcp server", "count": "20" }
duckduckgo_search { "query": "rust async runtime", "df": "m" }
baidu_search { "query": "人工智能", "ct": 2 }
x_profile { "profileId": "elonmusk" }
x_post { "tweetId": "1655608985058267139" }
screenshot { "url": "https://example.com", "fullPage": true, "format": "png" }
datacenter_proxy { "target_url": "https://httpbin.org/ip" }JSON endpoints (search, social, etc.): the parsed JSON is returned as text so the host can reason about it directly.
/scrape: raw HTML is returned as text.
/screenshot: the endpoint returns binary image bytes, which can't be carried as
text cleanly. The tool reports the content type and byte length, and notes how to fetch
the image directly. (If you need true image delivery, extend the handler to base64-encode
into an image content block.)
Non-2xx responses: returned as MCP error results (isError: true) with the upstream
status, content type, and body. Note Scrapingdog reports invalid keys as HTTP 400 with a
JSON "Unauthorized request" message — the body makes this clear.
Scrape: 1 (rotating proxy) → 25 (JS render + premium). Google/Bing/DDG/Baidu search: ~5. Screenshot: 5. Profile/Post scrapers: 5–10. See the pricing/credit table for the full breakdown. Requests time out after 60s upstream.
src/
index.ts # entry point — creates McpServer, connects stdio transport
scrapingdog.ts # API key resolution + shared HTTP request helper
result.ts # response → MCP tool-result formatting (ok / error / fromResponse)
tools.ts # the 9 tool definitions (schema + handler) and registrationMIT
Run a Baidu search via Scrapingdog (/baidu/search). Returns parsed results as JSON. Supports Chinese-language restriction (ct), pagination (pn), and result count (rn).
| Name | Required | Description | Default |
|---|---|---|---|
| ct | No | Language restriction: 1 = all, 2 = Simplified Chinese, 3 = Traditional Chinese. | |
| pn | No | Result offset for pagination. 0 = first page, 10 = second, 20 = third, etc. | |
| rn | No | Maximum number of results to return. | |
| html | No | Return the full raw HTML of the Baidu results page. | |
| query | Yes | The Baidu search query. Supports inurl:, site:, intitle: operators. | |
| api_key | No | Override the configured Scrapingdog API key for this call. If omitted, the key is read from SCRAPINGDOG_API_KEY or a local .env file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It does disclose that calls go through Scrapingdog and that results are returned as parsed JSON, and it highlights key options. However, it omits authentication requirements, rate-limit or cost implications, and behavior when the 'html' parameter is true.
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 concise sentences that front-load the core action and return format, then list the important supported options. There is no fluff or repetition, and 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?
For a simple search tool with a fully documented input schema, the description is mostly adequate. However, because there is no output schema and no annotations, it only vaguely promises 'parsed results as JSON' without describing the structure of those results or error behavior, making it complete enough but not thorough.
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 already documents all six parameters with 100% coverage, so the baseline is 3. The description adds little beyond restating that ct handles Chinese-language restriction, pn handles pagination, and rn handles result count—details already present 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 opens with a specific verb 'Run' and clearly identifies both the tool ('a Baidu search') and the implementation endpoint ('via Scrapingdog (/baidu/search)'). It also states the return type ('parsed results as JSON') and the tool's name distinguishes it from sibling search engines like google_search and bing_search.
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 the tool is for Baidu searches, but it does not explicitly contrast it with sibling tools such as google_search, bing_search, or duckduckgo_search. It provides no alternative recommendation, exclusion criteria, or conditions for when Baidu should be used over other engines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Bing search via Scrapingdog (/bing/search). Returns parsed Bing results as JSON. Supports market/country targeting, geo coordinates, pagination, and safe-search filters.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | Two-letter ISO country code, e.g. 'us', 'de', 'gb'. | |
| lat | No | GPS latitude for the search starting point. | |
| lon | No | GPS longitude for the search starting point. | |
| mkt | No | Market as <language>-<country>, e.g. 'en-US'. Mutually exclusive with cc. | |
| count | No | Results per page, 1–50 (actual may vary). | |
| first | No | Starting position of organic results. Default: 1. first=10 puts the 10th result first. | |
| query | Yes | The Bing search query. Supports NOT, OR, site:, filetype:, near:, etc. | |
| api_key | No | Override the configured Scrapingdog API key for this call. If omitted, the key is read from SCRAPINGDOG_API_KEY or a local .env file. | |
| filters | No | Advanced filter string copied from a Bing search URL. | |
| safeSearch | No | Adult-content filter level. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but only discloses that it returns parsed JSON and uses Scrapingdog. It does not mention auth requirements (e.g., requiring an API key), rate limits, error behavior, or that parameters like count may vary. This is adequate but lacks rich behavioral context.
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, front-loaded with the action, and no waste. It effectively covers the tool's purpose, key capabilities, and return type in a compact form.
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 is reasonably complete by summarizing the tool's scope. However, it does not detail the exact structure of the JSON response or mention operational aspects like API key handling, which the schema partially covers via the api_key parameter. It could be more precise about pagination semantics, but the schema descriptions fill most gaps.
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% with detailed parameter descriptions, so the baseline is 3. The description adds a concise summary of features (market/country, geo, pagination, safe-search) that maps to existing parameters but does not introduce new meaning beyond 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 tool runs a Bing search via Scrapingdog, returning parsed JSON results. This distinguishes it from sibling search tools (google_search, duckduckgo_search, baidu_search) with a specific verb and resource.
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?
It provides context on supported capabilities (market/country targeting, geo, pagination, safe-search) but does not explicitly say when to use Bing over alternatives or when not to use it. No exclusions or alternative naming, but the purpose is clear enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Scrapingdog Datacenter Proxy connection details (host, port, username, password) and a ready-to-paste curl/Python example. This is a forward proxy (proxy.scrapingdog.com:8081), not an HTTP API — point your own HTTP client at it. Optionally pass target_url for a ready-to-run curl.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Override the configured Scrapingdog API key for this call. If omitted, the key is read from SCRAPINGDOG_API_KEY or a local .env file. | |
| target_url | No | Optional target URL to test the proxy against. If provided, a ready-to-use curl command is returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool doesn't make requests itself ('point your own HTTP client'), reveals the proxy endpoint, and mentions the output includes examples. It doesn't discuss auth or rate limits, but for a simple info-return tool this is sufficient.
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, front-loaded with the core function, then the proxy context, then optional behavior. No filler, 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?
For a simple tool with two optional parameters and no output schema, the description gives purpose, output type, proxy nature, and optional parameter behavior. It lacks an explicit return structure but that is not essential for 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?
The input schema fully documents both parameters (100% coverage). The description adds some value by explaining target_url yields a ready-to-run curl, but does not mention api_key override. Baseline 3 applies since the schema already conveys parameter meaning.
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 returns Scrapingdog Datacenter Proxy connection details (host, port, username, password) and ready-to-paste examples, with a specific proxy address. It explicitly contrasts with an HTTP API, distinguishing it from sibling scraping tools.
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?
It explains this is a forward proxy, not an HTTP API, which implies when to use it (to get proxy connection info) vs sibling tools (for direct scraping). It also notes the optional target_url behavior for a ready-to-run curl, but doesn't explicitly name alternatives or state 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.
Run a DuckDuckGo search via Scrapingdog (/duckduckgo/search). Returns parsed results as JSON. Supports region (kl), date filters (df), and pagination via next_page_token (15 per page).
| Name | Required | Description | Default |
|---|---|---|---|
| df | No | Date filter: d (past day), w (week), m (month), y (year), or from_date..to_date. | |
| kl | No | Region, e.g. 'us-en', 'uk-en', 'fr-fr'. | |
| html | No | Return the full raw HTML of the DuckDuckGo results page. | |
| query | Yes | The DuckDuckGo search query. Supports inurl:, site:, intitle: operators. | |
| api_key | No | Override the configured Scrapingdog API key for this call. If omitted, the key is read from SCRAPINGDOG_API_KEY or a local .env file. | |
| next_page_token | No | Token from a previous response to fetch the next page (15 results per page). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure and does well by stating it returns parsed results as JSON, supports region/date filters, and has pagination with 15 results per page. It also mentions the Scrapingdog endpoint, adding context beyond the schema. It does not cover failure modes or rate limits, but provides solid behavioral context.
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 only two sentences yet packs all essential information: what it does, the output format, and supported features. It is front-loaded and every word adds value with no redundant phrasing.
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?
The description is largely complete for a search tool, covering input capabilities and output format. However, there is no output schema, so the exact structure of the parsed results is not specified (e.g., whether it returns a list of results with title, URL, snippet). It also does not mention error handling or API key requirements beyond what the schema implies. Still, the core use case is well covered.
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 each parameter is already well-documented. The description adds minimal extra meaning beyond repeating kl, df, and next_page_token, though it does add the pagination page size (15 per page) not present in the schema. This does not significantly improve semantic understanding beyond 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 tool performs a DuckDuckGo search via Scrapingdog, with a specific endpoint and output format. It distinguishes itself from sibling search tools by explicitly naming DuckDuckGo and mentioning key capabilities like region, date filtering, and pagination.
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 for DuckDuckGo searches but does not explicitly contrast with alternatives such as google_search, bing_search, or baidu_search. It lacks clear when-to-use / when-not-to-use guidance or any mention of alternatives, leaving the agent to infer based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Google search via Scrapingdog (/google). Returns organic results, ads, knowledge graph, and other SERP features as JSON (or raw HTML with html=true). Supports localization, pagination, advanced filters, and mobile results. Costs 5–10 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| tbs | No | Advanced filter string (time ranges, verbatim mode) copied from Google's URL. | |
| html | No | Return the full raw HTML of the Google results page. | |
| page | No | Page number: 0 = first page, 1 = second, etc. Default: 0. | |
| safe | No | Filter adult content: 'active' to filter, 'off' to disable. Default: off. | |
| uule | No | Encoded geographic locale for tailored results. Cannot be combined with location. | |
| query | Yes | The Google search query. Supports operators like site:, inurl:, intitle:. | |
| domain | No | Google domain for localized results, e.g. google.co.in, google.co.uk. Default: google.com. | |
| api_key | No | Override the configured Scrapingdog API key for this call. If omitted, the key is read from SCRAPINGDOG_API_KEY or a local .env file. | |
| country | No | Two-letter country code, e.g. 'us', 'uk', 'fr'. Default: us. | |
| results | No | Number of results per page. | |
| language | No | Result language code, e.g. 'en', 'es', 'fr'. Default: en. | |
| location | No | Origin location (city-level recommended). Cannot be used with uule. | |
| mob_search | No | Return mobile search results. true costs 10 credits. | |
| advance_search | No | Get advanced feature snippets. true costs 10 credits, otherwise 5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output format (JSON or raw HTML via html=true), mentions the credit cost (5–10 credits), and notes the underlying provider (Scrapingdog). These are meaningful behavioral traits beyond the schema. It does not explicitly state read-only status, but that is inherent in a search tool.
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 three sentences, each adding distinct value: purpose, output, and key capabilities/cost. It is front-loaded with the primary verb and resource, and contains no redundant filler.
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 (14 params, no output schema, no annotations), the description provides essential context: return format, features, credit cost, and provider. It lacks explicit information about rate limits, error handling, or dependency on external API availability, but it is sufficient for a typical search tool.
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 detailed descriptions for all 14 parameters. The description adds minimal extra semantics, only referencing html=true and mobile results which are already in the schema. The credit cost mention is useful but not tied to parameter names.
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 runs a Google search via Scrapingdog (/google), specifying the exact resource and action. It further enumerates the output types (organic results, ads, knowledge graph) and distinguishes it from sibling search engines like bing_search or duckduckgo_search.
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 for Google-specific search needs by naming the search engine directly. It also highlights capabilities (localization, pagination, advanced filters, mobile) that inform when to use this tool. However, it lacks explicit exclusions or comparisons to alternatives, such as 'use bing_search for Bing results.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape any URL via the Scrapingdog Web Scraping API (/scrape). Returns the page's HTML. Supports JS rendering (dynamic), premium residential proxies, geotargeting (country), sessions, stealth/captcha bypass, and a render wait. Costs 1–25 credits depending on options.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the page to scrape. | |
| wait | No | Milliseconds to wait after JS rendering before capturing HTML (0–35000). Use with dynamic=true. | |
| image | No | Scrape image URLs found on the page. | |
| api_key | No | Override the configured Scrapingdog API key for this call. If omitted, the key is read from SCRAPINGDOG_API_KEY or a local .env file. | |
| country | No | ISO country code for geotargeting (e.g. 'us', 'gb', 'in'). Sends the request from that location. Costs 10 credits. | |
| dynamic | No | Enable JavaScript rendering with a headless browser. Costs 5 credits (25 with premium proxy). | |
| premium | No | Use premium residential proxies instead of the rotating datacenter proxy. Costs 10 credits (25 with JS rendering). | |
| stealth_mode | No | Enable stealth mode to bypass bot detection / captchas. | |
| custom_headers | No | Set to true to forward your own request headers (passed via the headers parameter). | |
| session_number | No | Reuse the same proxy/IP across multiple requests by passing a stable session string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses the return type (HTML), core capabilities, and credit costs, which is useful behavioral context. However, it omits potential failure modes, rate limits, or whether the operation has side effects on the target site, leaving some gaps.
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 concise, with the core purpose in the first sentence and capability/cost summary in the second. It is front-loaded and every sentence contributes, though the second sentence is a bit of a list and could be more structured.
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 complex tool with 10 parameters and no output schema, the description adequately states the primary output (HTML), key features, and credit costs. It does not explain error handling or response structure beyond HTML, but the rich schema covers parameter details, making this reasonably 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 description coverage is 100%, so the schema already documents every parameter's meaning, including credit costs for country and dynamic. The description provides only a high-level summary of supported features, adding no meaningful details beyond what the schema already offers. Baseline 3 is appropriate.
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 it scrapes any URL via the Scrapingdog API and returns the page's HTML, using the specific verb 'Scrape' and resource. It inherently distinguishes itself from sibling tools like screenshot (captures images) and search tools (return search results).
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 general-purpose scraping for any URL and lists key capabilities (JS rendering, proxies, geotargeting) that indicate when to use specific options, but it does not explicitly contrast with sibling tools or state when not to use this tool. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of a URL via the Scrapingdog Screenshot API (/screenshot). Supports full-page capture, viewport size, wait-until, format (png/jpg/webp), and quality. Costs 5 credits. Note: this tool reports image metadata; binary bytes aren't returned as text.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the page to screenshot. | |
| width | No | Browser viewport width in pixels (e.g. '1920'). | |
| format | No | Output image format. Default: png. | |
| height | No | Browser viewport height in pixels (e.g. '1080'). | |
| api_key | No | Override the configured Scrapingdog API key for this call. If omitted, the key is read from SCRAPINGDOG_API_KEY or a local .env file. | |
| quality | No | Image quality 0–100 (jpg/webp). Default: 80. | |
| fullPage | No | Capture the full scrollable page rather than just the visible viewport. | |
| wait_until | No | When navigation is considered complete before screenshotting. Default: domcontentloaded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful behavioral context: a 5-credit cost and a note that binary bytes aren't returned as text (only image metadata). However, it doesn't disclose error handling, rate limits, or the exact return structure, leaving gaps for an agent.
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 three concise sentences: purpose, cost, and a critical behavioral caveat. Every sentence earns its place, and the most important information (what the tool does) is front-loaded.
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?
This tool has 8 parameters and no output schema, yet the description only vaguely mentions 'reports image metadata'. It does not describe the returned data structure (e.g., base64, URL, JSON fields), error scenarios, or how to handle the result, leaving an agent under-informed for a complex tool.
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 already documents all 8 parameters with descriptions (100% coverage). The tool description only recaps some parameter capabilities in prose, adding minimal value beyond the schema, so baseline 3 is appropriate.
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 opens with 'Capture a screenshot of a URL via the Scrapingdog Screenshot API (/screenshot)', using a specific verb and resource. It lists supported features (full-page, viewport, wait-until, format, quality) which clearly distinguishes it from sibling tools like scrape or search.
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 explicit guidance on when to use this tool versus alternatives such as scrape or search. The use case is implied by the tool's name, but there are no stated context cues, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape an X (Twitter) post (tweet) via Scrapingdog (/x/post). Pass the numeric tweet ID from the post URL.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Override the configured Scrapingdog API key for this call. If omitted, the key is read from SCRAPINGDOG_API_KEY or a local .env file. | |
| tweetId | Yes | The tweet ID, found in the post URL (e.g. for .../status/1655608985058267139 the ID is 1655608985058267139). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It adds the endpoint path and that the ID comes from the post URL, but it does not describe the return format, error behavior, rate limits, or side effects. For a scraping tool, the read-only nature is implied but not explicit.
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 concise sentences, front-loads the primary purpose, and wastes no words. Every sentence contributes useful information for selecting and invoking the tool.
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?
The tool is simple with one required parameter and clear schema coverage, but there is no output schema and the description does not mention what the response contains. Since the tool's purpose is scraping, the agent can infer it returns post data, but error and output behavior are unspecified. The description 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both api_key and tweetId already well described in the input schema. The description's instruction to pass the numeric tweet ID merely echoes the schema example and adds no new parameter semantics 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 uses a specific verb ('Scrape') and resource ('X (Twitter) post (tweet)') and names the exact endpoint (/x/post). It clearly distinguishes from siblings like x_profile, which targets profiles, and generic scrape.
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 clearly indicates that the tool is for scraping a single post and instructs the user to pass the numeric tweet ID from the URL. It does not explicitly mention alternatives or exclusions, but the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape an X (Twitter) profile via Scrapingdog (/x/profile). Returns the profile's name, handle, follower counts, bio, and other public metadata as JSON. Pass a username or user ID.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Override the configured Scrapingdog API key for this call. If omitted, the key is read from SCRAPINGDOG_API_KEY or a local .env file. | |
| profileId | Yes | The user ID or username of the X profile to scrape, e.g. 'elonmusk' or 'nasa'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that it returns JSON with specific fields, but it does not mention the dependency on Scrapingdog API key, rate limits, caching behavior, or whether it performs a live scrape. These are significant omissions for an external scraping tool.
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 action and endpoint, and contains no filler. Every word contributes to understanding the tool's function.
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 simple read-only scrape with only two parameters, the description adequately covers purpose, input format, and return fields. However, it omits mention of API key requirements or error conditions, and with no output schema, it relies on the listed fields to convey the response shape. Still, it provides enough context for an agent to select and invoke the tool correctly in most cases.
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 baseline 3 applies. The description restates that the tool accepts a username or user ID, which is already in the schema's profileId description. It adds no new semantic detail 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 a specific verb 'Scrape' with a clear resource 'X (Twitter) profile' and even names the endpoint '/x/profile'. It distinguishes the tool from siblings like x_post and search tools by focusing on profile 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?
The description provides a parameter-level instruction ('Pass a username or user ID') but gives no explicit guidance on when to use this tool versus alternatives. The use case is implied by the resource, but no exclusions or comparisons with sibling tools are offered.
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.
v0.1.1baidu_searchbing_searchdatacenter_proxyduckduckgo_searchgoogle_searchscrapescreenshotx_postx_profileScored across 9 tools
Each tool targets a distinct resource or action: raw HTML scraping, screenshots, four search engines, X profile/post, and proxy details. The search tools are differentiated by the named engine, and the X tools by profile vs post, leaving no ambiguous overlaps.
Tool names use a mix of verb forms and noun compounds, such as scrape, screenshot, google_search, x_profile, and datacenter_proxy. While the snake_case style is consistent, there is no uniform verb_noun pattern, making the naming somewhat mixed.
With 9 tools covering scraping, screenshots, search, social media, and proxy access, the count is well within the ideal 3-15 range and each tool earns its place.
The set covers core Scrapingdog features (scrape, screenshot, search engines, X data, proxy) with only minor gaps such as missing X search or timeline and other less-used Scrapingdog endpoints. Agents can work around these gaps by using the scrape tool.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
All HasData scraping tools in one MCP server: Google, TikTok, Instagram, maps, e-commerce and more.
Scrapingdog MCP — wraps Scrapingdog (scrapingdog.com), a proxy-based web
One MCP server for 180+ live web-data APIs returning clean JSON from sites that block scrapers.
Official SerpApi MCP server for Google, Bing, and other search engines.
