URLpipe

Name: URLpipe
Author: URLpipe

by dev.urlpipe

Overview Discussions Admin

Server Details

Read any page with its JavaScript run: Markdown, screenshots, metadata, console errors, Lighthouse.

Ownership verified

Status: Healthy
Uptime: 98.8% over 22 days
Last Tested: 2026-10-16 23:40
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: URLpipe/mcp
GitHub Stars: 0
Server Listing: URLpipe MCP server

TDQS

A4.1/5.0

Scored 2026-09-30 13:15 across 14 tools

Disambiguation4/5

Each tool targets a distinct resource or output, and descriptions explicitly clarify boundaries (fetch_markdown for reading, fetch_html for markup, extract_metadata for declared metadata, scrape_url as a batch wrapper). The overlap among the fetch/extract tools is real but the guidance for choosing between them is unusually clear, so only minor confusion remains.

Naming Consistency5/5

Every name is a consistent snake_case verb_noun pair (fetch_, extract_, capture_, get_, list_, run_, scrape_, summarize_), covering both action and target predictably. No mixed conventions or vague verbs.

Tool Count5/5

14 tools sits comfortably in the ideal 3-15 range. Each tool represents a genuine operation of the service (page fetches, extraction, audits, plus project/request/result/usage management) with no filler.

Completeness4/5

The surface covers the full lifecycle: fetch/render, extract, capture, audit, batched scraping, plus retrieving past requests, results, usage and projects. Minor gaps exist around project/webhook creation and management (only list_projects is offered), but core workflows are fully supported.

Available Tools

17 tools

capture_console_errorsCapture console errors

Idempotent

Inspect

Exposes POST /console. Loads the page in headless Chrome and returns what it reported through console.error and console.warn during load, plus uncaught exceptions and unhandled promise rejections (not console.log). 1 credit.

What you would open DevTools for: broken third-party scripts and client-side errors you cannot reproduce locally.

ParametersJSON 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.
`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.
`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

ParametersJSON Schema

Name	Required	Description
No output parameters

capture_pdfSave a page as PDFA

Idempotent

Inspect

Exposes POST /pdf. Prints the whole rendered page to a PDF — JavaScript executed, web fonts and lazy-loaded images included, its headings as bookmarks. 1 credit, whichever options you use.

Use it to archive or hand on a page as a document: a receipt, an article, a report, terms as they stood today. pdf_options choose the paper, the orientation, the margins and the scale, whether backgrounds print, whether the page's print stylesheet or its on-screen look is used, and whether to cut it into sheets at all; page_options wait for the page and take ads and cookie banners out of it.

