MrScraper MCP Server
OfficialProvides Google web search through the webSearch tool, accepting Google queries or Google search URLs and returning search results.
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., "@MrScraper MCP Serverscrape mrscraper.com/pricing and return it as markdown"
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.
MrScraper MCP Server for Web Scraping and Google Search
MrScraper MCP is the official MrScraper server for the
Model Context Protocol. It connects AI
assistants to page content and Google search through two SDK-compatible tools,
plus an account check. Retrieve HTML, Markdown, or screenshots with
scraperAPI, discover pages with webSearch, and check your plan and token
usage with status.
Use the hosted server with OAuth sign-in, or run the open-source server locally
with the @mrscraper/mcp npm package.
See the MrScraper MCP documentation
for setup instructions and client configurations.
The server exposes three tools:
scraperAPI webSearch statusDeployment options
Option | Endpoint or command | Best for |
Hosted |
| A managed Streamable HTTP connection |
Local HTTP |
| A self-managed HTTP service |
Local stdio |
| MCP clients that launch a local process |
The hosted server signs you in through your browser with OAuth 2.1, so there is no key to copy. Self-hosted and stdio setups use a MrScraper API key from app.mrscraper.com/api-tokens, which the hosted server also still accepts.
Related MCP server: byob
Connect to the hosted server
Point your MCP client at https://mcp.mrscraper.com/mcp with no credential.
The server answers with an OAuth challenge, your client opens a browser, and
you approve the connection on app.mrscraper.com.
claude mcp add --transport http --scope user \
mrscraper https://mcp.mrscraper.com/mcpFor clients configured by file, omit the headers block entirely:
{
"mcpServers": {
"mrscraper": {
"type": "http",
"url": "https://mcp.mrscraper.com/mcp"
}
}
}Use exactly this URL, including the /mcp path. It is the resource identifier
access tokens are issued for, and a token minted for a different spelling of
the address will be refused.
What you are approving
Scope | Grants |
|
|
|
|
|
|
A tool called without its scope is refused with 403 insufficient_scope, and
your client will offer to grant the missing permission.
scraperAPI submits a scraping job to the backend with POST /, which requires
scrape:write. Connections authorized before this scope was advertised need to
authorize again and grant it; scrape:read alone does not grant write access.
Disconnect it later under Connected applications in your MrScraper account. Disconnecting revokes the refresh tokens immediately; an access token already issued stops working within the hour.
Connect with an API key instead
An API key still works as a bearer token, which is what self-hosted deployments and non-OAuth clients use:
{
"mcpServers": {
"mrscraper": {
"type": "http",
"url": "https://mcp.mrscraper.com/mcp",
"headers": {
"Authorization": "Bearer YOUR_MRSCRAPER_API_KEY"
}
}
}
}Use your client's environment-variable or secret-storage feature so the key stays out of project files. An API key carries your full account authority, so no scope is enforced against it.
Codex
export MRSCRAPER_API_KEY="YOUR_MRSCRAPER_API_KEY"
codex mcp add mrscraper \
--url https://mcp.mrscraper.com/mcp \
--bearer-token-env-var MRSCRAPER_API_KEYStart Codex from an environment containing MRSCRAPER_API_KEY. Codex stores
the environment-variable name in its MCP configuration.
Claude Code
claude mcp add \
--transport http \
--scope user \
--header "Authorization: Bearer YOUR_MRSCRAPER_API_KEY" \
mrscraper https://mcp.mrscraper.com/mcpClaude Code also supports project and local scopes. Choose the scope that matches how broadly the connection should be available.
Copyable agent setup prompt
Connect MrScraper MCP to this agent. Detect the current MCP client and configure a Streamable HTTP server named mrscraper at https://mcp.mrscraper.com/mcp with no credential. The server uses OAuth 2.1, so the client will open a browser to sign in. If the client cannot do OAuth, fall back to a MrScraper API key from https://app.mrscraper.com/api-tokens stored through the client's environment-variable or secret-storage mechanism and sent as Authorization: Bearer <key>. Reload the MCP client when required, then list the tools and confirm that scraperAPI, webSearch, and status are the only available tools.Choosing a tool
Tool | Choose it when |
| You have a page URL and need HTML, Markdown, a screenshot, or a combination. |
| You have a Google query or Google search URL and need search results. |
| You need the account's plan, token usage, or remaining tokens. |
A discovery workflow is webSearch → scraperAPI. Both web tools advertise
readOnlyHint: true, openWorldHint: true, and destructiveHint: false;
status is read-only and not open-world. Authentication comes from the MCP
connection; no tool takes an API token argument.
Migration from the previous tool set
Only scraperAPI, webSearch, and status are registered. The other old tool
names are removed.
Previous call | Replacement |
|
|
|
|
|
|
| Removed from this MCP server. |
super_mode becomes super. home_page now maps to warmStart, and
token_cap=0 is accepted. Restart the server and reconnect the MCP client after
updating so it refreshes tools/list.
Tool reference
The options and defaults of scraperAPI and webSearch follow the Python SDK's
scraper_api and web_search methods. MCP tool names use camel case; their
argument names use the SDK's snake case.
scraperAPI
POST https://api.mrscraper.com/Start with a known URL:
{
"url": "https://www.scrapethissite.com/pages/simple/"
}Request HTML, Markdown, and a screenshot together:
{
"url": "https://example.com",
"html": true,
"markdown": true,
"screenshot": true,
"super": true,
"home_page": true,
"geo_code": "ID",
"timeout": 120
}Omit browser_rendering or use null to let the service try without a browser
and fall back to browser loading. true forces browser loading and false
disables it. A screenshot always forces browser loading, even when
browser_rendering=false. super selects real-device routing independently.
The JSON body contains url, maxRetries, and optional tokenCap. Page
options are query parameters. For API keys, the request also includes the
SDK-compatible token query parameter and Authorization/x-api-token
headers. OAuth JWTs are sent only through Authorization.
Input | Default | API mapping / purpose |
| required | Body |
|
| Query |
|
| Query |
|
| Query |
|
| Query |
| omitted | Query |
| omitted | Query |
|
| Query |
|
| Query |
| omitted | Query |
| omitted | Query |
|
| Query |
|
| Query |
|
| Query |
|
| Query |
| omitted | Query |
| omitted | Query |
|
| Body |
| omitted | Body |
| omitted | Query |
|
| Optional |
webSearch
POST https://sync.scraper.mrscraper.com/api/google/serp/v2/syncRequest parsed Google results:
{
"url": "MrScraper web scraping",
"raw": false,
"region": "id",
"language": "id",
"page": 1,
"format": "json"
}raw=true is the Python SDK-compatible default and requests HTML regardless
of format. Set raw=false and format="json" for parsed results.
A Google search URL supplies the query, locale, and page:
{
"url": "https://www.google.com/search?q=web+scraping&gl=us&hl=en&start=20",
"raw": false
}This derives query="web scraping", region="us", language="en", and
page=3. Explicit options override URL-derived values.
Input | Default | Request mapping / purpose |
| required | Search text or Google URL; normalized to body |
|
| Forces body |
|
| Body |
| URL value or omitted | Body |
| URL value or omitted | Body |
| URL value or omitted | Body |
|
| Body |
|
| Local HTTP deadline in seconds; omitted from the body. |
status
GET https://api.app.mrscraper.com/api/v1/subscription-accountsstatus takes no input. It returns the connected account's identity (name,
email, and verification state), subscription status, token limit, token usage,
remaining tokens, usage percentage, rate limit, auto-renewal, and renewal date.
It copies only those fields, so the API key and Stripe identifiers in the raw
account record never reach the client.
{
"kind": "mrscraper-cli-status-summary",
"source_endpoints": ["/subscription-accounts"],
"status_code": 200,
"data": {
"account": {
"subscription_status": "active",
"enterprise": false,
"token_usage": 61240,
"token_limit": 100000,
"token_remaining": 38760,
"usage_percent": 61.24,
"rate_limit": 0,
"rate_ttl": 0,
"auto_renew": true,
"ends_at": "2026-12-01T00:00:00.000Z",
"user": {
"name": "Ada",
"email": "ada@example.com",
"verified": true
}
}
}
}An OAuth connection needs the account:read scope for status.
Response envelope
scraperAPI and webSearch return status_code, data, and headers in
structuredContent and as JSON text. JSON bodies are parsed; other response
bodies remain text. status returns the summary shown above.
A scraperAPI response carries the requested representations in data;
screenshot is a base64-encoded JPEG and x-status-code is the target page's
status:
{
"status_code": 200,
"data": {
"html": "<!DOCTYPE html>...",
"markdown": null,
"screenshot": null,
"token_usage": 3,
"runtime": 18.02,
"retry_count": 0,
"error": null
},
"headers": {
"content-type": "application/json",
"x-status-code": "200",
"token_usage": "3"
}
}A parsed webSearch response (raw=false) has organic results in
data.data.organic.
Failures include error and set MCP isError=true. Network failures have
status_code=null. Credential-bearing response headers and JSON metadata
are filtered; network errors redact signed query credentials.
Manual testing: one tool at a time
scripts/test-tools.ts starts the compiled local MCP
server over stdio, verifies that exactly the three tools are exposed, calls one
tool, prints its response, and exits. No separate server terminal is needed.
The runner loads .env, or reads MRSCRAPER_API_KEY / MRSCRAPER_API_TOKEN
from your shell. Each tool call uses the live MrScraper service.
Run these commands individually from the repository directory:
Install dependencies:
npm ciBuild the current server:
npm run buildSet your API key:
export MRSCRAPER_API_KEY="YOUR_MRSCRAPER_API_KEY"Test
scraperAPI:npm run test:manual -- scraperAPI --url "https://www.scrapethissite.com/pages/simple/"Test
webSearch:npm run test:manual -- webSearch --query "MrScraper web scraping"Test
status:npm run test:manual -- status
The webSearch sample explicitly requests raw=false, format="json", US
results, and English. Each command prints Tools: scraperAPI, webSearch, status
and PASS <tool> on success. Exit codes are 0 for success, 1 for a tool or
connection failure, and 2 for invalid command arguments.
Pass a complete JSON object to test any supported options:
npm run test:manual -- scraperAPI --args '{"url":"https://example.com","markdown":true,"screenshot":true,"super":true}'npm run test:manual -- webSearch --args '{"url":"web scraping","raw":false,"region":"id","language":"id","page":1,"render_js":true}'To test an already running HTTP MCP server, append
--target http://127.0.0.1:8000/mcp. Rebuild after source changes when testing
local stdio. npm run test:manual -- --help lists runner options.
Run the server locally
Node.js 20 or newer is required.
git clone https://github.com/mrscraper-com/mrscraper-mcp.git
cd mrscraper-mcp
npm ci
npm run buildStreamable HTTP
TRANSPORT=http npm startThe default endpoint is http://127.0.0.1:8000/mcp.
{
"mcpServers": {
"mrscraper": {
"type": "http",
"url": "http://127.0.0.1:8000/mcp",
"headers": {
"Authorization": "Bearer YOUR_MRSCRAPER_API_KEY"
}
}
}
}stdio
{
"mcpServers": {
"mrscraper": {
"command": "npx",
"args": ["-y", "@mrscraper/mcp@latest"],
"env": {
"MRSCRAPER_API_KEY": "YOUR_MRSCRAPER_API_KEY"
}
}
}
}Stdio credential precedence is MRSCRAPER_API_KEY, then
MRSCRAPER_API_TOKEN.
Authentication and security
Transport | Credential |
Hosted or local HTTP | An OAuth 2.1 access token, or a MrScraper API key, as |
Local stdio |
|
The HTTP transport is an OAuth 2.1 resource server. It publishes RFC 9728
protected resource metadata at /.well-known/oauth-protected-resource (and at
the /mcp path-suffixed variant), and an unauthenticated request is answered
with 401 and a WWW-Authenticate header naming that document, which is how a
client discovers where to send you to sign in.
Access tokens are verified locally against the authorization server's published
JWKS. A token must name this server in its aud claim, so a token issued for
another MrScraper surface cannot be replayed here.
API keys are validated against the MrScraper account endpoint before tool execution. Either way, each HTTP request uses its own caller's credential; server environment credentials are never used on the HTTP transport.
The server filters credential-bearing response headers. Parsed JSON credential
metadata and credentials embedded in generated curl commands are redacted.
Page content remains available in data.
Browser-origin requests are accepted from trusted local origins, from
claude.ai and chatgpt.com, and from exact origins configured through
MRSCRAPER_ALLOWED_ORIGINS. Service-to-service MCP clients typically connect
without an Origin header. The discovery documents are served ahead of origin
checks, since any client must be able to read them before it has credentials.
Interactive widgets
webSearch carries a self-contained Google results widget for parsed JSON
results. HTML responses show a prompt to request parsed results. status
carries an account widget with the plan, token usage, and a usage meter. Hosts
without MCP Apps support display the normal JSON tool response.
Each widget is a self-contained document with its script and styles inlined,
because strict host CSP blocks anything external. Each one declares an empty
network allowlist, since it only renders data the tool already returned. Sources live
in ui/; npm run build:widgets bundles them into
src/widgets/bundles.generated.ts, which npm run build does for you.
Docker
docker build -f docker/Dockerfile -t mrscraper-mcp .
docker run --rm -p 8000:8000 mrscraper-mcpThe image binds to 0.0.0.0. Apply the network controls appropriate for the
deployment and keep bearer authentication enabled.
Environment variables
Variable | Default | Purpose |
|
| Selects |
|
| HTTP bind address; the Docker image uses |
|
| HTTP listen port. |
| - | Primary stdio credential. |
| - | Alternative stdio credential (also used by the Python SDK). |
|
| Enables HTTP bearer verification. |
|
| Accepts OAuth 2.1 access tokens alongside API keys. |
|
| Public origin; |
|
| Authorization server issuer. |
|
| Key set used to verify access tokens. |
| - | Comma-separated browser origins allowed to call the HTTP server. |
| MrScraper platform API | Platform endpoint override for development and testing. |
| MrScraper Web Unblocker | Scraper API endpoint override. |
| MrScraper synchronous scraper API | Web search endpoint override. |
| off | Enables trusted-environment request-body diagnostics. |
|
| Maximum diagnostic payload length. |
Troubleshooting
Connection error: Confirm the server URL ends in
/mcpand reload the MCP client after configuration changes.401 Unauthorized: For OAuth, reconnect the server so your client runs the sign-in flow again. For an API key, confirm the bearer key for HTTP or the environment key for stdio.
403 insufficient_scope: The token lacks a scope the tool needs. Reconnect and approve the additional permission. For
scraperAPI, the token must includescrape:write; forwebSearch, it must includescrape:read.Signing in succeeds but tools fail: Confirm the server URL is exactly
https://mcp.mrscraper.com/mcp; the token audience is bound to it.403 Forbidden Origin: Add the exact browser origin to
MRSCRAPER_ALLOWED_ORIGINS.Tool input error: Compare the call with the tool's parameter table and the documented SDK-compatible defaults.
Upstream timeout: Increase
scraperAPI.timeout(up to 300 seconds) orwebSearch.timeoutwhen the target requires a longer request window.New tools are missing: Start a new client session and inspect
tools/listfor exactlyscraperAPIandwebSearch.
Development
npm ci
npm run format:check
npm run lint
npm test
npm run build
npm pack --dry-runSmoke-test a running HTTP server:
npm run test:mcp -- \
--target http://127.0.0.1:8000/mcp \
--token "$MRSCRAPER_API_KEY"npm run test:e2e runs both new tools sequentially against the live MrScraper
service using the manual runner. Use -- --url URL --query QUERY to customize
the targets, or -- --target http://127.0.0.1:8000/mcp to use HTTP.
MCP Registry
The hosted server's MCP Registry manifest is defined in
server.json. It describes the Streamable HTTP endpoint and
links to this repository and the setup documentation.
.github/workflows/publish-mcp-registry.yml
publishes server.json as io.github.mrscraper-com/mrscraper-mcp. Run it from
the Actions tab (Publish to MCP Registry → Run workflow) or push a
v* tag that matches the version in server.json. It authenticates with
GitHub OIDC, which grants this repository the io.github.mrscraper-com/*
namespace; an interactive mcp-publisher login github works only for
organization owners. The workflow fails if server.json and package.json
have different versions.
See the official registry publishing guide
for details. Registry versions are immutable, so use a new version in
server.json when publishing changed metadata. Publishing this manifest
registers the hosted server; it does not publish a new npm package.
License
MIT. See LICENSE.
Available Tools
3 toolsscraperAPIScraper APIARead-onlyInspect
Retrieves a known page through MrScraper's Scraper API as HTML, Markdown, a screenshot, or a combination. Matches the Python SDK's scraper_api options. Omit browser_rendering for automatic browser fallback; screenshot=true always enables it. super enables real-device routing independently. home_page maps to warmStart. Proxy, cookie, target-header, retry, and timeout options control page loading. Returns status_code, data, and sanitized headers.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Required absolute HTTP or HTTPS page URL. | |
| html | No | Request HTML page content. | |
| proxy | No | Custom proxy in username:password@host:port form. | |
| super | No | Use real-device routing independently of browser rendering. | |
| stream | No | Ask the API to stream; the MCP server buffers the response into the normal envelope. | |
| headers | No | Target page request headers as an object or JSON string. | |
| timeout | No | Page timeout in seconds (1–300); transport allows 30 additional seconds. | |
| geo_code | No | Proxy geolocation country code, such as US, ID, or SG. | US |
| markdown | No | Request Markdown page content. | |
| home_page | No | Visit the site's root before the target URL; sent as warmStart=true. | |
| token_cap | No | Optional nonnegative retry-token budget. | |
| use_proxy | No | Allow the service to use a configured proxy. | |
| cookie_jar | No | Cookie configuration string, such as domain=example.com&country=us&max_used=100&max_age=50m. | |
| screenshot | No | Capture a screenshot; always enables browser rendering. | |
| max_retries | No | Maximum Web Unblocker retries; 0 disables retries. | |
| bypass_proxy | No | Enable the API's proxy-bypass/resource-blocking behavior. | |
| proxy_country | No | Compatibility country option sent as proxyCountry. | |
| block_resources | No | Block images, CSS, and fonts during loading. | |
| browser_rendering | No | True forces browser rendering, false disables it; omit or use null for automatic fallback. | |
| wait_for_selector | No | CSS selector to wait for before returning page content. | |
| discard_token_secret | No | Optional value for the x-discard-token-secret upstream header. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Response body as parsed JSON or text. |
| error | No | Request failure message, if any. |
| headers | Yes | Response headers with credentials and cookies removed. |
| status_code | Yes | Upstream HTTP status, or null for a network failure. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful behavioral details beyond that: browser fallback rules, screenshot always enabling browser rendering, super operating independently, and proxy/cookie/header/retry/timeout options controlling loading. It stops short of covering auth or 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?
The description is front-loaded with purpose and then uses compact sentences for option interactions. It is appropriately sized for a 21-parameter tool, though the return-value sentence is somewhat redundant given the output schema.
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 retrieval tool with annotations and an output schema, the description covers the main purpose and cross-parameter behavior well. However, it does not clarify when to choose this over webSearch or status, leaving a usage gap that matters 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?
Schema description coverage is 100%, so the schema already documents all 21 parameters. The description echoes schema semantics such as home_page mapping to warmStart and screenshot enabling browser rendering, adding little syntax or format detail beyond what is already present. 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 states a specific verb and resource: retrieves a known page through MrScraper's Scraper API. 'Known page' implicitly distinguishes it from webSearch, but it never names the sibling or explicitly rules out search-style tasks, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'known page' implies use when the URL is already known, but there is no explicit when-to-use versus webSearch or status, no when-not guidance, and no prerequisites. Usage is only indirectly suggested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
statusAccount StatusARead-onlyInspect
Returns the connected MrScraper account's identity (name, email, and verification state), subscription status, token limit, token usage, remaining tokens, and rate limit. Use it to check the account and remaining quota, for example before a large batch of requests. It takes no input and reports account usage, not the progress of a request.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| kind | No | |
| error | No | |
| headers | No | |
| status_code | Yes | |
| source_endpoints | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful non-annotation context: it takes no input, and it reports account usage rather than request progress. It does not discuss auth/prerequisite requirements, which is a minor gap.
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 tight sentences, front-loaded with what is returned, followed by usage and scope clarification. The enumerated field list partially duplicates the output schema, but it is compact enough to earn its place as a quick orientation.
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?
An output schema exists, so return values need not be explained, yet the description still summarizes them alongside usage intent and input expectations. For a zero-parameter, read-only status tool with rich annotations, nothing an agent needs in order to call it correctly is missing.
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, so the baseline is 4. The description confirms 'It takes no input', which matches the empty input schema and removes any doubt about required arguments.
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?
States a specific verb (Returns) and resource (the connected MrScraper account's identity, subscription, token quota and rate limit), and enumerates the concrete data points returned. It also explicitly distinguishes itself from request-progress lookups, so an agent can tell what this tool is and is not.
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?
Gives a clear when-to-use signal: 'check the account and remaining quota, for example before a large batch of requests'. It clarifies the negative case ('not the progress of a request'). No alternative tool is named, but the siblings (scraperAPI, webSearch) are unrelated operations, so there is no meaningful alternative to route to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webSearchWeb SearchARead-onlyInspect
Searches Google from query text or a Google search URL passed as url. Matches the Python SDK's web_search options. Set raw=false and format=json for parsed results; the SDK-compatible default raw=true returns HTML. Google URLs supply q, gl, hl, and start; explicit region, language, and page override URL-derived values. render_js enables dynamic features; timeout controls the local request deadline. Returns status_code, data, and sanitized headers.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | SDK compatibility default: true requests HTML and overrides format. Set false for parsed JSON results. | |
| url | Yes | Required search query text or complete Google search URL. | |
| page | No | One-based result page; overrides the page derived from start in a Google URL. | |
| format | No | Response representation when raw=false. | json |
| region | No | Country code; overrides gl from a Google search URL. | |
| timeout | No | Local upstream HTTP deadline in seconds; omitted from the JSON body. | |
| language | No | Language code; overrides hl from a Google search URL. | |
| render_js | No | Render JavaScript-dependent search features. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Response body as parsed JSON or text. |
| error | No | Request failure message, if any. |
| headers | Yes | Response headers with credentials and cookies removed. |
| status_code | Yes | Upstream HTTP status, or null for a network failure. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds important behavior beyond the annotations: the SDK-compatible raw=true default returns HTML, URL parameters are derived and can be overridden, render_js enables dynamic features, and timeout is a local deadline.
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 purpose is front-loaded and the remaining sentences are dense but useful. The only minor redundancy is the return-value sentence, since an output schema exists, but it remains short and harmless.
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 annotations, full schema description coverage, and an output schema, the description covers the call-critical behavior an agent needs: query vs URL input, raw/format behavior, override rules, JavaScript rendering, and timeout. Nothing essential is missing.
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%, so the baseline is 3, but the description adds useful cross-parameter semantics: raw overrides format, Google URLs supply q/gl/hl/start, explicit region/language/page override URL-derived values, and timeout is excluded from the JSON body.
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 precise verb and resource: 'Searches Google from query text or a Google search URL passed as url.' That clearly separates it from scraperAPI and status without needing to name them.
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 gives operational guidance such as setting raw=false and format=json for parsed results, but it does not explicitly say when to use this tool versus scraperAPI or status, nor when not to use it. Usage is implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.2.2- First observed
scraperAPI - First observed
status - First observed
webSearch
TDQS
Scored across 3 tools
The three tools target distinct operations: scraping a known page, searching Google, and checking account status. There is mild overlap in that both scraperAPI and webSearch return web content, and 'scraperAPI' doesn't obviously signal 'fetch a known page,' but descriptions clarify the boundary.
scraperAPI and webSearch follow a camelCase verb+noun style, while 'status' is a bare noun, a minor deviation. The API suffix on scraperAPI is slightly unconventional but the set is still predictable and readable.
Three tools is on the thin side but each earns its place for a focused scraping service (fetch, search, account check). It's slightly under-scoped rather than bloated.
Core workflows — retrieving a page, running a web search, and checking quota — are covered with rich SDK-compatible options. There's no batch/crawl or structured-extraction tool, but agents can work around this with the existing scrape operation.
Maintenance
Related MCP Connectors
Web search and page-reading for AI agents. One-click OAuth connect, or a Caesar API key.
Web search, page reading, HTML to PDF, file upload and flight search for AI agents, paid in USDC.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
Web data for agents: YouTube transcripts, screenshots, Google News, WHOIS, jobs, tech stack, more.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI assistants to access real-time web data through search, markdown scraping, and browser automation while bypassing anti-bot protections. It provides tools for web research, e-commerce monitoring, and data extraction from across the globe.410,225 npm5MIT
- AlicenseNot gradedqualityBmaintenanceLets AI assistants control your real Chrome browser to perform web tasks like reading pages, taking screenshots, clicking, and typing, using your existing logged-in sessions.143MIT
- FlicenseNot gradedqualityDmaintenanceUnlimited, session-authenticated web search and fetch for AI tools using your own browser. Supports authenticated/paywalled pages without API keys.-
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to search the web, read and extract content from webpages, fetch JSON from REST APIs, and collect links while bypassing anti-bot protections.26 npmISC