URLpipe

Extract structured data with your own schema

extract_data

Idempotent

Exposes POST /extract. Reads the page and fills an object YOU define: pass fields, each with a name, a type and a description of what to take from the page, and get back exactly those keys in that order. Anything the page does not give comes back null — values are never guessed. Types: string, number, integer, boolean, date, datetime, url, email, object (with its own fields) and array (with items). Use it for product details, prices, contact data, job listings, event dates, lists of items with several attributes each. 24 credits: it reads the whole page with an AI model, so prefer extract_metadata when the standard metadata is all you need.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	The page to fetch. Must be a public http(s) URL.
`sync`	No	Wait for the result and return it (default false). When false the call returns a token immediately and you collect the result with get_result.
`fields`	Yes	The fields to extract, at most 50 in all.
`labels`	No	Your own keys to find this request by later, e.g. {"client": "acme"}: they come back with the result, in the webhook and in list_requests, which can filter by them. Up to 16 keys of up to 40 letters, digits, _ - or .; string values up to 256 characters.
`max_age`	No	How fresh a stored result must be to be reused, e.g. "2 hours" or "3 days". Default 7 days, maximum 30. A reused result is free. Pass "0" to force a fresh fetch.
`report_to`	No	Async only: a webhook URL to deliver the result to. Defaults to the project's configured endpoint, if it has one.
`project_id`	Yes	Which project this request belongs to. From list_projects.
`residential`	No	Fetch the page from a residential (home ISP) exit instead of a datacentre one. Costs a surcharge per page visit — see get_usage. Use it for sites that block datacentre traffic.
`instructions`	No	Optional guidance that applies to every field, e.g. "prices in EUR".
`page_options`	No	What to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too, and what scrolling loaded is in all of them.
`idempotency_key`	No	Makes the call safe to retry: sending it again with the same key within 24 hours returns the first call's token and result instead of starting (and charging for) new work, even with max_age "0". Up to 255 printable ASCII characters; a UUID is ideal.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 12, 2026

changedInput schema / properties / page_options / description

Previous value: -"What to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too."New value: +"What to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too, and what scrolling loaded is in all of them."

addedInput schema / properties / page_options / properties / scroll_to_bottom

Added value: +{
+  "description": "Scroll down the page before reading it, for as long as scrolling loads more (up to 25s). For listings and feeds that load their content as they are scrolled.",
+  "type": "boolean"
+}

AddedOct 12, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorld), so the bar is lower, yet the description adds real behavior: missing values come back null and are never guessed, and the 24-credit AI-based read is disclosed. It does not itself explain the sync default/token flow or caching, though those live in the schema.

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?

Front-loaded with what the tool does, then types, then use cases, then cost/warning in a logical order. The type enumeration and use-case list add length but each maps to a real decision; only minor trimming is possible.

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?

An output schema exists, so return values need not be explained, and the description covers the remaining decision-relevant facts: custom schema contract, null semantics, credit cost, and the cheaper sibling. Nothing an agent needs to invoke this correctly is missing.

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 is 3, but the description adds semantics not present in the schema: result keys come back in the defined order, unextractable values are null, and the supported type list is spelled out for a human-readable overview. The nested fields/items mechanics are left to the schema, which is appropriate.

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 (extract) and resource (structured data from a page) and immediately frames the defining feature: the caller supplies the schema and gets back exactly those keys. It is clearly distinguishable from extract_metadata and scrape_url, which it names or implies.

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?

Gives concrete when-to-use examples (product details, prices, contact data, job listings, event dates) and an explicit alternative: 'prefer extract_metadata when the standard metadata is all you need.' The cost driver (24 credits, AI model reads the whole page) further informs the choice.

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

All URLpipe tools Inspect

Try in Browser

Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?