MrScraper MCP Server

Official

by mrscraper-com

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Scraper API

scraperAPI

Read-only

Retrieve a known web page as HTML, Markdown, or a screenshot through MrScraper, with proxy, browser rendering, retry, and timeout controls.

Instructions

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.

Input Schema

TableJSON Schema

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

TableJSON 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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.2Oct 20, 2026

TDQS

A3.7/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Deploy Server