Skip to main content
Glama
ZenRows
by ZenRows

extract

Read-only

Pull structured JSON data such as products, articles, and listings from a webpage with Zenrows, using auto, autoparse, or CSS selector modes.

Instructions

Extract structured data from a webpage via Zenrows.

Returns JSON fields (products, articles, listings) rather than a full page body. Modes:

  • auto (default): extract=auto, site-tailored Extract (currently free, billing may apply later). Works on any domain Zenrows has prepared, with any API key; falls back to autoparse when the domain isn't prepared yet (REQS007)

  • autoparse: general-purpose structured JSON on any domain

  • css: css_extractor with an explicit selector map

Requests use automatic mode (mode=auto) by default: Zenrows enables JS rendering and premium proxies only when the site needs them, and charges only for the configuration that succeeds. Pass just the URL. Set js_render or premium_proxy only to force a fixed configuration; that turns automatic mode off and bills every request at that configuration's cost.

Check "empty" in the result: true means no field came back with a value. "noDataExtracted": true means Extract processed the page and found nothing to extract (not charged); retrying the same request returns the same answer. Full-page markdown, HTML and screenshots come from scrape.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe webpage URL to extract from
modeNoExtraction mode: auto (extract=auto, default), autoparse, or css (requires css_extractor)auto
waitNoMilliseconds to wait after load. Requires js_render=true; without it, including in automatic mode, it may be ignored.
wait_forNoCSS selector to wait for before extracting. Requires js_render=true; without it, including in automatic mode, it may be ignored.
js_renderNoForce JS rendering on every request. Overrides automatic mode (mode=auto), which already renders when needed.
mode_autoNoAutomatic mode (mode=auto) is on by default; leave unset. False sends a plain request without it.
css_extractorNoRequired when mode=css. JSON map of field→selector, e.g. '{"title":"h1","price":".price"}'
premium_proxyNoForce premium residential proxies on every request (10x cost). Overrides automatic mode (mode=auto), which already uses premium proxies when a page needs them.
proxy_countryNoISO 3166-1 alpha-2 country code. Works in automatic mode (mode=auto); with js_render or mode_auto=false it requires premium_proxy.
fallback_autoparseNoWhen mode=auto and the domain isn't prepared for Extract yet (REQS007, or the legacy AUTH010), retry once with autoparse (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.7.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/non-destructive, so the bar is low, yet the description adds substantial behavior: billing semantics (auto charges only for the succeeding configuration; forcing a config bills every request at 10x for premium proxies), fallback-on-unprepared-domain, and the meaning of the result flags 'empty' and 'noDataExtracted' plus the no-retry advice. This is exactly the operational context annotations cannot carry.

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?

Purpose and return shape are front-loaded, the mode list is scannable, and the closing note routes full-page needs to scrape. It runs long, but nearly every line carries behavior, cost, or mode-selection information, so little is wasted.

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

Completeness5/5

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

With 10 parameters, no output schema, and cost-bearing configuration choices, this would be easy to under-document. Instead the description covers mode selection, the automatic-vs-forced tradeoff, fallback behavior, and the shape and failure flags of the return value, which is enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds cross-parameter semantics the schema cannot: forcing js_render/premium_proxy disables automatic mode and changes billing, wait/wait_for are inert without js_render even in auto mode, and fallback_autoparse only applies to mode=auto. The css_extractor example also appears in the schema, so that portion is duplicative rather than additive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Extract structured data from a webpage') and immediately narrows the output contract ('Returns JSON fields (products, articles, listings) rather than a full page body'). It also explicitly distinguishes itself from the sibling scrape tool for full-page content, so an agent can route without opening a schema.

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

Usage Guidelines5/5

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

The three modes (auto/autoparse/css) are each given a when-to-use condition, including the default and the fallback case (REQS007), and the description names the alternative tool ('Full-page markdown, HTML and screenshots come from scrape'). It further states when NOT to set js_render or premium_proxy and why.

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