Scrapling MCP Server

Send HTTP request

make_request

Read-only

Fetch web pages over HTTP without executing JavaScript, then extract content as text, HTML, or Markdown for low-to-mid protected sites.

Instructions

Make an HTTP request without JavaScript. Suitable for low-to-mid protection.

Input Schema

Name	Required	Description	Default
`url`	Yes	URL to fetch.
`auth`	No	Basic auth: {"username": ..., "password": ...}.
`data`	No	Form or raw body; ignored for GET.
`json`	No	JSON body; ignored for GET.
`http3`	No	Use HTTP/3; may conflict with browser impersonation.
`proxy`	No	Proxy URL, optionally including credentials.
`method`	No	HTTP method.	GET
`params`	No	Query parameters.
`verify`	No	Verify TLS certificates.
`cookies`	No	Request cookies.
`headers`	No	Request headers.
`retries`	No	Maximum attempts, including the first; None or values below 1 send once.
`timeout`	No	Timeout in seconds.
`proxy_auth`	No	Proxy basic auth: {"username": ..., "password": ...}.
`impersonate`	No	Browser/version to impersonate; "chrome" uses the latest supported Chrome profile. Lists pick randomly per attempt; None disables impersonation.	chrome
`retry_delay`	No	Seconds between retries.
`css_selector`	No	Select matching elements after `main_content_only` filtering.
`max_redirects`	No	Redirect limit; -1 means unlimited.
`extraction_type`	No	Content output format.	markdown
`follow_redirects`	No	"safe" blocks redirects to private/internal IPs; True allows all; False disables redirects.	safe
`stealthy_headers`	No	Fill missing browser headers and use a Google referer if none was supplied.
`main_content_only`	No	Sanitize <body> content before selection; False uses the full document.

Output Schema

Name	Required	Description
`url`	Yes	The URL given by the user that resulted in this response.
`status`	Yes	The status code returned by the website.
`content`	Yes	The page content as Markdown, HTML, text, or an AI ARIA snapshot.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 30, 2026

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external reach are covered. The description adds the meaningful behavioral note that no JavaScript executes and that it targets low-to-mid protection sites, but it is silent on the significant behaviors exposed by the schema (retries, impersonation conflicts, redirect safety) that an agent should understand before calling.

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?

Two short, front-loaded sentences with zero filler and the key differentiator placed early. It is efficiently written, though the brevity borders on under-specification for a 22-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, but for a 22-parameter tool with impersonation, retries, proxy, and redirect-safety behaviors, the description omits routing guidance versus the many sibling fetch/session tools and any note on limits or typical failure modes.

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 all 22 parameters are self-documented with defaults, enums, and semantics (e.g. follow_redirects safe mode, impersonate list randomization). The description adds no parameter-level meaning, so baseline 3 applies.

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?

States a specific verb and resource ("Make an HTTP request") and adds a differentiator against the browser siblings by noting it runs "without JavaScript." An agent can tell this is the non-browser fetch path, though it doesn't name which specific sibling to prefer.

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?

"Suitable for low-to-mid protection" implies a scope boundary and hints that heavier protection needs another tool, but it never names the alternative (browser_fetch, browser_fetch_once, session_make_request) nor states explicit when-not conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server