Skip to main content
Glama

Scrape page content as Markdown, text, or HTML

scrape_page

Loads JavaScript-rendered pages in a real browser and extracts clean Markdown, text, HTML, or image URLs for reading and summarizing content that plain HTTP fetches cannot access.

Instructions

Loads a page in a real browser (JavaScript executed) and extracts its content: clean Markdown (best for reading and summarizing), plain text, the fully rendered HTML, and/or every image URL on the page. Extracted files are fetched and returned inline, truncated to max_content_chars. Works on JavaScript-heavy sites that plain HTTP fetches can't read. A screenshot is captured as part of the same request and counts as one credit.

Input Schema

NameRequiredDescriptionDefault
jsNoJavaScript executed in the page before capture, e.g. "document.querySelector('.popup').remove();".
cssNoCSS injected before capture, e.g. '.header { display: none; }'.
urlNoWebsite URL to render, including the protocol, e.g. 'https://example.com'. Either url or custom_html is required.
blockNoResources to block while rendering. For a clean capture use ['ads', 'cookie_banners', 'chat_widgets']. 'tracking' blocks analytics. 'javascript', 'stylesheets', 'xhr', and 'fetch' can break pages or hide content — use only when needed. Others: images, media (audio/video), fonts, text_tracks, event_source, websockets, manifest.
delayNoExtra wait in milliseconds after the page loads, before capture. Default 0. Use 1000-5000 for animations, charts, or late-loading content.
proxyNoProxy to route the request through: 'address:port' or 'username:password@address:port' (an http:// prefix is accepted). Useful for geo-specific content or CAPTCHA-prone sites.
widthNoBrowser viewport width in pixels (max 7680). Default 1680. Use ~390 to emulate a phone, ~768 for a tablet.
heightNoBrowser viewport height in pixels (max 4320). Default 876.
js_urlNoURL of an external JavaScript file to execute before capture.
cookiesNoCookies to set before loading, as 'name=value; other=value;'. Use for pages behind a login.
css_urlNoURL of an external stylesheet to inject before capture.
extractNoWhat to extract. Default ['markdown']. Options: markdown, text, html, image_urls.
headersNoExtra HTTP headers as 'Name: value;' pairs separated by semicolons, e.g. 'Authorization: Bearer abc; X-Test: 1;'.
timeoutNoMaximum milliseconds the API waits for the page to load before aborting. Default 100000.
latitudeNoLatitude reported by the browser Geolocation API.
timezoneNoIANA timezone to emulate, e.g. 'America/New_York', 'Asia/Karachi'. Default is the server timezone.
dark_modeNoRender with the dark color scheme (for sites that support it). Default false.
grayscaleNoDesaturate the output, 0 (full color, default) to 100 (fully grayscale).
lazy_loadNoScroll through the whole page first so lazy-loaded images and sections render. Default false.
longitudeNoLongitude reported by the browser Geolocation API.
adjust_topNoScroll the viewport down this many pixels before capture. Default 0. Not supported for PDFs.
user_agentNoCustom User-Agent string, e.g. a mobile Safari UA to get the mobile site.
custom_htmlNoRaw HTML to render instead of loading a URL. Takes precedence over url. Inline CSS and JavaScript in the HTML are applied. Useful for pages that are not publicly reachable.
template_idNoID of a saved cookie template from the ScreenshotAPI dashboard to apply before navigation.
scroll_delayNoMilliseconds to wait between scroll steps when lazy_load is true. Default 500. High values on long pages can hit the timeout.
blur_selectorNoCSS selector(s) of elements to blur, comma-separated — for redacting emails, account numbers, or other sensitive data.
wait_for_eventNoPage lifecycle event to wait for before capture. 'load' (default) waits for all resources; 'domcontentloaded' is faster but may miss images; 'networkidle' waits until no network requests for 500ms — best for SPAs and dashboards.
click_recursionNoHow many times to click selector_to_click in sequence. Requires selector_to_click. Default 0.
include_contentNoFetch the extracted files and return their contents inline. Default true. false returns only the file URLs.
remove_selectorNoCSS selector(s) of elements to remove from the page before capture, comma-separated, e.g. '.ad-banner, #sidebar'. Non-matching selectors are ignored.
accept_languagesNoAccept-Language header for localized content, e.g. 'fr-FR,fr;q=0.9'. Default 'en-US,en;q=0.8'.
enable_incognitoNoRender in an isolated incognito session with no persisted cookies or storage. Default false.
max_content_charsNoTruncate each extracted file to this many characters. Default 50000.
scroll_to_elementNoCSS selector of an element to scroll into view before a viewport capture.
selector_to_clickNoCSS selector of an element to click before capture, e.g. to open a tab, dropdown, or accordion.
block_specific_requestsNoSpecific request URLs or patterns to block, separated by commas, spaces, or newlines, e.g. 'https://example.com/api/data, https://ads-domain.com'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description does most of the work: it discloses that a real browser renders the page with JavaScript executed, that extracted files are fetched and returned inline, that output is truncated to max_content_chars, and that a screenshot is included and "counts as one credit", which is a billing behavior not visible in the schema. It still omits auth/rate-limit expectations and failure behavior for a 36-param tool.

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?

Five sentences, front-loaded with the core verb and output formats, then the inline/truncation behavior, then the JS-site rationale, then cost. Each sentence carries information, and the length is reasonable for a 36-parameter tool, though the screenshot/credit sentence could be merged or moved.

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?

For a tool with 36 parameters and no output schema, the description should clarify the return shape, but it only says files are fetched and returned inline and truncated, without describing the response structure or how the screenshot relates to the extraction output. It is adequate given the rich schema, but it leaves real gaps around return values and error behavior.

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 coverage is 100%, so the schema already documents all 36 parameters thoroughly, making 3 the baseline. The description adds only marginal meaning: the tradeoff between Markdown and other extract modes, and the truncation role of max_content_chars; it leaves the other 34 parameters entirely to the schema.

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 has a specific verb and resource: loads a page in a real browser and extracts Markdown, text, HTML, or image URLs. It distinguishes itself from plain HTTP fetches ("JS-heavy sites that plain HTTP fetches can't read") but never contrasts with its actual siblings take_screenshot or generate_pdf, even though it notes a screenshot is captured as a side effect, which blurs the line with take_screenshot.

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?

"Works on JavaScript-heavy sites that plain HTTP fetches can't read" and "Markdown (best for reading and summarizing)" imply when to prefer this tool and which extract mode to pick. However, it never says when to use take_screenshot or generate_pdf instead, and it has no explicit exclusions or prerequisites.

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