Scrapling MCP Server

Fetch page in browser

browser_fetch_once

Read-only

Fetch JavaScript-rendered web pages through a stealth browser to retrieve content as Markdown, text, or HTML for scraping and LLM ingestion.

Instructions

Fetch a page with a stealth browser and JavaScript rendering.

Input Schema

Name	Required	Description	Default
`url`	Yes	URL to fetch.
`wait`	No	Extra milliseconds after the page is ready, before returning.
`proxy`	No	Proxy URL, or dictionary with server and optional username/password.
`locale`	No	Browser language, Accept-Language, and formatting locale; system default if omitted.
`cdp_url`	No	Connect to an existing Chromium browser over CDP in a new context; launch settings do not apply.
`cookies`	No	Initial cookies as Playwright cookie dictionaries.
`timeout`	No	Navigation and page-operation timeout in milliseconds.
`headless`	No	Hide the browser window.
`useragent`	No	User-Agent override; otherwise generated in headless mode, native in headful mode.
`allow_webgl`	No	Enable WebGL; disabling it can trigger bot detection.
`hide_canvas`	No	Add noise to canvas operations.
`real_chrome`	No	Use locally installed Chrome.
`timezone_id`	No	Browser timezone; uses the system timezone if omitted.
`block_webrtc`	No	Disable non-proxied WebRTC UDP to reduce IP leaks.
`css_selector`	No	Select matching elements after `main_content_only` filtering.
`network_idle`	No	Try to wait for 500 ms without network activity; continue if the wait fails.
`extra_headers`	No	Additional request headers.
`google_search`	No	Set a Google referer, overriding any supplied referer.
`pierce_shadow`	No	Include open Shadow DOM content.
`wait_selector`	No	Wait for the first CSS match; continue if the wait fails.
`additional_args`	No	Browser context options that override Scrapling settings.
`executable_path`	No	Absolute Chromium-compatible executable path; overrides the server default.
`extraction_type`	No	Content output format.	markdown
`solve_cloudflare`	No	Attempt to solve Cloudflare Turnstile/interstitial challenges before returning.
`disable_resources`	No	Block font, image, media, beacon, object, imageset, texttrack, websocket, csp_report, and stylesheet requests.
`main_content_only`	No	Sanitize <body> content before selection; False uses the full document.
`wait_selector_state`	No	Target state of `wait_selector`.	attached

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.2/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 open-world nature are covered. The description adds genuinely useful context by naming stealth and JS rendering, but omits the tradeoffs an agent cares about here — whether a session persists, what gets destroyed, and why one would choose this over browser_fetch.

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?

A single front-loaded sentence with no filler. It is efficient, though the leanness borders on under-specification given the tool's 27-parameter complexity.

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

Completeness3/5

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

An output schema and rich annotations reduce what the description must carry, but with 27 parameters and 16 sibling browser/session tools, the description should at least clarify one-shot versus session semantics. It leaves that ambiguity unresolved.

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% across 27 parameters, so the schema carries the full burden of explaining url, wait, timeout, extraction_type, cookies, and stealth flags. The description adds nothing beyond what the schema documents, which is the expected baseline when coverage is this high.

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 (fetch a page) plus the distinguishing mechanism (stealth browser, JavaScript rendering). However, it never contrasts with sibling tools like browser_fetch, browser_open, or make_request, so an agent must infer where it fits.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no exclusions, and no mention of alternatives. The 'once' in the name implies one-shot versus session-based fetching, but the description never confirms or explains this relative to browser_open or open_request_session.

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

Deploy Server