ParametersJSON 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.
`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.
`pdf_options`	No	How to print the PDF. Every key is optional; leave it out for A4 portrait.
`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.
`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

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-schema context: a flat cost of '1 credit, whichever options you use', and the rendering behaviors (JavaScript executed, web fonts and lazy-loaded images included, headings turned into bookmarks). It does not mention the residential surcharge or caching beyond what the schema states, so it is not exhaustive.

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?

The definition is front-loaded: the first sentence establishes the operation and its rendering fidelity, the second gives cost, and the third gives use cases and options. The third sentence is long and slightly dense, but every clause earns its place by summarizing an option group the agent would otherwise have to read out of the nested schema.

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

Completeness4/5

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

With an output schema present, the description is not obligated to explain return values, and it covers cost, rendering behavior, and both option groups. The remaining gap is routing: for a 10-parameter tool with many near-sibling capture tools, it should say when PDF output is the right pick versus capture_screenshot or fetch_html.

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 the schema already documents all ten parameters in detail, including the enum values and defaults. The description's paragraph on pdf_options and page_options ('the paper, the orientation, the margins and the scale... whether to cut it into sheets') mostly paraphrases those same fields rather than adding new semantics such as format constraints or interactions. The 3 baseline is therefore correct.

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 names a concrete verb and resource: it 'Prints the whole rendered page to a PDF', and goes further to specify what the PDF includes (executed JavaScript, web fonts, lazy images, headings as bookmarks). This is far more specific than a title restatement. However, it never names or contrasts with the obvious sibling alternatives (capture_screenshot, fetch_html, fetch_markdown), so it falls short of the explicit sibling differentiation a 5 requires.

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

Usage Guidelines4/5

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

The description gives a clear use context — 'archive or hand on a page as a document' with concrete examples (a receipt, an article, a report, terms as they stood today). This tells the agent when this tool is appropriate. What is missing is any exclusion or explicit alternative: nothing says when to prefer capture_screenshot or fetch_markdown over this, which keeps it below a 5.

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

capture_screenshotTake a screenshot

Idempotent

Inspect

Exposes POST /screenshot. Captures the whole rendered page as a PNG — JavaScript executed, web fonts and images included, exactly as a browser would draw it. 1 credit, whichever options you use.

Use it to see a page rather than read it: layout, visual regressions, link previews, or checking what an anti-bot page actually showed us. screenshot_options size it (viewport, scale, one element, the fold only), encode it (png, jpeg or webp) and restyle it (dark mode, hidden elements, your own CSS); page_options wait for the page and take ads and cookie banners out of it.

ParametersJSON 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.
`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.
`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.
`screenshot_options`	No	How to take the screenshot. Every key is optional; leave it out for a full-page PNG.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

detect_technologiesDetect a page's technologiesA

Idempotent

Inspect

Exposes POST /technologies. Detects what a page is built with — CMS, e-commerce platform, JavaScript frameworks and libraries, analytics and tag managers, advertising and marketing tools, CDN, web server, programming language, payment providers, chat widgets, consent managers and more — from an open database of over 7,000 fingerprints. Each technology comes with its version when the page gives it away, a confidence from 0 to 100, its categories, its website and CPE, and which signals gave it away (html, meta tags, headers, cookies, JavaScript globals, DOM, script URLs and contents, stylesheets, DNS records, robots.txt). The page is rendered first, so technologies loaded by JavaScript are found too. 1 credit.

ParametersJSON 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.
`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.
`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

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior4/5

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

Adds real value beyond annotations: page is rendered first so JS-loaded techs are found, fingerprint DB size (7,000+), what each result contains, and the cost (1 credit). Annotations only flag openWorld/idempotent/non-destructive; the description tells the agent the work is a rendered fetch with a metered cost, which materially changes invocation decisions. Does not disclose latency or failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and detection scope, but the middle sentence is a long run-on list of 12 categories that could be compressed, and the trailing '1 credit' cost detail is buried at the end rather than flagged earlier.

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

Completeness4/5

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

For a 9-parameter async-capable tool with full schema coverage and an output schema, the description covers purpose, rendering behavior, result contents, and cost — enough for correct invocation. Missing only cost/rate context around the residential surcharge and async token flow, which the schema partially handles via get_result.

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 all nine parameters are documented in the schema (sync vs async, max_age caching, residential surcharge, idempotency). The description adds nothing parameter-specific, which is acceptable given full schema coverage — baseline 3.

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 (detects) and resource (a page's technologies) and enumerates the categories detected, so an agent can distinguish it from siblings like extract_metadata or run_lighthouse_audit without opening the schema. The 'Exposes POST /technologies' opener is the only slightly redundant part.

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?

The description never says when to choose this over extract_metadata, fetch_markdown, or run_lighthouse_audit, and gives no exclusions or prerequisites beyond the URL being public http(s). A precisely worded but purely descriptive entry point with no routing guidance.

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

extract_dataExtract structured data with your own schemaA

Idempotent

Inspect

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.

ParametersJSON 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

ParametersJSON Schema

Name	Required	Description
No output parameters

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.

extract_keywordsExtract keywords

Idempotent

Inspect

Exposes POST /keywords. Returns the 5–15 terms and phrases that best represent the page, ordered by relevance — ranked by a language model, not by raw frequency. 15 credits.

As with summarize_page: if you are going to reason over the result yourself, fetch_markdown costs 1 credit and gives you everything.

ParametersJSON 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.
`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.
`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

ParametersJSON Schema

Name	Required	Description
No output parameters

extract_metadataExtract page metadata

Idempotent

Inspect

Exposes POST /meta. Reads everything a page declares about itself — Open Graph, Twitter cards, meta tags, JSON-LD, microdata and links — into one object with the same keys on every page: title, description, site name, kind of page, language, authors, publication and update dates, share image and video, favicon and icons, logo, feeds, keywords, canonical URL, robots directives, hreflang alternates, oEmbed endpoint and structured-data types, plus the raw og: and twitter: tags. A value the page does not declare is null or an empty list. Values injected by JavaScript are included, because the page is rendered first. 1 credit.

ParametersJSON 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.
`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.
`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

ParametersJSON Schema

Name	Required	Description
No output parameters

fetch_htmlGet the rendered HTML

Idempotent

Inspect

Exposes POST /html. Returns the page's HTML after JavaScript has run and redirects have been followed — the DOM a real browser sees, not the empty shell curl returns. 1 credit.

Use it when you need the markup itself: a specific attribute, a script tag, a structured-data block. If you want to read the page's content, fetch_markdown costs the same and returns a fraction of the text.

ParametersJSON 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.
`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.
`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

ParametersJSON Schema

Name	Required	Description
No output parameters

fetch_markdownRead a page as Markdown

Idempotent

Inspect

Exposes POST /markdown. Renders the page in headless Chrome and converts its main content to clean Markdown — headings, lists, links and code kept, navigation, sidebars and cookie banners dropped.

Start here when you want to READ a page. It is the cheapest operation we sell (1 credit) and by far the most compact thing to put in front of a model: fetch_html returns the whole DOM, which is usually many times larger and says nothing extra about what the page means.

ParametersJSON 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.
`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.
`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

ParametersJSON Schema

Name	Required	Description
No output parameters

get_requestInspect a past requestA

Read-onlyIdempotent

Inspect

Everything about one past request except its result: what was asked for, how long each stage took, whether it came from the store, and how the webhook delivery went.

This is the metadata; get_result returns the page itself. Reach for this one when a call did not do what you expected — it says whether the result was reused, why an analysis failed, and whether the delivery to the project's endpoint succeeded.

ParametersJSON Schema

Name	Required	Description	Default
`token`	Yes	The token the original call returned.
`project_id`	Yes	From list_projects.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`meta`	No	What the HTTP response headers would say: cache, cost, quota, result_url, final_url.
`async`	No
`token`	Yes
`labels`	No
`status`	Yes
`credits`	No
`max_age`	No
`outcome`	No
`success`	No
`final_url`	No	Where the page ended up after its redirects.
`operation`	No
`report_to`	No
`created_at`	No
`operations`	No
`duration_ms`	No
`finished_at`	No
`webhook_error`	No
`webhook_status`	No
`request_options`	No
`served_from_cache`	No
`webhook_delivered_at`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine behavioral value beyond that: it reveals what data is exposed (stage timings, store reuse, webhook delivery outcome, why an analysis failed) and what is excluded (the result). It stops short of stating auth or rate-limit behavior, but for a read tool that is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, both front-loaded with the key constraint (result excluded) and the decision trigger. No filler; every clause carries information.

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-shape explanation is not required, yet the description still tells the agent which diagnostic fields to expect and why to call it. Nothing an agent needs to invoke it correctly is missing.

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% and both parameters are documented in the schema (token, project_id with source hint). The description adds no further parameter syntax or semantics, so baseline 3 applies.

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 (inspect) and resource (one past request) and immediately delimits scope: 'Everything about one past request except its result.' It explicitly separates itself from get_result, so an agent can route without opening either 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?

Gives an explicit when-to-use trigger ('Reach for this one when a call did not do what you expected') and names the alternative (get_result returns the page itself). The contrast with the sibling makes the selection condition unambiguous.

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

get_resultGet a result

Read-onlyIdempotent

Inspect

Exposes GET /result/:token. Returns the result of a past request, in the same form the call that made it would have returned — Markdown as Markdown, a structured operation as its object, a screenshot as an image, a PDF as an embedded application/pdf resource, a scrape as its combined object.

This is how an async call is collected: any tool called without sync: true answers with a token, and this turns that token into the result. It also re-reads a result somebody already paid for, which is free — results are kept for 30 days.

A request that has not finished yet answers {"status": "processing"}; call again in a moment.

ParametersJSON Schema

Name	Required	Description	Default
`token`	Yes	The token the original call returned.
`project_id`	Yes	From list_projects.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

get_usageCheck usage and pricesA

Read-onlyIdempotent

Inspect

What the organization's plan allows, how much of it is left this period, and what each operation costs.

Worth reading before a run of expensive calls: the operations differ by seventeen times in price, so the difference between fetch_markdown and summarize_page over a hundred pages is 100 credits against 1,700. It is also how to read a refusal — a call that comes back with quota_exceeded is telling you this number ran out.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`plan`	Yes
`credits`	Yes
`plan_name`	No
`concurrency_limit`	No
`cost_per_operation`	Yes
`residential_surcharge_per_page_visit`	No

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: it reveals that operation prices differ by a factor of seventeen, and it explains that a quota_exceeded error indicates this number has run out. This goes beyond the annotations by tying the tool to rate-limit semantics and error interpretation, which is exactly the kind of context the dimension seeks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the core purpose, the second provides a concrete usage scenario and an error-interpretation tip. It is front-loaded with the primary function and wastes no words. Every sentence earns its place, and the structure is efficient and scannable.

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?

Given the tool's simplicity (no parameters, an output schema exists), the description covers all essential aspects: what data it returns (plan allowance, remaining quota, operation costs), when to use it (before expensive calls), and how to interpret a specific error (quota_exceeded). It is fully sufficient for an agent to know when and why to invoke it.

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?

The tool has zero parameters, so the schema coverage is trivially 100%. Per the rubric, a baseline of 4 is appropriate when there are no parameters to explain. The description does not need to elaborate on parameters, and it correctly avoids doing so.

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?

The description clearly states what the tool does: it reports the organization's plan limits, remaining quota for the period, and the cost of each operation. This is specific and distinct from sibling tools like fetch_markdown or summarize_page, which are about fetching or summarizing content. It uses a concrete verb-resource pair ('get usage and prices') and leaves no ambiguity about its function.

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 description explicitly advises using this tool before a run of expensive calls, gives a concrete example comparing fetch_markdown and summarize_page costs, and explains how to interpret a quota_exceeded refusal. This gives clear guidance on when to call it and how it relates to other operations, effectively routing the agent to the right context.

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

list_projectsList projectsA

Read-onlyIdempotent

Inspect

The projects this token can reach, each with how many requests it has made in the last 30 days and where its results are delivered.

Start here: every other tool takes a project_id from this list. A project is the unit a request is billed and recorded against — credits themselves belong to the organization, so which project you pick does not change what a call costs.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`projects`	Yes
`organization`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already carry the safe, read-only, idempotent profile, so the description's job is to add context beyond that. It does by disclosing token-based scoping, the included usage statistics, and the relationship between projects, credits, and billing. This is meaningful behavioral context without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Both sentences earn their place: the first defines the output contents, and the second provides essential usage and billing orientation. The 'Start here' directive is front-loaded and there is no repetition of schema or annotation information.

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?

For a parameterless list operation with an output schema, the description fully covers what an agent needs to invoke it correctly and why it should be the first call. It explains scope, output content, and downstream usage with no missing operational details.

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?

The tool takes zero parameters, so the schema already fully documents the input surface. The description adds context about how the returned project_id will be used by other tools, which is the relevant semantic information here.

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: lists projects visible to the token. It also specifies what each project entry contains (request counts in last 30 days, result delivery location), which clearly differentiates it from the sibling action tools.

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?

Explicitly says 'Start here' and explains that every other tool consumes a project_id from this list, giving the agent a clear invocation order. The billing clarification also prevents the agent from assuming project choice affects cost.

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

list_requestsList past requests

Read-onlyIdempotent

Inspect

A project's recent requests, newest first, with each one's token.

Look here before fetching a page: if somebody already pulled it, passing that token to get_result returns the same result for nothing. A /scrape appears as one entry — its per-operation children are internal, and the scrape's own token returns all of them.

Pass labels to see only the requests made with them — every key given must match its value exactly.

ParametersJSON Schema

Name	Required	Description
`url`	No	Only requests for this exact URL.
`limit`	No	How many to return. Default 25, maximum 100.
`labels`	No	Only requests made with all of these labels, each value matched exactly.
`offset`	No	Skip this many, for paging.
`operation`	No	Only requests running this operation.
`project_id`	Yes	From list_projects.

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	Yes
`offset`	Yes
`requests`	Yes
`project_id`	Yes

run_lighthouse_auditRun a Lighthouse auditA

Idempotent

Inspect

Exposes POST /lighthouse. Runs a real Google Lighthouse audit against the live page: performance, accessibility, best-practices and SEO scores plus Core Web Vitals. 2 credits — dearer than a page fetch because the audit runs in its own limited lane, so it also takes longer than anything else here.

It fetches the page itself rather than sharing a visit, so asking for it inside scrape_url costs two page visits, not one.

ParametersJSON 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.
`device`	No	Which profile to audit under. Default mobile.
`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.
`include_audits`	No	Include the full per-audit detail, not just scores and metrics. Much larger; default false.
`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

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior5/5

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

The description goes well beyond annotations. It discloses that the tool makes a network request (openWorldHint true), is not read-only (readOnlyHint false) because it runs a computation and charges credits, supports idempotency (idempotentHint true) via idempotency_key, and is non-destructive (destructiveHint false). It adds unique behavior: it fetches the page independently, caches results (max_age), supports async delivery, and has a residential exit option. No contradiction with annotations.

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?

The description is two paragraphs, but every sentence carries useful information: purpose, cost, latency, fetch behavior, and a note about interaction with scrape_url. It is front-loaded with the core purpose. Slightly longer than necessary but justified by the tool's complexity.

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?

Given the tool's complexity (10 parameters, async modes, caching, cost), the description is thorough. It explains cost, caching, async vs sync, residential fetching, and idempotency. An output schema exists (not shown here), so return-value details are covered. Nothing an agent needs to invoke it correctly is missing.

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?

The input schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides; it adds context on cost and behavior, but that's not tied to individual parameters. It doesn't compensate for any gaps because there are none.

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?

The description states a specific verb ('Runs a real Google Lighthouse audit') and resource ('against the live page'), and enumerates the exact outputs (performance, accessibility, best-practices, SEO scores, Core Web Vitals). This clearly distinguishes it from siblings like fetch_html or capture_screenshot, which serve different purposes.

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

Usage Guidelines4/5

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

The description provides contextual guidance on when to use the tool: it mentions higher cost (2 credits) and longer runtime than other tools, and clarifies that it fetches the page itself, affecting cost when used inside scrape_url. However, it doesn't explicitly state 'use this when you need Lighthouse scores' or name alternative tools for comparison, so the guidance is implicit rather than prescriptive.

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

scrape_urlSeveral results from one page visit

Idempotent

Inspect

Exposes POST /scrape. Runs any subset of the other operations in one request, served from a single page visit where possible. Each operation is billed and stored exactly as the individual call would be, so this is not a discount — with one exception, and it is the reason to use it: a residential exit is charged per page VISIT, so several results off one visit pay the surcharge once.

Answers with one object keyed by operation, each entry carrying its own success and result, so a partial failure still returns everything that worked.

lighthouse does not share the visit — it runs its own audit on its own engine — so including it means two page fetches, and two surcharges when residential is on. So does a screenshot whose screenshot_options set viewport_width, viewport_height, device_scale_factor, dark_mode or block_ads: those change how the page loads, so the screenshot gets a visit of its own.

ParametersJSON 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.
`device`	No	Lighthouse only, when it is among the operations. Default mobile.
`fields`	No	extract only, and required when it is among the operations: the fields to fill, exactly as extract_data takes them.
`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.
`operations`	Yes	Which operations to run off this page.
`project_id`	Yes	Which project this request belongs to. From list_projects.
`pdf_options`	No	PDF only, when it is among the operations: how to print it, exactly as capture_pdf takes it.
`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.
`include_audits`	No	Lighthouse only: include the full per-audit detail. Default false.
`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.
`screenshot_options`	No	Screenshot only, when it is among the operations: how to take it, exactly as capture_screenshot takes it.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

summarize_pageSummarize a page

Idempotent

Inspect

Exposes POST /summarize. Returns a concise Markdown summary of the page's main content, with the navigation, ads and boilerplate left out.

The most expensive operation we sell, at 17 credits, because it runs a language model over the page. If YOU are the model that will read it, fetch_markdown gives you the whole page for 1 credit and you can summarize it yourself — this tool is for when the summary is the artefact being produced, not a step on the way to one.

ParametersJSON 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.
`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.
`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

ParametersJSON Schema

Name	Required	Description
No output parameters

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

11 tool updatesOct 12, 2026

Changedcapture_console_errors2 fields changed

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."