Read any page after its JavaScript runs: Markdown, screenshots, metadata, console errors and Lighthouse audits.
Scored across 17 tools
Each tool has a well-defined output medium (markdown, html, png, pdf, structured object, metadata) and the descriptions explicitly cross-reference rivals to steer selection, e.g. fetch_markdown vs fetch_html vs summarize_page. The only real overlaps are the batch tool scrape_url, which subsumes most operations, and the trio of LLM-backed content tools (summarize_page, extract_keywords, extract_data), which are distinct in output but close in intent.
All 17 names are snake_case verb_noun pairs with a small, predictable verb vocabulary (capture_, extract_, fetch_, get_, list_, run_, plus scrape_url/summarize_page/detect_technologies). The verb choice maps consistently to what the tool does: get_ for stored records, fetch_ for raw page representations, capture_ for rendered artifacts.
At 17 tools it sits just above the comfortable range, but the surface is genuinely multi-purpose (rendering, extraction, request history, project/quota administration) and each tool corresponds to a distinct endpoint with a distinct cost. Nothing looks like filler, though a few low-value entries (extract_keywords, get_usage) could arguably fold into others.
The surface covers the full lifecycle of a rendering/scraping API: discovery (list_projects, list_requests, get_usage), synchronous fetch in multiple formats, structured extraction, visual/document capture, batching via scrape_url, and async collection via get_result/get_request with cost and caching guidance. No obvious operational gap remains within the declared scope.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| auth_profile | No | Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles | |
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorld, idempotent, non-destructive and readOnly=false, so the safety profile is covered. The description adds genuinely non-redundant behavior: the request runs in headless Chrome, the result is limited to error/warn channels plus uncaught exceptions and rejections, and each call costs '1 credit' — a cost signal not present in the annotations. It does not mention the async/token-return behavior or result caching, but 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the operation then the exclusions, with no filler. The opening 'Exposes POST /console' is minor API-plumbing that an agent invoking the MCP tool does not need, but it costs only four words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 described, and the 10 parameters including a nested object are fully covered in the schema. The description supplies the remaining agent-facing facts — what the capture includes, what it excludes, and the per-call credit cost — leaving nothing material unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every one of the 10 parameters, including the nested page_options, is documented in the schema. The description contributes no additional detail about url, sync, max_age or auth_profile, so it sits at the baseline where the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Loads the page in headless Chrome and returns what it reported through console.error and console.warn'), and explicitly bounds scope with '(not console.log)', which separates it from generic fetch siblings like fetch_html and capture_screenshot. An agent can pick this out of the sibling list without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete use-case anchor — 'What you would open DevTools for: broken third-party scripts and client-side errors you cannot reproduce locally' — which tells the agent the situation that selects this tool. It stops short of naming an alternative or a when-not-to-use condition beyond the console.log exclusion, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| auth_profile | No | Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles | |
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only/idempotent/destructive hints, and the description still adds real behavior the annotations cannot express: a flat cost of "1 credit, whichever options you use" and the rendering guarantee that JS, fonts, and lazy images are included. It does not touch async-vs-sync collection or reuse semantics, but those are documented 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, followed by cost, then use cases, then option groups — a sensible order. The "Exposes POST /pdf" lead-in is API-implementation detail an agent does not need, and the prose is slightly florid, but nothing is seriously wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, nested option objects, an output schema, and full annotation coverage, the description carries enough: what it produces, what it costs, and how the two option groups differ. Missing pieces (sync/get_result flow, auth_profile, max_age reuse) are all fully specified in the schema, so no gap is critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains every option in detail. The description's paragraph on pdf_options and page_options is essentially a paraphrase of that, adding only the conceptual split between print settings and page pre-processing. It correctly hints that page_options change the document itself, but names no parameter directly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A specific verb and resource: "Prints the whole rendered page to a PDF", with the rendering fidelity pinned down (JavaScript executed, web fonts, lazy images, headings as bookmarks). It clearly separates the tool's output medium from siblings like capture_screenshot or fetch_html, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is stated with concrete motivating cases — archiving a receipt, article, report, or terms "as they stood today". The implicit contrast with screenshot/extraction siblings is inferable from those cases, but there is no explicit when-not condition or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| auth_profile | No | Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles | |
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context the annotations cannot carry: '1 credit, whichever options you use' and the fact that JS executes and external assets load, which affects latency and fidelity. It omits the request-record side effect (results retrievable via get_request/list_requests) and the async token flow, though the schema covers the latter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then a compact two-sentence second paragraph that packs cost, fidelity and option groups without redundancy. The opening 'Exposes POST /screenshot' is arguably filler for an agent but is a single short clause, and the parenthetical lists stay tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is rightly omitted. The description covers fidelity, cost, the see-vs-read decision and both option groups, which is enough for an 11-parameter tool with nested objects. Minor gap: nothing tells the agent that results are recorded and retrievable later, which matters for the async default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in detail — baseline 3 applies. The description adds grouping value by summarizing the two nested objects as 'size it / encode it / restyle it' and 'wait for the page and take ads and cookie banners out of it', but contributes no syntax or semantics beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and artifact ('Captures the whole rendered page as a PNG') plus the fidelity guarantee ('JavaScript executed, web fonts and images included, exactly as a browser would draw it'). The line 'see a page rather than read it' implicitly separates it from the text-extraction siblings (fetch_html, fetch_markdown, scrape_url), but the nearest sibling, capture_pdf, is never named or contrasted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete use cases (layout, visual regressions, link previews, verifying an anti-bot page) and a clear selection rule: use it when you need to see rather than read the page. It stops short of explicit exclusions — it never says when to prefer capture_pdf, or that text tasks should go to fetch_markdown/scrape_url.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| auth_profile | No | Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles | |
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag the coarse profile (openWorld, idempotent, non-destructive), while the description adds two things they cannot convey: the page is rendered first so JS-injected technologies are caught, and the call costs 1 credit. It does not contradict the annotations — POST-ing a job that isn't destructive and is idempotent is consistent with readOnlyHint false, destructiveHint false, idempotentHint true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded paragraph that opens with the purpose, then the result contents, then rendering behavior and cost. It is dense but each clause adds value; only the long enumeration of technology categories and signal types is slightly padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an existing output schema and fully described parameters, the description covers the non-obvious pieces an agent needs: rendering before detection, fingerprint database scope, and credit cost. It stops short of advising on sync vs async or cached-result reuse, though those live in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Every parameter is already documented at 100% schema coverage, so the schema carries the semantics. The description adds no parameter-level detail beyond noting the rendering step (loosely tying to page_options), so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Detects what a page is built with') and enumerates the technology classes found (CMS, JS frameworks, analytics, CDN, payment providers, etc.), which clearly separates it from siblings like extract_metadata or fetch_html.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied clearly enough — you call this when you want a technology fingerprint of a URL — but there is no explicit guidance on when to prefer it over scrape_url, extract_metadata or run_lighthouse_audit, and no stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| auth_profile | No | Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles | |
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: a 24-credit charge per call, whole-page AI reading, and a strong guarantee that missing values come back null rather than being guessed. Annotations already cover open-world and idempotency, and the description does not contradict them, but it does not mention the async/sync split or result retrieval, which the schema carries instead.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core contract and the null guarantee, then use cases, then cost and the alternative — a sensible order. The enumerated type list largely repeats the schema enum and could be dropped without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with nested objects, an output schema and rich annotations, the description covers the mental model, cost, and the key sibling choice. Async/sync behavior, caching and webhook delivery are left entirely to the schema, which is acceptable given the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter, including types, nesting, labels and max_age. The description adds only two things beyond that: the result preserves key order, and the type list is restated (duplicating the schema enum). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Reads the page and fills an object YOU define' — and names the mechanism (POST /extract, AI model reading the page). It is immediately distinguishable from extract_metadata, which it explicitly positions against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete use cases (product details, prices, contact data, job listings, event dates, lists with attributes) and an explicit alternative with a condition: 'prefer extract_metadata when the standard metadata is all you need.' The cost note reinforces the routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| auth_profile | No | Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles | |
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint, non-readOnly and idempotent, so the bar is lower, but the description still adds genuinely useful behaviour: a fixed 15-credit price, the LLM-based ranking semantics of the output, and the cheaper sibling's cost for comparison. It does not restate anything the annotations cover and creates no contradiction with readOnlyHint=false given the credit charge. Async vs sync mechanics are left to 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with purpose and ranking semantics before cost and the alternative. 'Exposes POST /keywords' is the only near-dead weight, restating a transport detail most agents will not act on. Nothing else could be cut without losing routing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with a nested object and an output schema, the description covers what the tool produces, its cost, and when to prefer the cheap alternative — the remaining gaps (async collection, caching, webhooks) are fully documented in the schema. Only the boundary against the other extraction tools is unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including nested page_options, sync/async, max_age caching and idempotency_key, so the schema carries the parameter burden entirely. The description adds no parameter-level meaning of its own. Baseline 3 is correct when the schema is this complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns the 5–15 terms and phrases that best represent the page') and pins down the ranking method ('ranked by a language model, not by raw frequency'), which is exactly the differentiator an agent needs against extract_metadata or scrape_url. It also routes to fetch_markdown for the case where the agent will do its own reasoning, which distinguishes it from siblings without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use-something-else rule: if the agent intends to reason over the result itself, fetch_markdown at 1 credit is the better call than 15 credits here. That is concrete, cost-anchored guidance. It stops short of exclusions against other extraction siblings (extract_metadata, extract_data, summarize_page) where the boundary is left implicit via the 'As with summarize_page' analogy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| auth_profile | No | Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles | |
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (destructiveHint false, idempotentHint true, openWorldHint true), and the description adds genuinely non-redundant behavior: the page is rendered before reading so JS-injected values appear, missing values come back as null or empty lists, and the call costs 1 credit. It does not restate the sync/async default or caching, which live in the schema, but that is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded paragraph that leads with what is read and follows with the key set, then the rendering and null semantics and the cost. The long field enumeration is dense but earns its place by telling the agent what keys to expect; 'Exposes POST /meta' is the only mildly wasteful, implementation-facing clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter, nested-schema tool with an output schema, the description covers what the agent needs: what is extracted, that rendering happens, how absences are represented, and the credit cost. The remaining gap is routing guidance against the many sibling extraction tools, which is a usage concern rather than a completeness one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every one of the ten parameters, including the nested page_options, carries its own explanatory text. The description adds nothing about parameters, so the baseline 3 applies — the schema is doing all the work here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Reads everything a page declares about itself') and enumerates the exact output surface: Open Graph, Twitter cards, meta tags, JSON-LD, microdata, links. That enumeration effectively separates it from siblings like extract_keywords or fetch_html, but no sibling is ever named explicitly, so differentiation is inferred rather than declared.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the purpose — an agent can infer 'use this to get a page's declared metadata' but there is no explicit when-to-use, no when-not-to-use, and no pointer to alternatives such as extract_data or fetch_markdown. The mention that JavaScript-injected values are included hints at the case where fetch_html would be insufficient, but that contrast is never made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| auth_profile | No | Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles | |
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare openWorldHint and idempotentHint, and the description adds the material operational facts an agent needs: the page is JS-rendered and redirect-followed, and each call costs 1 credit. It does not itself explain the sync/async split or the free-cached-result behaviour, but those are fully covered by the sync, max_age and idempotency_key schema text, so no contradiction and only a small residual gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact paragraphs, front-loaded with what is returned and the cost, then the selection guidance. There is no filler, no restating of the title, and the sibling comparison closes the piece in a single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return format needs no explanation, and all 10 parameters are documented in-schema. Purpose, cost and the sibling routing are all covered; the only thing left implicit is when a caller should switch to async polling via get_result, which the sync parameter text carries instead.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with rich per-parameter prose covering caching, webhooks, residential surcharges and page_options, so the structured data does the heavy lifting. The description only adds the pricing anchor ('1 credit', 'costs the same' as fetch_markdown) and does not expand on any individual parameter, which is the expected baseline when the schema is this complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource ('Returns the page's HTML after JavaScript has run and redirects have been followed') and sharpens it with a contrast against curl's empty shell. The distinction from the sibling fetch_markdown is drawn explicitly in the same description, so an agent can choose 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives both sides of the decision: use this 'when you need the markup itself: a specific attribute, a script tag, a structured-data block,' and use fetch_markdown instead 'If you want to read the page's content,' noting the equal cost. That is explicit when-to-use, when-not-to-use, and a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| auth_profile | No | Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles | |
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real information beyond the annotations: cost of 1 credit, rendering engine, and the content-extraction behavior that removes nav/sidebars/cookie banners from the output. Annotations already cover idempotency, open-world and non-destructiveness, and the schema covers caching/webhook behavior, so the description's added value is mainly cost and output shape rather than exhaustive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the endpoint and the transformation, then the recommendation. Some promotional padding ("cheapest operation we sell", "says nothing extra") that is marginal but does carry cost-comparison information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and the input schema is rich, so the description only needs purpose, cost and the sibling comparison, all of which are present. What is missing is minor: nothing about the default sync behavior or the async get_result loop, though the schema covers both.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already fully documented in the schema. The description adds no parameter-level guidance (nothing on sync vs async, max_age reuse, or page_options) beyond what the schema states, which is the baseline case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete mechanism (headless Chrome render, main content converted to clean Markdown) and enumerates what is preserved versus dropped. It is clearly distinguishable from fetch_html, which it names directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Start here when you want to READ a page" gives an explicit default recommendation and steers away from fetch_html by explaining the DOM is larger and less informative. It stops short of stating the inverse rule (when to prefer fetch_html, e.g. needing raw markup or script content), so the routing is strong but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The token the original call returned. | |
| project_id | Yes | From list_projects. |
| 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 |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The token the original call returned. | |
| project_id | Yes | From list_projects. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, and the description still adds real behavioral context: results are retained 30 days, re-reads are free, and an unfinished request returns {"status": "processing"} rather than erroring. That last point is exactly the kind of retry guidance an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the endpoint and purpose, then the async-collection workflow, then the processing caveat. The enumeration of output forms is somewhat long but each item is informative and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is technically optional, yet the description still explains the async token workflow, retention, and the processing state — everything an agent needs to call this correctly and handle the non-final response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with only two parameters, both documented in the schema itself (token, project_id). The description explains where the token originates but adds no syntax or format detail beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Exposes GET /result/:token. Returns the result of a past request') and immediately clarifies the output forms, so an agent can distinguish it from get_request and list_requests 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger condition — any tool called without sync: true returns a token, and this converts that token into the result — plus the 30-day re-read window. It does not name a sibling alternative or state a when-not-to-use case, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| credits | Yes | |
| plan_name | No | |
| concurrency_limit | No | |
| cost_per_operation | Yes | |
| residential_surcharge_per_page_visit | No |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| projects | Yes | |
| organization | Yes |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| offset | Yes | |
| requests | Yes | |
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description clears a lower bar and then exceeds it: it discloses that results are cacheable via tokens, that a /scrape collapses into a single entry whose children are internal, and that label filtering is an AND across exact values. These are genuine behavioral traits an agent cannot recover from the schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short paragraphs, front-loaded with what is returned and why it matters, then dedup guidance, then the scrape exception, then filtering. No sentence is filler and each adds a distinct fact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and the description covers the remaining agent-facing questions: why to call it, how entries are shaped (token, scrape aggregation), and how filtering behaves. Nothing needed 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter including limit, offset, and the operation enum is already documented. The description's label clause ('every key given must match its value exactly') restates the schema's own 'all of these labels... matched exactly', adding no new syntax or format detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (a project's requests), its ordering (newest first), and what each entry carries (a token), which is enough to separate it from get_request, get_result, and list_projects. It stops short of an explicit verb or naming a sibling, so it is clear but not maximally differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the exact moment to call this tool ('Look here before fetching a page') and names the alternative it plays against (get_result), with the condition for choosing it: reuse an existing token and the result costs nothing. It also explains how labels narrow the list, so nothing about when/when-not to use it is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| auth_profile | No | Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles | |
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly=false, openWorld=true, idempotent=true and non-destructive. The description adds real behavior beyond that: each operation is billed and stored as if called alone, results come back keyed by operation with per-entry success so partial failures still return everything that worked, and certain option combinations trigger a second page fetch and a second surcharge.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight paragraphs that front-load the core idea and then the economics, followed by the exceptions. The opening 'Exposes POST /scrape' is a redundant implementation detail, and the long dash-laden sentence about screenshot options is denser than it needs to be, but nearly every sentence carries decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter tool with nested option objects and an output schema, the description covers what structured fields cannot: why to batch, how billing and caching interact, and what happens on partial failure. Return shape is delegated to the output schema, which is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so individual parameters are already documented; the description's value is cross-parameter semantics the schema cannot express — that residential billing is per visit, and that screenshot_options viewport_width, viewport_height, device_scale_factor, dark_mode and block_ads force a separate visit. It does not touch sync, max_age or idempotency_key, but those are fully described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: runs any subset of the other operations in one request against a single page. It explicitly distinguishes itself from the sibling operation tools (lighthouse, capture_screenshot) and explains the batching role that no sibling fills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit reason to choose this over individual calls (residential surcharge is charged per page visit, so bundling pays it once) and explicitly states it is not a discount otherwise. It also names the two cases where batching does not apply — lighthouse and screenshots with viewport/dark_mode/block_ads options — which is exactly the when-not guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| auth_profile | No | Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles | |
| 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. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=true and openWorldHint=true, but the description adds the economics (17 credits, model-run) and the output artefact shape (Markdown summary), which no structured field conveys. It does not contradict the annotations — a charged, recorded request justifies readOnlyHint=false even though nothing is mutated. It stops short of discussing failure modes or latency, keeping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight paragraphs, front-loaded with the operation and its return format, then the cost caveat, then the alternative. Nothing is redundant with the schema and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and all ten parameters are documented, so the description only needs to supply positioning and cost — which it does. It omits the async/get_result handoff, but that path is fully described inside the sync parameter, so no critical gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so url, sync, max_age, labels, report_to, residential, auth_profile, page_options and idempotency_key are all documented in the schema itself. The description adds no parameter-level detail beyond the credit mention, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — returns a concise Markdown summary of a page's main content with nav, ads and boilerplate removed — and names the backing endpoint POST /summarize. A sentence later it explicitly separates itself from fetch_markdown, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use and when-not-to-use guidance: if the calling agent is the reader, fetch_markdown at 1 credit is preferable; this tool is for when the summary is the deliverable. The decision rule and the alternative are both named outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
capture_console_errors1 field changedInput schema / properties / auth_profileAdded value: +{
+ "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
+ "type": "string"
+}capture_pdf1 field changedInput schema / properties / auth_profileAdded value: +{
+ "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
+ "type": "string"
+}capture_screenshot1 field changedInput schema / properties / auth_profileAdded value: +{
+ "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
+ "type": "string"
+}detect_technologies1 field changedInput schema / properties / auth_profileAdded value: +{
+ "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
+ "type": "string"
+}extract_data1 field changedInput schema / properties / auth_profileAdded value: +{
+ "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
+ "type": "string"
+}extract_keywords1 field changedInput schema / properties / auth_profileAdded value: +{
+ "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
+ "type": "string"
+}extract_metadata1 field changedInput schema / properties / auth_profileAdded value: +{
+ "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
+ "type": "string"
+}fetch_html1 field changedInput schema / properties / auth_profileAdded value: +{
+ "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
+ "type": "string"
+}fetch_markdown1 field changedInput schema / properties / auth_profileAdded value: +{
+ "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
+ "type": "string"
+}scrape_url1 field changedInput schema / properties / auth_profileAdded value: +{
+ "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
+ "type": "string"
+}summarize_page1 field changedInput schema / properties / auth_profileAdded value: +{
+ "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
+ "type": "string"
+}capture_screenshot1 field changedInput schema / properties / screenshot_options / properties / styles / descriptionPrevious value: -"CSS to inject into the page before capturing."New value: +"CSS to inject into the page before capturing, up to 20000 characters."scrape_url1 field changedInput schema / properties / screenshot_options / properties / styles / descriptionPrevious value: -"CSS to inject into the page before capturing."New value: +"CSS to inject into the page before capturing, up to 20000 characters."capture_console_errors2 fields changedInput schema / properties / page_options / descriptionPrevious 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."Input schema / properties / page_options / properties / scroll_to_bottomAdded 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"
+}capture_pdf2 fields changedInput schema / properties / page_options / descriptionPrevious 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."Input schema / properties / page_options / properties / scroll_to_bottomAdded 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"
+}capture_screenshot2 fields changedInput schema / properties / page_options / descriptionPrevious 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."Input schema / properties / page_options / properties / scroll_to_bottomAdded 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"
+}detect_technologies2 fields changedInput schema / properties / page_options / descriptionPrevious 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."Input schema / properties / page_options / properties / scroll_to_bottomAdded 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"
+}extract_data2 fields changedInput schema / properties / page_options / descriptionPrevious 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."Input schema / properties / page_options / properties / scroll_to_bottomAdded 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"
+}extract_keywords2 fields changedInput schema / properties / page_options / descriptionPrevious 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."Input schema / properties / page_options / properties / scroll_to_bottomAdded 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"
+}extract_metadata2 fields changedInput schema / properties / page_options / descriptionPrevious 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."Input schema / properties / page_options / properties / scroll_to_bottomAdded 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"
+}fetch_html2 fields changedInput schema / properties / page_options / descriptionPrevious 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."Input schema / properties / page_options / properties / scroll_to_bottomAdded 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"
+}fetch_markdown2 fields changedInput schema / properties / page_options / descriptionPrevious 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."Input schema / properties / page_options / properties / scroll_to_bottomAdded 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"
+}scrape_url2 fields changedInput schema / properties / page_options / descriptionPrevious 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."Input schema / properties / page_options / properties / scroll_to_bottomAdded 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"
+}summarize_page2 fields changedInput schema / properties / page_options / descriptionPrevious 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."Input schema / properties / page_options / properties / scroll_to_bottomAdded 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"
+}capture_console_errors1 field changedInput schema / properties / page_options / properties / block_popupsAdded value: +{
+ "description": "Remove newsletter, app-install and promotional popups laid over the page.",
+ "type": "boolean"
+}capture_pdfcapture_screenshot1 field changedInput schema / properties / page_options / properties / block_popupsAdded value: +{
+ "description": "Remove newsletter, app-install and promotional popups laid over the page.",
+ "type": "boolean"
+}detect_technologiesextract_dataextract_keywords1 field changedInput schema / properties / page_options / properties / block_popupsAdded value: +{
+ "description": "Remove newsletter, app-install and promotional popups laid over the page.",
+ "type": "boolean"
+}extract_metadata1 field changedInput schema / properties / page_options / properties / block_popupsAdded value: +{
+ "description": "Remove newsletter, app-install and promotional popups laid over the page.",
+ "type": "boolean"
+}fetch_html1 field changedInput schema / properties / page_options / properties / block_popupsAdded value: +{
+ "description": "Remove newsletter, app-install and promotional popups laid over the page.",
+ "type": "boolean"
+}fetch_markdown1 field changedInput schema / properties / page_options / properties / block_popupsAdded value: +{
+ "description": "Remove newsletter, app-install and promotional popups laid over the page.",
+ "type": "boolean"
+}get_result1 field changedOutput schema / anyOfPrevious value: -[
- {
- "properties": {
- "markdown": {
- "description": "The page's main content as Markdown.",
- "type": "string"
- }
- },
- "required": [
- "markdown"
- ],
- "type": "object"
- },
- {
- "properties": {
- "html": {
- "description": "The rendered HTML.",
- "type": "string"
- }
- },
- "required": [
- "html"
- ],
- "type": "object"
- },
- {
- "properties": {
- "summary": {
- "description": "A Markdown summary of the page.",
- "type": "string"
- }
- },
- "required": [
- "summary"
- ],
- "type": "object"
- },
- {
- "properties": {
- "keywords": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "keywords"
- ],
- "type": "object"
- },
- {
- "properties": {
- "entries": {
- "items": {
- "properties": {
- "text": {
- "type": "string"
- },
- "type": {
- "enum": [
- "error",
- "warning",
- "exception"
- ],
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "entries"
- ],
- "type": "object"
- },
- {
- "properties": {
- "mime_type": {
- "description": "The image's type. The image itself is the image content block.",
- "type": "string"
- },
- "result_url": {
- "description": "A link to the image that needs no key.",
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "mime_type"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "alternates": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "hreflang": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "hreflang",
- "url"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "authors": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "type": "string"
- },
- "profiles": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "url": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "name",
- "url",
- "profiles"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "canonical_url": {
- "description": "The page's canonical URL, absolute.",
- "type": [
- "string",
- "null"
- ]
- },
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "favicon_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "feeds": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "title": {
- "type": [
- "string",
- "null"
- ]
- },
- "type": {
- "type": [
- "string",
- "null"
- ]
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "url",
- "type",
- "title"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "final_url": {
- "description": "The address the page ended on, after its redirects.",
- "type": [
- "string",
- "null"
- ]
- },
- "generator": {
- "type": [
- "string",
- "null"
- ]
- },
- "icons": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "rel": {
- "type": "string"
- },
- "sizes": {
- "type": [
- "string",
- "null"
- ]
- },
- "type": {
- "type": [
- "string",
- "null"
- ]
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "url",
- "rel",
- "sizes",
- "type"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "image": {
- "additionalProperties": false,
- "properties": {
- "alt": {
- "type": [
- "string",
- "null"
- ]
- },
- "height": {
- "type": [
- "integer",
- "null"
- ]
- },
- "type": {
- "type": [
- "string",
- "null"
- ]
- },
- "url": {
- "type": "string"
- },
- "width": {
- "type": [
- "integer",
- "null"
- ]
- }
- },
- "required": [
- "url",
- "width",
- "height",
- "alt",
- "type"
- ],
- "type": [
- "object",
- "null"
- ]
- },
- "keywords": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "language": {
- "description": "ISO 639-1 code of the language the content is written in.",
- "type": [
- "string",
- "null"
- ]
- },
- "locale": {
- "description": "The most specific language tag the page declares for that language, BCP 47 (en-US).",
- "type": [
- "string",
- "null"
- ]
- },
- "logo_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "manifest_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "modified_at": {
- "description": "ISO 8601, as published_at.",
- "type": [
- "string",
- "null"
- ]
- },
- "oembed_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "open_graph": {
- "additionalProperties": false,
- "description": "The page's og: tags as declared.",
- "properties": {
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "image": {
- "type": [
- "string",
- "null"
- ]
- },
- "locale": {
- "type": [
- "string",
- "null"
- ]
- },
- "site_name": {
- "type": [
- "string",
- "null"
- ]
- },
- "title": {
- "type": [
- "string",
- "null"
- ]
- },
- "type": {
- "type": [
- "string",
- "null"
- ]
- },
- "url": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "title",
- "description",
- "image",
- "url",
- "type",
- "site_name",
- "locale"
- ],
- "type": "object"
- },
- "published_at": {
- "description": "ISO 8601: a date (2024-05-01) or a moment with its offset.",
- "type": [
- "string",
- "null"
- ]
- },
- "robots": {
- "additionalProperties": false,
- "properties": {
- "follow": {
- "type": "boolean"
- },
- "index": {
- "type": "boolean"
- }
- },
- "required": [
- "index",
- "follow"
- ],
- "type": "object"
- },
- "site_name": {
- "type": [
- "string",
- "null"
- ]
- },
- "structured_data_types": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "theme_color": {
- "type": [
- "string",
- "null"
- ]
- },
- "title": {
- "description": "The page's own title, without the site's name around it.",
- "type": [
- "string",
- "null"
- ]
- },
- "twitter": {
- "additionalProperties": false,
- "description": "The page's twitter: tags as declared.",
- "properties": {
- "card": {
- "type": [
- "string",
- "null"
- ]
- },
- "creator": {
- "type": [
- "string",
- "null"
- ]
- },
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "image": {
- "type": [
- "string",
- "null"
- ]
- },
- "site": {
- "type": [
- "string",
- "null"
- ]
- },
- "title": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "card",
- "site",
- "creator",
- "title",
- "description",
- "image"
- ],
- "type": "object"
- },
- "type": {
- "description": "The kind of page, as the page declares it.",
- "enum": [
- "article",
- "website",
- "profile",
- "book",
- "product",
- "video",
- "music",
- "place",
- "event",
- "recipe",
- null
- ],
- "type": [
- "string",
- "null"
- ]
- },
- "video": {
- "additionalProperties": false,
- "properties": {
- "height": {
- "type": [
- "integer",
- "null"
- ]
- },
- "type": {
- "type": [
- "string",
- "null"
- ]
- },
- "url": {
- "type": "string"
- },
- "width": {
- "type": [
- "integer",
- "null"
- ]
- }
- },
- "required": [
- "url",
- "type",
- "width",
- "height"
- ],
- "type": [
- "object",
- "null"
- ]
- }
- },
- "required": [
- "final_url",
- "canonical_url",
- "title",
- "description",
- "site_name",
- "type",
- "language",
- "locale",
- "authors",
- "published_at",
- "modified_at",
- "image",
- "video",
- "favicon_url",
- "icons",
- "logo_url",
- "feeds",
- "keywords",
- "theme_color",
- "generator",
- "manifest_url",
- "robots",
- "open_graph",
- "twitter",
- "alternates",
- "oembed_url",
- "structured_data_types"
- ],
- "type": "object"
- },
- {
- "properties": {
- "audits": {
- "type": "object"
- },
- "categories": {
- "type": "object"
- },
- "device": {
- "type": "string"
- },
- "fetchTime": {
- "type": "string"
- },
- "metrics": {
- "type": "object"
- },
- "url": {
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "final_url": {
- "description": "The address the page ended on, after its redirects.",
- "type": [
- "string",
- "null"
- ]
- },
- "operations": {
- "additionalProperties": {
- "properties": {
- "cached": {
- "type": "boolean"
- },
- "error": {
- "type": "string"
- },
- "result": {},
- "success": {
- "type": "boolean"
- }
- },
- "type": "object"
- },
- "description": "One key per operation requested, in the order asked for.",
- "type": "object"
- },
- "url": {
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "labels": {
- "type": "object"
- },
- "status": {
- "const": "processing",
- "type": "string"
- },
- "token": {
- "type": "string"
- }
- },
- "required": [
- "token",
- "status"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "properties": {
+ "markdown": {
+ "description": "The page's main content as Markdown.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "markdown"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "html": {
+ "description": "The rendered HTML.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "html"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "summary": {
+ "description": "A Markdown summary of the page.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "summary"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "keywords"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "entries": {
+ "items": {
+ "properties": {
+ "text": {
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "error",
+ "warning",
+ "exception"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "entries"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "mime_type": {
+ "description": "The image's type. The image itself is the image content block.",
+ "type": "string"
+ },
+ "result_url": {
+ "description": "A link to the image that needs no key.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "mime_type"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "mime_type": {
+ "description": "Always application/pdf. The document itself is the resource content block.",
+ "type": "string"
+ },
+ "result_url": {
+ "description": "A link to the PDF that needs no key.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "mime_type"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "alternates": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "hreflang": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hreflang",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "authors": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "profiles": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "url",
+ "profiles"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "canonical_url": {
+ "description": "The page's canonical URL, absolute.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "favicon_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "feeds": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "type",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "final_url": {
+ "description": "The address the page ended on, after its redirects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "generator": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "icons": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "rel": {
+ "type": "string"
+ },
+ "sizes": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "rel",
+ "sizes",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "image": {
+ "additionalProperties": false,
+ "properties": {
+ "alt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "height": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "width": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "url",
+ "width",
+ "height",
+ "alt",
+ "type"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "language": {
+ "description": "ISO 639-1 code of the language the content is written in.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "locale": {
+ "description": "The most specific language tag the page declares for that language, BCP 47 (en-US).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "logo_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "manifest_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "modified_at": {
+ "description": "ISO 8601, as published_at.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "oembed_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "open_graph": {
+ "additionalProperties": false,
+ "description": "The page's og: tags as declared.",
+ "properties": {
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "image": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "locale": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "site_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "title",
+ "description",
+ "image",
+ "url",
+ "type",
+ "site_name",
+ "locale"
+ ],
+ "type": "object"
+ },
+ "published_at": {
+ "description": "ISO 8601: a date (2024-05-01) or a moment with its offset.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "robots": {
+ "additionalProperties": false,
+ "properties": {
+ "follow": {
+ "type": "boolean"
+ },
+ "index": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "index",
+ "follow"
+ ],
+ "type": "object"
+ },
+ "site_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "structured_data_types": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "theme_color": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "description": "The page's own title, without the site's name around it.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "twitter": {
+ "additionalProperties": false,
+ "description": "The page's twitter: tags as declared.",
+ "properties": {
+ "card": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "creator": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "image": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "site": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "card",
+ "site",
+ "creator",
+ "title",
+ "description",
+ "image"
+ ],
+ "type": "object"
+ },
+ "type": {
+ "description": "The kind of page, as the page declares it.",
+ "enum": [
+ "article",
+ "website",
+ "profile",
+ "book",
+ "product",
+ "video",
+ "music",
+ "place",
+ "event",
+ "recipe",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "video": {
+ "additionalProperties": false,
+ "properties": {
+ "height": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "width": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "url",
+ "type",
+ "width",
+ "height"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "final_url",
+ "canonical_url",
+ "title",
+ "description",
+ "site_name",
+ "type",
+ "language",
+ "locale",
+ "authors",
+ "published_at",
+ "modified_at",
+ "image",
+ "video",
+ "favicon_url",
+ "icons",
+ "logo_url",
+ "feeds",
+ "keywords",
+ "theme_color",
+ "generator",
+ "manifest_url",
+ "robots",
+ "open_graph",
+ "twitter",
+ "alternates",
+ "oembed_url",
+ "structured_data_types"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "final_url": {
+ "description": "The address the page ended on, after its redirects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "technologies": {
+ "description": "Every technology detected, most certain first.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "categories": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "confidence": {
+ "description": "How sure the detection is, 0–100. Most are 100.",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "cpe": {
+ "description": "The CPE 2.3 name, for looking the technology up in vulnerability databases.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "detected_by": {
+ "description": "Which signals gave it away: html, meta, headers, cookies, js, dom, script_src, scripts, css, text, url, xhr, cert_issuer, dns, robots. Empty for a technology only implied by another.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "implied_by": {
+ "description": "The detected technologies that imply this one (WordPress implies PHP).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "description": "The technology's name, e.g. WordPress.",
+ "type": "string"
+ },
+ "slug": {
+ "description": "A stable identifier for the technology, e.g. wordpress.",
+ "type": "string"
+ },
+ "version": {
+ "description": "The version, when the page gives it away.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "website": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "slug",
+ "version",
+ "confidence",
+ "categories",
+ "website",
+ "description",
+ "cpe",
+ "detected_by",
+ "implied_by"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "final_url",
+ "technologies"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": true,
+ "description": "One key per requested field, in the order requested. A value the page does not give is null.",
+ "type": "object"
+ },
+ {
+ "properties": {
+ "audits": {
+ "type": "object"
+ },
+ "categories": {
+ "type": "object"
+ },
+ "device": {
+ "type": "string"
+ },
+ "fetchTime": {
+ "type": "string"
+ },
+ "metrics": {
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "final_url": {
+ "description": "The address the page ended on, after its redirects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "operations": {
+ "additionalProperties": {
+ "properties": {
+ "cached": {
+ "type": "boolean"
+ },
+ "error": {
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "description": "One key per operation requested, in the order asked for.",
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "processing",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+]list_requests1 field changedInput schema / properties / operation / enumPrevious value: -[
- "html",
- "screenshot",
- "markdown",
- "meta",
- "summarize",
- "keywords",
- "lighthouse",
- "console",
- "scrape"
-]New value: +[
+ "html",
+ "screenshot",
+ "markdown",
+ "meta",
+ "summarize",
+ "keywords",
+ "lighthouse",
+ "console",
+ "technologies",
+ "pdf",
+ "extract",
+ "scrape"
+]scrape_url5 fields changedInput schema / properties / fieldsAdded value: +{
+ "description": "extract only, and required when it is among the operations: the fields to fill, exactly as extract_data takes them.",
+ "items": {
+ "properties": {
+ "description": {
+ "description": "What to take from the page. The more specific, the better.",
+ "type": "string"
+ },
+ "fields": {
+ "description": "For an object: its fields, shaped like this one.",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "items": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "object"
+ }
+ ],
+ "description": "For an array: what it holds — a type such as \"string\", or {\"type\": \"object\", \"fields\": [...]}."
+ },
+ "name": {
+ "description": "The key in the result: letters, digits and underscores.",
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "string",
+ "number",
+ "integer",
+ "boolean",
+ "date",
+ "datetime",
+ "url",
+ "email",
+ "object",
+ "array"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Input schema / properties / instructionsAdded value: +{
+ "description": "Optional guidance that applies to every field, e.g. \"prices in EUR\".",
+ "type": "string"
+}Input schema / properties / operations / items / enumPrevious value: -[
- "html",
- "screenshot",
- "markdown",
- "meta",
- "summarize",
- "keywords",
- "lighthouse",
- "console"
-]New value: +[
+ "html",
+ "screenshot",
+ "markdown",
+ "meta",
+ "summarize",
+ "keywords",
+ "lighthouse",
+ "console",
+ "technologies",
+ "pdf",
+ "extract"
+]Input schema / properties / page_options / properties / block_popupsAdded value: +{
+ "description": "Remove newsletter, app-install and promotional popups laid over the page.",
+ "type": "boolean"
+}Input schema / properties / pdf_optionsAdded value: +{
+ "description": "PDF only, when it is among the operations: how to print it, exactly as capture_pdf takes it.",
+ "properties": {
+ "landscape": {
+ "description": "Landscape orientation. Default false.",
+ "type": "boolean"
+ },
+ "margin": {
+ "description": "Margin on every side, 0 to 50 mm. Default 10.",
+ "type": "integer"
+ },
+ "media": {
+ "description": "print (default) uses the page's print stylesheet; screen prints it as a browser shows it.",
+ "enum": [
+ "print",
+ "screen"
+ ],
+ "type": "string"
+ },
+ "paper_size": {
+ "description": "The paper. Default a4.",
+ "enum": [
+ "letter",
+ "legal",
+ "tabloid",
+ "a3",
+ "a4",
+ "a5"
+ ],
+ "type": "string"
+ },
+ "print_background": {
+ "description": "Print background colours and images. Default true.",
+ "type": "boolean"
+ },
+ "scale": {
+ "description": "Scale of the page, 10 to 200 percent. Default 100.",
+ "type": "integer"
+ },
+ "single_page": {
+ "description": "One page as wide as the browser window and as tall as the whole document, instead of paper-sized sheets. Default false.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}summarize_page1 field changedInput schema / properties / page_options / properties / block_popupsAdded value: +{
+ "description": "Remove newsletter, app-install and promotional popups laid over the page.",
+ "type": "boolean"
+}extract_metadata1 field changedOutput schema / anyOfPrevious value: -[
- {
- "properties": {
- "additional_author_information": {
- "type": [
- "object",
- "null"
- ]
- },
- "author_name": {
- "type": [
- "string",
- "null"
- ]
- },
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "favicon_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "feed_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "language": {
- "type": [
- "string",
- "null"
- ]
- },
- "main_image_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "publication_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "title": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "labels": {
- "type": "object"
- },
- "status": {
- "const": "accepted",
- "type": "string"
- },
- "token": {
- "type": "string"
- }
- },
- "required": [
- "token",
- "status"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "alternates": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "hreflang": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hreflang",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "authors": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "profiles": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "url",
+ "profiles"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "canonical_url": {
+ "description": "The page's canonical URL, absolute.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "favicon_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "feeds": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "type",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "final_url": {
+ "description": "The address the page ended on, after its redirects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "generator": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "icons": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "rel": {
+ "type": "string"
+ },
+ "sizes": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "rel",
+ "sizes",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "image": {
+ "additionalProperties": false,
+ "properties": {
+ "alt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "height": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "width": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "url",
+ "width",
+ "height",
+ "alt",
+ "type"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "language": {
+ "description": "ISO 639-1 code of the language the content is written in.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "locale": {
+ "description": "The most specific language tag the page declares for that language, BCP 47 (en-US).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "logo_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "manifest_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "modified_at": {
+ "description": "ISO 8601, as published_at.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "oembed_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "open_graph": {
+ "additionalProperties": false,
+ "description": "The page's og: tags as declared.",
+ "properties": {
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "image": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "locale": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "site_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "title",
+ "description",
+ "image",
+ "url",
+ "type",
+ "site_name",
+ "locale"
+ ],
+ "type": "object"
+ },
+ "published_at": {
+ "description": "ISO 8601: a date (2024-05-01) or a moment with its offset.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "robots": {
+ "additionalProperties": false,
+ "properties": {
+ "follow": {
+ "type": "boolean"
+ },
+ "index": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "index",
+ "follow"
+ ],
+ "type": "object"
+ },
+ "site_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "structured_data_types": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "theme_color": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "description": "The page's own title, without the site's name around it.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "twitter": {
+ "additionalProperties": false,
+ "description": "The page's twitter: tags as declared.",
+ "properties": {
+ "card": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "creator": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "image": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "site": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "card",
+ "site",
+ "creator",
+ "title",
+ "description",
+ "image"
+ ],
+ "type": "object"
+ },
+ "type": {
+ "description": "The kind of page, as the page declares it.",
+ "enum": [
+ "article",
+ "website",
+ "profile",
+ "book",
+ "product",
+ "video",
+ "music",
+ "place",
+ "event",
+ "recipe",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "video": {
+ "additionalProperties": false,
+ "properties": {
+ "height": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "width": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "url",
+ "type",
+ "width",
+ "height"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "final_url",
+ "canonical_url",
+ "title",
+ "description",
+ "site_name",
+ "type",
+ "language",
+ "locale",
+ "authors",
+ "published_at",
+ "modified_at",
+ "image",
+ "video",
+ "favicon_url",
+ "icons",
+ "logo_url",
+ "feeds",
+ "keywords",
+ "theme_color",
+ "generator",
+ "manifest_url",
+ "robots",
+ "open_graph",
+ "twitter",
+ "alternates",
+ "oembed_url",
+ "structured_data_types"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "accepted",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+]get_request3 fields changedOutput schema / properties / final_urlAdded value: +{
+ "description": "Where the page ended up after its redirects.",
+ "type": "string"
+}Output schema / properties / meta / descriptionPrevious value: -"What the HTTP response headers would say: cache, cost, quota, result_url."New value: +"What the HTTP response headers would say: cache, cost, quota, result_url, final_url."Output schema / properties / operations / items / properties / final_urlAdded value: +{
+ "description": "Where the page ended up after its redirects.",
+ "type": "string"
+}get_result1 field changedOutput schema / anyOfPrevious value: -[
- {
- "properties": {
- "markdown": {
- "description": "The page's main content as Markdown.",
- "type": "string"
- }
- },
- "required": [
- "markdown"
- ],
- "type": "object"
- },
- {
- "properties": {
- "html": {
- "description": "The rendered HTML.",
- "type": "string"
- }
- },
- "required": [
- "html"
- ],
- "type": "object"
- },
- {
- "properties": {
- "summary": {
- "description": "A Markdown summary of the page.",
- "type": "string"
- }
- },
- "required": [
- "summary"
- ],
- "type": "object"
- },
- {
- "properties": {
- "keywords": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "required": [
- "keywords"
- ],
- "type": "object"
- },
- {
- "properties": {
- "entries": {
- "items": {
- "properties": {
- "text": {
- "type": "string"
- },
- "type": {
- "enum": [
- "error",
- "warning",
- "exception"
- ],
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
- }
- },
- "required": [
- "entries"
- ],
- "type": "object"
- },
- {
- "properties": {
- "mime_type": {
- "description": "The image's type. The image itself is the image content block.",
- "type": "string"
- },
- "result_url": {
- "description": "A link to the image that needs no key.",
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "mime_type"
- ],
- "type": "object"
- },
- {
- "properties": {
- "additional_author_information": {
- "type": [
- "object",
- "null"
- ]
- },
- "author_name": {
- "type": [
- "string",
- "null"
- ]
- },
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "favicon_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "feed_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "language": {
- "type": [
- "string",
- "null"
- ]
- },
- "main_image_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "publication_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "title": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "audits": {
- "type": "object"
- },
- "categories": {
- "type": "object"
- },
- "device": {
- "type": "string"
- },
- "fetchTime": {
- "type": "string"
- },
- "metrics": {
- "type": "object"
- },
- "url": {
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "operations": {
- "additionalProperties": {
- "properties": {
- "cached": {
- "type": "boolean"
- },
- "error": {
- "type": "string"
- },
- "result": {},
- "success": {
- "type": "boolean"
- }
- },
- "type": "object"
- },
- "description": "One key per operation requested, in the order asked for.",
- "type": "object"
- },
- "url": {
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "labels": {
- "type": "object"
- },
- "status": {
- "const": "processing",
- "type": "string"
- },
- "token": {
- "type": "string"
- }
- },
- "required": [
- "token",
- "status"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "properties": {
+ "markdown": {
+ "description": "The page's main content as Markdown.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "markdown"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "html": {
+ "description": "The rendered HTML.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "html"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "summary": {
+ "description": "A Markdown summary of the page.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "summary"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "keywords"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "entries": {
+ "items": {
+ "properties": {
+ "text": {
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "error",
+ "warning",
+ "exception"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "entries"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "mime_type": {
+ "description": "The image's type. The image itself is the image content block.",
+ "type": "string"
+ },
+ "result_url": {
+ "description": "A link to the image that needs no key.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "mime_type"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "alternates": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "hreflang": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hreflang",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "authors": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "profiles": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "url",
+ "profiles"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "canonical_url": {
+ "description": "The page's canonical URL, absolute.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "favicon_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "feeds": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "type",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "final_url": {
+ "description": "The address the page ended on, after its redirects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "generator": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "icons": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "rel": {
+ "type": "string"
+ },
+ "sizes": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "rel",
+ "sizes",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "image": {
+ "additionalProperties": false,
+ "properties": {
+ "alt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "height": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "width": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "url",
+ "width",
+ "height",
+ "alt",
+ "type"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "language": {
+ "description": "ISO 639-1 code of the language the content is written in.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "locale": {
+ "description": "The most specific language tag the page declares for that language, BCP 47 (en-US).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "logo_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "manifest_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "modified_at": {
+ "description": "ISO 8601, as published_at.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "oembed_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "open_graph": {
+ "additionalProperties": false,
+ "description": "The page's og: tags as declared.",
+ "properties": {
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "image": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "locale": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "site_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "title",
+ "description",
+ "image",
+ "url",
+ "type",
+ "site_name",
+ "locale"
+ ],
+ "type": "object"
+ },
+ "published_at": {
+ "description": "ISO 8601: a date (2024-05-01) or a moment with its offset.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "robots": {
+ "additionalProperties": false,
+ "properties": {
+ "follow": {
+ "type": "boolean"
+ },
+ "index": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "index",
+ "follow"
+ ],
+ "type": "object"
+ },
+ "site_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "structured_data_types": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "theme_color": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "description": "The page's own title, without the site's name around it.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "twitter": {
+ "additionalProperties": false,
+ "description": "The page's twitter: tags as declared.",
+ "properties": {
+ "card": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "creator": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "image": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "site": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "card",
+ "site",
+ "creator",
+ "title",
+ "description",
+ "image"
+ ],
+ "type": "object"
+ },
+ "type": {
+ "description": "The kind of page, as the page declares it.",
+ "enum": [
+ "article",
+ "website",
+ "profile",
+ "book",
+ "product",
+ "video",
+ "music",
+ "place",
+ "event",
+ "recipe",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "video": {
+ "additionalProperties": false,
+ "properties": {
+ "height": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "width": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "url",
+ "type",
+ "width",
+ "height"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "final_url",
+ "canonical_url",
+ "title",
+ "description",
+ "site_name",
+ "type",
+ "language",
+ "locale",
+ "authors",
+ "published_at",
+ "modified_at",
+ "image",
+ "video",
+ "favicon_url",
+ "icons",
+ "logo_url",
+ "feeds",
+ "keywords",
+ "theme_color",
+ "generator",
+ "manifest_url",
+ "robots",
+ "open_graph",
+ "twitter",
+ "alternates",
+ "oembed_url",
+ "structured_data_types"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "audits": {
+ "type": "object"
+ },
+ "categories": {
+ "type": "object"
+ },
+ "device": {
+ "type": "string"
+ },
+ "fetchTime": {
+ "type": "string"
+ },
+ "metrics": {
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "final_url": {
+ "description": "The address the page ended on, after its redirects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "operations": {
+ "additionalProperties": {
+ "properties": {
+ "cached": {
+ "type": "boolean"
+ },
+ "error": {
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "description": "One key per operation requested, in the order asked for.",
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "processing",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+]list_requests1 field changedOutput schema / properties / requests / items / properties / final_urlAdded value: +{
+ "description": "Where the page ended up after its redirects.",
+ "type": "string"
+}scrape_url1 field changedOutput schema / anyOfPrevious value: -[
- {
- "properties": {
- "operations": {
- "additionalProperties": {
- "properties": {
- "cached": {
- "type": "boolean"
- },
- "error": {
- "type": "string"
- },
- "result": {},
- "success": {
- "type": "boolean"
- }
- },
- "type": "object"
- },
- "description": "One key per operation requested, in the order asked for.",
- "type": "object"
- },
- "url": {
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "labels": {
- "type": "object"
- },
- "status": {
- "const": "accepted",
- "type": "string"
- },
- "token": {
- "type": "string"
- }
- },
- "required": [
- "token",
- "status"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "properties": {
+ "final_url": {
+ "description": "The address the page ended on, after its redirects.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "operations": {
+ "additionalProperties": {
+ "properties": {
+ "cached": {
+ "type": "boolean"
+ },
+ "error": {
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "description": "One key per operation requested, in the order asked for.",
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "accepted",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+]capture_console_errors1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "anyOf": [
+ {
+ "properties": {
+ "entries": {
+ "items": {
+ "properties": {
+ "text": {
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "error",
+ "warning",
+ "exception"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "entries"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "accepted",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}capture_screenshot1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "anyOf": [
+ {
+ "properties": {
+ "mime_type": {
+ "description": "The image's type. The image itself is the image content block.",
+ "type": "string"
+ },
+ "result_url": {
+ "description": "A link to the image that needs no key.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "mime_type"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "accepted",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}extract_keywords1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "anyOf": [
+ {
+ "properties": {
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "keywords"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "accepted",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}extract_metadata1 field changedOutput schema / anyOfPrevious value: -[
- {
- "properties": {
- "additional_author_information": {
- "type": [
- "object",
- "null"
- ]
- },
- "author_name": {
- "type": [
- "string",
- "null"
- ]
- },
- "description": {
- "type": [
- "string",
- "null"
- ]
- },
- "favicon_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "feed_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "language": {
- "type": [
- "string",
- "null"
- ]
- },
- "main_image_url": {
- "type": [
- "string",
- "null"
- ]
- },
- "publication_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "title": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "labels": {
- "type": "object"
- },
- "status": {
- "const": "accepted",
- "type": "string"
- },
- "token": {
- "type": "string"
- }
- },
- "type": "object"
- }
-]New value: +[
+ {
+ "properties": {
+ "additional_author_information": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "author_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "favicon_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "feed_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "language": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "main_image_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "publication_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "accepted",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+]fetch_html1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "anyOf": [
+ {
+ "properties": {
+ "html": {
+ "description": "The rendered HTML.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "html"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "accepted",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}fetch_markdown1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "anyOf": [
+ {
+ "properties": {
+ "markdown": {
+ "description": "The page's main content as Markdown.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "markdown"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "accepted",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}get_result1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "anyOf": [
+ {
+ "properties": {
+ "markdown": {
+ "description": "The page's main content as Markdown.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "markdown"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "html": {
+ "description": "The rendered HTML.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "html"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "summary": {
+ "description": "A Markdown summary of the page.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "summary"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "keywords": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "keywords"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "entries": {
+ "items": {
+ "properties": {
+ "text": {
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "error",
+ "warning",
+ "exception"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "entries"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "mime_type": {
+ "description": "The image's type. The image itself is the image content block.",
+ "type": "string"
+ },
+ "result_url": {
+ "description": "A link to the image that needs no key.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "mime_type"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "additional_author_information": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "author_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "favicon_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "feed_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "language": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "main_image_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "publication_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "audits": {
+ "type": "object"
+ },
+ "categories": {
+ "type": "object"
+ },
+ "device": {
+ "type": "string"
+ },
+ "fetchTime": {
+ "type": "string"
+ },
+ "metrics": {
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "operations": {
+ "additionalProperties": {
+ "properties": {
+ "cached": {
+ "type": "boolean"
+ },
+ "error": {
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "description": "One key per operation requested, in the order asked for.",
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "processing",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}run_lighthouse_audit1 field changedOutput schema / anyOfPrevious value: -[
- {
- "properties": {
- "audits": {
- "type": "object"
- },
- "categories": {
- "type": "object"
- },
- "device": {
- "type": "string"
- },
- "fetchTime": {
- "type": "string"
- },
- "metrics": {
- "type": "object"
- },
- "url": {
- "type": "string"
- }
- },
- "type": "object"
- },
- {
- "properties": {
- "labels": {
- "type": "object"
- },
- "status": {
- "const": "accepted",
- "type": "string"
- },
- "token": {
- "type": "string"
- }
- },
- "type": "object"
- }
-]New value: +[
+ {
+ "properties": {
+ "audits": {
+ "type": "object"
+ },
+ "categories": {
+ "type": "object"
+ },
+ "device": {
+ "type": "string"
+ },
+ "fetchTime": {
+ "type": "string"
+ },
+ "metrics": {
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "accepted",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+]scrape_url1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "anyOf": [
+ {
+ "properties": {
+ "operations": {
+ "additionalProperties": {
+ "properties": {
+ "cached": {
+ "type": "boolean"
+ },
+ "error": {
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "description": "One key per operation requested, in the order asked for.",
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "accepted",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}summarize_page1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "anyOf": [
+ {
+ "properties": {
+ "summary": {
+ "description": "A Markdown summary of the page.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "summary"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "accepted",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "status"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}capture_console_errorsconsole_logsextract_metadata1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "anyOf": [
+ {
+ "properties": {
+ "additional_author_information": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "author_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "favicon_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "feed_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "language": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "main_image_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "publication_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "properties": {
+ "labels": {
+ "type": "object"
+ },
+ "status": {
+ "const": "accepted",
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}get_request1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "properties": {
+ "async": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "credits": {
+ "type": "integer"
+ },
+ "duration_ms": {
+ "type": "integer"
+ },
+ "finished_at": {
+ "type": "string"
+ },
+ "labels": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "max_age": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "meta": {
+ "description": "What the HTTP response headers would say: cache, cost, quota, result_url.",
+ "type": "object"
+ },
+ "operation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "operations": {
+ "items": {
+ "properties": {
+ "created_at": {
+ "type": "string"
+ },
+ "credits": {
+ "type": "integer"
+ },
+ "duration_ms": {
+ "type": "integer"
+ },
+ "finished_at": {
+ "type": "string"
+ },
+ "labels": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "operation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "served_from_cache": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "status": {
+ "type": "string"
+ },
+ "success": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "token": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "url",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "outcome": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "report_to": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "request_options": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "served_from_cache": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "status": {
+ "type": "string"
+ },
+ "success": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "token": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "webhook_delivered_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "webhook_error": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "webhook_status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "token",
+ "url",
+ "status"
+ ],
+ "type": "object"
+}get_usage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "properties": {
+ "concurrency_limit": {
+ "type": "integer"
+ },
+ "cost_per_operation": {
+ "additionalProperties": {
+ "type": "integer"
+ },
+ "type": "object"
+ },
+ "credits": {
+ "properties": {
+ "limit": {
+ "description": "A number, or \"unlimited\".",
+ "type": [
+ "integer",
+ "string"
+ ]
+ },
+ "remaining": {
+ "description": "A number, or \"unlimited\".",
+ "type": [
+ "integer",
+ "string"
+ ]
+ },
+ "resets_at": {
+ "type": "string"
+ },
+ "used": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "plan": {
+ "type": "string"
+ },
+ "plan_name": {
+ "type": "string"
+ },
+ "residential_surcharge_per_page_visit": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "plan",
+ "credits",
+ "cost_per_operation"
+ ],
+ "type": "object"
+}lighthouse_auditlist_projects1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "properties": {
+ "organization": {
+ "type": "string"
+ },
+ "projects": {
+ "items": {
+ "properties": {
+ "default_webhook_url": {
+ "type": "string"
+ },
+ "id": {
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "requests_last_30_days": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "organization",
+ "projects"
+ ],
+ "type": "object"
+}list_requests1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "properties": {
+ "offset": {
+ "type": "integer"
+ },
+ "project_id": {
+ "type": "integer"
+ },
+ "requests": {
+ "items": {
+ "properties": {
+ "created_at": {
+ "type": "string"
+ },
+ "credits": {
+ "type": "integer"
+ },
+ "duration_ms": {
+ "type": "integer"
+ },
+ "finished_at": {
+ "type": "string"
+ },
+ "labels": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "operation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "served_from_cache": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "status": {
+ "type": "string"
+ },
+ "success": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "token": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "url",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "project_id",
+ "total",
+ "offset",
+ "requests"
+ ],
+ "type": "object"
+}run_lighthouse_auditcapture_screenshotconsole_logsextract_keywordsextract_metadatafetch_htmlfetch_markdownget_requestget_resultget_usagelighthouse_auditlist_projectslist_requestsscrape_urlsummarize_page
Add one secure layer between your agents and this server.