Scrape to markdown, map and crawl sites, drive a real browser. Pay per call, no API key, no signup.
Scored across 14 tools
Most tools target a distinct resource+action and the descriptions explicitly disambiguate the tricky pairs (web_crawl vs web_scrape_batch, web_map vs web_crawl). The main friction is the trio of near-identical status tools (web_crawl_status, web_batch_status, web_task_status) and the split between web_search_exa and web_task_start, which an agent must reason about but can resolve from descriptions.
All names share a clean `web_` snake_case prefix with a predictable resource_action shape (web_crawl_status, web_task_start, web_batch_status). Minor deviations: web_session_open/close invert to noun_verb order, and web_search_exa embeds a vendor name that breaks the verb_noun pattern.
14 tools is well-scoped for a scraping, crawling and browser-control server, with each tool covering a distinct verb or lifecycle step. No obvious filler or redundancy in the surface.
The core lifecycle (scrape, batch, crawl, map, search, session open/act/close, task start/status/cancel, feedback) is well covered and symmetrical for jobs. However, since every description stresses API keys and credits, there is a notable gap: no tool to check account balance or credit spend, and no way to list existing sessions, batches or tasks beyond a jobId the agent must already hold.
Runs actions against an open session and returns the resulting state. Actions: {navigate}, {click:{ref}}, {type:{ref,text,clear}}, {select:{ref,value}}, {press}, {scroll}, {wait}, {back}. The ref is the one controls gave you. It stops at the first failure and tells you where. $0.0005 (0.25 credit) per action, plus requested outputs and any outstanding browser time. API key and credits required. Reference for the oassis API: https://oassis.dev/openapi.json
| Name | Required | Description | Default |
|---|---|---|---|
| No | Options for the `pdf` format: `format` (a4, letter, legal…), `landscape`, `printBackground`, `scale` 0.1 to 2. | ||
| url | No | Page to process. | |
| json | No | For the `json` format: a `prompt` describing what to pull out, a JSON `schema` to fill, or both. | |
| wait | No | When to consider the page loaded: `until` (load, domcontentloaded, networkidle0, networkidle2), `selector` to wait for, `timeout` in ms. | |
| block | No | What not to load, which makes a render faster and cheaper. `resourceTypes` takes image, font, stylesheet, media… and `urlPatterns` are regular expressions, not globs: `\.svg$`, not `*.svg`. | |
| links | No | Options for the `links` format: `visibleOnly`, `excludeExternal` to keep only internal links. | |
| maxAge | No | Accept an answer up to this many milliseconds old. A cache hit costs $0.0002 instead of the format price. Leave it out to force a fresh render. | |
| actions | Yes | What to do, in order: click, type, select, scroll, hover, press, navigate, wait. One to twenty-five per call. | |
| formats | No | Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt` or `json.schema`. | |
| request | No | How to make the request: `headers`, `cookies`, `userAgent`, and `auth` for basic authentication. | |
| binaryAs | No | How a screenshot or a PDF comes back. `base64` is the only value today. | base64 |
| controls | No | Options for the `controls` format: `visibleOnly`, and `limit` (1 to 1000) to cut the map. | |
| viewport | No | The window to render in: `width`, `height`, `deviceScaleFactor`. | |
| selectors | No | CSS selectors for the `elements` format. | |
| sessionId | Yes | The session to act on, from `web_session_open`. | |
| screenshot | No | Options for the `screenshot` format: `fullPage` for the whole page, `type` (png, jpeg, webp), `quality` 1-100 (not with png), `omitBackground`, `selector` to capture one element, and its own `viewport`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnlyHint false, openWorldHint true, idempotentHint false, destructiveHint false) by disclosing failure semantics ('stops at the first failure and tells you where'), per-action pricing ($0.0005 plus outputs and browser time), and auth/billing prerequisites (API key and credits required). These are exactly the operational facts an agent needs before committing to a paid, non-idempotent call.
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-loads purpose, then action grammar, then failure behavior, then cost/auth. Every sentence carries weight, though the trailing API-reference URL and credit note read slightly like boilerplate appended to the end.
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 16-parameter tool with no output schema, the description covers actions, ref provenance, failure behavior, cost, and auth. The one gap is the return value: 'returns the resulting state' is vague where there is no output schema to fall back on, so the agent cannot tell what shape 'state' takes.
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 baseline is 3, but the description adds real meaning beyond the schema by explaining that `ref` is the identifier handed out by the `controls` format — a cross-tool coupling the schema never states. It also enumerates the action shapes verbatim (though the schema's `actions` list mentions 'hover', which the description omits).
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 — 'Runs actions against an open session' — and enumerates the exact action types (navigate, click, type, select, press, scroll, wait, back). It implicitly distinguishes itself from web_session_open by scoping to an already-open session, but it never names a sibling tool to contrast against, so it stops just short of full differentiation.
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 implied rather than stated: the agent learns refs must come from `controls` and that this operates on an open session, which signals the workflow. However, there is no explicit when-to-use/when-not guidance and no comparison to alternatives like web_task_start or web_scrape for similar page work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks a batch of scrapes: status, how many are done, and the results. Free for the owning account. Pass cancel: true to stop it.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The batch, from web_scrape_batch. | |
| limit | No | Results to return (default 50). | |
| cancel | No | Stop pending pages and refund pages that never started. An in-flight read may finish and is billed; failed reads are refunded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description nonetheless adds two useful behavioral facts beyond the schema: the call is 'Free for the owning account' (cost context) and passing cancel:true stops the batch, which explains why a status tool is not read-only.
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, front-loaded sentences with no padding: capability, cost, and the optional stop flag. Every sentence earns its place and the most important information comes first.
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 no output schema, the description correctly takes on the burden of describing the return values ('status, how many are done, and the results'), which is enough for an agent to know what to expect. It stops short of mentioning pagination or how limits interact with large result sets, a minor gap.
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 jobId, limit, and cancel are already fully documented in the schema, including the refund/billing nuance for cancel. The description's 'Pass cancel: true to stop it' only restates what the schema says, 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 ('Checks a batch of scrapes') and even enumerates what comes back: status, count of completed pages, and results. It implicitly separates itself from the crawl-status sibling by scoping to scrapes, but it never names web_scrape_batch or web_crawl_status directly, so an agent must infer the boundary.
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: the tool is clearly meant to be called after web_scrape_batch produced a jobId, and the cancel note hints at the stop-then-poll flow. There is no explicit when-to-use/when-not statement and no alternative tool is named for the polling case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Follows a site's links and reads every page. Returns a jobId; poll it with web_crawl_status. API key and credits required; limit controls the maximum pages charged. Use web_map first if you only need the urls. Reference for the oassis API: https://oassis.dev/openapi.json
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page to process. | |
| json | No | For the `json` format: a `prompt` describing what to pull out, a JSON `schema` to fill, or both. | |
| wait | No | When to consider the page loaded: `until` (load, domcontentloaded, networkidle0, networkidle2), `selector` to wait for, `timeout` in ms. | |
| block | No | What not to load, which makes a render faster and cheaper. `resourceTypes` takes image, font, stylesheet, media… and `urlPatterns` are regular expressions, not globs: `\.svg$`, not `*.svg`. | |
| limit | No | Pages this crawl may read, up to 200. Charged up front; what it does not read comes back. | |
| links | No | Options for the `links` format: `visibleOnly`, `excludeExternal` to keep only internal links. | |
| maxAge | No | Accept an answer up to this many milliseconds old. A cache hit costs $0.0002 instead of the format price. Leave it out to force a fresh render. | |
| formats | No | Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt` or `json.schema`. A screenshot or a PDF is not available here: every result is kept until you collect it. Ask for those one url at a time on web_scrape. | |
| request | No | How to make the request: `headers`, `cookies`, `userAgent`, and `auth` for basic authentication. | |
| binaryAs | No | How a screenshot or a PDF comes back. `base64` is the only value today. | base64 |
| controls | No | Options for the `controls` format: `visibleOnly`, and `limit` (1 to 1000) to cut the map. | |
| maxDepth | No | How far from the starting page to follow links. 0 reads only the starting page. | |
| viewport | No | The window to render in: `width`, `height`, `deviceScaleFactor`. | |
| selectors | No | CSS selectors for the `elements` format. | |
| excludePaths | No | Discard urls whose path contains one of these. Up to twenty. It wins over `includePaths`. | |
| includePaths | No | Keep only urls whose path contains one of these. Up to twenty. | |
| includeSubdomains | No | Treat subdomains of the same site as part of it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover only the safety profile (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); the description adds the asynchronous jobId/polling model, credential and credit requirements, and the charge/refund behavior of `limit`, none of which annotations convey. It stops short of failure/retry semantics or rate-limit behavior, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action, then job model, billing, and alternatives in four tight sentences; every sentence carries information. The OpenAPI reference link is minor overhead but plausibly useful for a 17-parameter tool.
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 objects and no output schema, the description supplies the essential mental model: async job + status polling, credit cost, and routing to web_map/web_scrape. Return-content detail is implicit via the status tool, which is adequate, though nothing is said about how crawled page results are retrieved or formatted.
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 documents all 17 parameters in detail (including `limit`, `maxDepth`, `formats`, `block`, path filters). The description only restates `limit`'s charging behavior, adding no syntax or format detail beyond the schema. 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+resource ('Follows a site's links and reads every page') and immediately differentiates from siblings: 'Use web_map first if you only need the urls' and the web_scrape pointer for screenshots/PDFs. An agent can distinguish this from web_scrape and web_map without opening any 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?
Explicitly names the follow-up tool ('poll it with web_crawl_status'), the alternative for URL-only needs (web_map), and the alternative for screenshot/PDF output (web_scrape). It also flags prerequisites ('API key and credits required'), leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks a crawl: status, pages read, discovered and still queued, and the pages themselves. Free for the owning account. Pass cancel: true to stop it.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The crawl, from web_crawl. | |
| limit | No | Pages to return (default 50). | |
| cancel | No | Stop pending pages and refund pages that never started. An in-flight read may finish and is billed; failed reads are refunded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false due to cancel, destructiveHint=false, idempotentHint=true), and the description adds non-annotated context: 'Free for the owning account' and the fact that cancel stops the crawl. It omits the refund/in-flight nuance, but that detail lives in the schema's cancel description, so the bar is met.
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 return contents, then the cost note, then the cancel trigger. Efficient and readable, with only minor overlap between 'Pass cancel: true' and the schema's cancel description.
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 no output schema, the description usefully enumerates what a caller receives (status, pages read, discovered, queued, pages themselves), and annotations plus the schema cover safety and parameters. Pagination defaults and polling cadence are left unstated, which is a minor gap.
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 jobId, limit, and cancel are already fully documented, including the refund semantics for cancel. The description only restates the cancel usage, adding no meaning beyond the schema. 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 ('Checks a crawl') and enumerates the returned fields, so an agent can distinguish it from the initiating sibling web_crawl. It stops short of naming web_crawl as the counterpart, leaving sibling differentiation partly to inference.
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 implies usage (poll a crawl started elsewhere) and gives one explicit action ('Pass cancel: true to stop it'), but never states when to use this versus web_batch_status, web_task_status, or when not to call it. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell us an answer was good or bad. FREE. Use it when a result is wrong — empty markdown, a control map missing a button, data that does not match the page — with the url or the jobId so it can be reproduced. It is the only way we learn that we read a page badly: our logs cannot tell that apart from a page that is simply like that. Reference for the oassis API: https://oassis.dev/openapi.json
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The page that came out wrong: usually the fastest way to reproduce it. | |
| route | No | Which tool or endpoint it is about, as you called it. | |
| comment | No | What you expected and what you got. | |
| verdict | Yes | Did the answer do the job or not. | |
| reference | No | The jobId or sessionId it happened on, so it can be looked up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations say not read-only, not idempotent, not destructive. The description adds that this is the only channel for the service to learn about bad reads and that logs cannot detect it. It does not state what happens after submission (no response/output schema), which keeps it below 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?
Front-loads the action and trigger examples well, but then runs long with the rationale about logs and the API-spec link. The sentences earn some of their place, though the behavioral motivation could be trimmed.
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?
Covers the trigger conditions, the reproduction identifiers, and why the feedback matters, sufficient for a 5-param report tool with no output schema. Missing only explicit confirmation of what the caller receives after submission.
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 documents every parameter. The description adds reproduction-orientation ('with the url or the jobId') but no syntax or field-level detail beyond the schema, 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 (report/feedback) and resource (an answer/result) and frames it as a quality-signal tool. It does not explicitly differentiate itself from siblings like web_act or web_scrape, but its purpose is clear enough that an agent can tell it apart from the retrieval 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?
Gives concrete conditions for use ('when a result is wrong — empty markdown, a control map missing a button, data that does not match the page') and mentions supplying url or jobId for reproduction. It does not name alternatives or say when not to use it, but the triggers are sharp.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every url of a site, fast and cheap: its sitemap plus, optionally, the links on the page. Use it BEFORE crawling, to see what is there and decide what is worth reading. 1 credit ($0.002) with includePage: false (no browser at all), 1.5 credits ($0.003) with the page. Reference for the oassis API: https://oassis.dev/openapi.json
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page to process. | |
| limit | No | Urls to return. Up to 5000. | |
| search | No | Keep only urls containing this text. | |
| includePage | No | Render the page too, to catch urls the sitemap does not list. `false` uses no browser at all, so it costs less: $0.002 against $0.003. | |
| excludePaths | No | Discard urls whose path contains one of these. Up to twenty. It wins over `includePaths`. | |
| includePaths | No | Keep only urls whose path contains one of these. Up to twenty. | |
| includeSubdomains | No | Treat subdomains of the same site as part of it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld, but the description adds the credit and dollar cost model, the browser-vs-no-browser distinction for includePage, and an API reference link. It stops short of describing the return shape or rate limits.
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?
Dense and front-loaded: capability first, then the decision heuristic, then cost, then the reference link. Every sentence carries information, though the cost figures appear twice (credit and dollar) without added nuance.
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 7-param read-only tool with full schema coverage and rich annotations, the description supplies the missing decision context and cost model. With no output schema, it partially compensates by saying what is returned (sitemap urls plus page links), though pagination and response format are not addressed.
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 all seven parameters are already documented, including the includePage cost tradeoff and the excludePaths-wins-over-includePaths precedence. The description only adds cost framing that the schema largely duplicates, 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 ('every url of a site') plus the exact mechanism (sitemap plus optional page links). It is clearly distinguishable from web_crawl and web_scrape siblings 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?
Explicitly tells the agent to use it 'BEFORE crawling, to see what is there and decide what is worth reading', which gives context and sequencing. It refers to crawling as a concept rather than naming the web_crawl sibling, so it falls just short of the explicit-alternative bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Processes a page and returns every output you ask for at once: markdown, html, links, screenshot, PDF, accessibility tree, elements by selector, AI-structured data, and controls (what can be clicked). One call, and a partial failure does not void the rest. From 1 credit ($0.002) per output. A url pointing at a PDF, Word, Excel or CSV file is converted to markdown instead, with no browser, for $0.002. Reference for the oassis API: https://oassis.dev/openapi.json
| Name | Required | Description | Default |
|---|---|---|---|
| No | Options for the `pdf` format: `format` (a4, letter, legal…), `landscape`, `printBackground`, `scale` 0.1 to 2. | ||
| url | No | Page to process. | |
| html | No | Raw HTML instead of `url`, for a page you already have. Nothing leaves for the network. | |
| json | No | For the `json` format: a `prompt` describing what to pull out, a JSON `schema` to fill, or both. | |
| wait | No | When to consider the page loaded: `until` (load, domcontentloaded, networkidle0, networkidle2), `selector` to wait for, `timeout` in ms. | |
| block | No | What not to load, which makes a render faster and cheaper. `resourceTypes` takes image, font, stylesheet, media… and `urlPatterns` are regular expressions, not globs: `\.svg$`, not `*.svg`. | |
| links | No | Options for the `links` format: `visibleOnly`, `excludeExternal` to keep only internal links. | |
| maxAge | No | Accept an answer up to this many milliseconds old. A cache hit costs $0.0002 instead of the format price. Leave it out to force a fresh render. | |
| formats | No | Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt` or `json.schema`. | |
| request | No | How to make the request: `headers`, `cookies`, `userAgent`, and `auth` for basic authentication. | |
| binaryAs | No | How a screenshot or a PDF comes back. `base64` is the only value today. | base64 |
| controls | No | Options for the `controls` format: `visibleOnly`, and `limit` (1 to 1000) to cut the map. | |
| viewport | No | The window to render in: `width`, `height`, `deviceScaleFactor`. | |
| selectors | No | CSS selectors for the `elements` format. | |
| screenshot | No | Options for the `screenshot` format: `fullPage` for the whole page, `type` (png, jpeg, webp), `quality` 1-100 (not with png), `omitBackground`, `selector` to capture one element, and its own `viewport`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, non-destructive semantics, and the description adds genuinely new operational context: per-output pricing from 1 credit ($0.002), partial-failure isolation, $0.0002 cache hits via maxAge vs a forced fresh render, and that document URLs are converted without a browser. It stops short of covering auth requirements, rate limits, or response shape, but it discloses far more behavior than the annotations 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?
The opening sentence front-loads the core capability and the output list, with cost and the document-conversion fallback immediately after; the API reference URL is appended cleanly at the end. Pricing details are repeated in a slightly dense way ('From 1 credit ($0.002) per output' plus 'for $0.002'), but nothing is wasted enough to hurt readability.
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 15-parameter, deeply nested tool with no output schema, the description covers the essential call contract: multiple formats in one response, which sub-options certain formats require, cost/caching behavior, and the non-browser document path — and it points to the OpenAPI reference for full detail. With no output schema to explain returns and 100% schema coverage on parameters, this is sufficient for correct invocation.
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 parameter (formats, json, wait, block, screenshot, selectors, maxAge) already carries its own schema prose, so the schema does the heavy lifting. The description reinforces a few cross-parameter dependencies (elements needs selectors, json needs json.prompt or json.schema, controls is the click map) but adds little syntax or format detail beyond the schema, matching the baseline 3.
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 gives a concrete verb and resource ('Processes a page and returns every output you ask for at once') and enumerates the concrete output formats (markdown, html, links, screenshot, PDF, accessibility tree, elements, json, controls), so an agent immediately knows the scope. However, it never names or contrasts against the close siblings such as web_crawl, web_map, or web_act, so differentiation relies on inference from the sibling names alone.
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 implied rather than stated: 'One call, and a partial failure does not void the rest' hints at batching many formats into a single request, and the PDF/Word/Excel/CSV branch tells the agent what happens when url points at a document. There is no explicit when-to-use-this-vs-web_crawl/web_map/web_act guidance and no stated prerequisites, so the guidance stays at the implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A batch OF SCRAPES: reads a list of urls YOU give it (2 to 50, from any sites) and returns a jobId. It discovers nothing on its own — for that use web_crawl. API key and credits required. Poll it with web_batch_status.
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | For the `json` format: a `prompt` describing what to pull out, a JSON `schema` to fill, or both. | |
| urls | Yes | The pages of this batch. Two to fifty, no duplicates: a batch charges per url. | |
| wait | No | When to consider the page loaded: `until` (load, domcontentloaded, networkidle0, networkidle2), `selector` to wait for, `timeout` in ms. | |
| block | No | What not to load, which makes a render faster and cheaper. `resourceTypes` takes image, font, stylesheet, media… and `urlPatterns` are regular expressions, not globs: `\.svg$`, not `*.svg`. | |
| links | No | Options for the `links` format: `visibleOnly`, `excludeExternal` to keep only internal links. | |
| maxAge | No | Accept an answer up to this many milliseconds old. A cache hit costs $0.0002 instead of the format price. Leave it out to force a fresh render. | |
| formats | No | Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt` or `json.schema`. A screenshot or a PDF is not available here: every result is kept until you collect it. Ask for those one url at a time on web_scrape. | |
| request | No | How to make the request: `headers`, `cookies`, `userAgent`, and `auth` for basic authentication. | |
| binaryAs | No | How a screenshot or a PDF comes back. `base64` is the only value today. | base64 |
| controls | No | Options for the `controls` format: `visibleOnly`, and `limit` (1 to 1000) to cut the map. | |
| viewport | No | The window to render in: `width`, `height`, `deviceScaleFactor`. | |
| selectors | No | CSS selectors for the `elements` format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds useful operational context: it returns a jobId, requires API key and credits, and must be polled via web_batch_status. It does not restate schema-level billing details, but the key behavior is covered.
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 four short sentences and is front-loaded with the core definition. Each sentence adds a distinct piece of information: batch semantics, no autonomous discovery, auth/billing requirements, and polling.
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 complex 12-parameter asynchronous batch tool, the description covers the essential call contract: caller-supplied URLs, jobId return, credit requirement, and polling. The remaining parameter detail is handled by the rich schema, though the description could say more about result collection if output were not otherwise described.
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 parameter meanings are already well documented in the schema. The description reinforces that URLs are caller-supplied and must be 2 to 50, but it adds no syntax or format details beyond the structured fields, so 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?
The description gives a specific verb and resource: it reads a list of URLs supplied by the caller and returns a jobId. It also distinguishes this from web_crawl by saying it discovers nothing on its own, so an agent can identify the tool 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?
It clearly states the batch-scrape use case and redirects discovery tasks to web_crawl, and it tells the agent to poll with web_batch_status. It does not explicitly compare against web_scrape for single-URL scrapes, so the guidance is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web with Exa's index: a query instead of a url, for when you do not know where to look. Returns title, url and a snippet per result. To read the pages, pass the urls to web_scrape_batch. The engine is named because the price is Exa's, passed through with no markup and read from its own payment challenge on every call — the quote is read at execution time and is not a guaranteed fixed price. API key and credits required over MCP.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results to return. Up to 50. | |
| query | Yes | What to search for. | |
| since | No | Only results published after this ISO date. | |
| domains | No | Only these domains, subdomains included: `example.com` also matches `docs.example.com`. | |
| snippets | No | Text alongside each result. On by default: a bare url is rarely enough. | |
| excludeDomains | No | Never these domains, subdomains included. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, destructiveHint=false, openWorldHint), and the description adds genuinely non-derivable behavior: API key and credits are required over MCP, pricing is Exa's pass-through with no markup read from its own payment challenge at execution time, and the quote is not a guaranteed fixed price. That cost/auth disclosure is exactly the kind of context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what it does and when to use it, then the return shape, then the operational caveats. The pricing sentence is long but carries load-bearing pricing/auth information; nothing is padding, though it could be split for scanability.
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 no output schema, the description supplies the return fields (title, url, snippet) itself, plus the auth/credits requirement and the non-fixed pricing caveat a caller needs before invoking. Nothing material is left for the agent to guess.
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 documents query, limit, since, domains, excludeDomains and snippets with their bounds. The description only re-states that a snippet accompanies each result, adding no syntax or filter semantics beyond the structured fields. 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 (search) and resource (the web via Exa's index) and explicitly contrasts the interaction model with a sibling: 'a query instead of a url, for when you do not know where to look.' It also names the return shape (title, url, snippet), so an agent can separate it from web_scrape and web_map without opening any 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 clear selection condition ('when you do not know where to look') and routes the agent onward: 'To read the pages, pass the urls to web_scrape_batch.' It does not state when NOT to use it (e.g. when the url is already known, or vs. web_map/web_crawl), so it stops short of an explicit alternatives matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Closes the browser session and stops its time. HTTP equivalent: POST /web/v1/session/{id}/close. No additional close fee; outstanding browser time is settled when applicable. If you do not close it, it closes itself after a minute without use.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The session to close, from web_session_open. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=false and idempotentHint=true, so the safety profile is covered. The description adds non-obvious behavior: billing semantics ('No additional close fee; outstanding browser time is settled') and the idle auto-close timeout, which an agent cannot infer from structured fields.
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 the action, with no padding. The HTTP-equivalent line is mildly extraneous for a chat agent but is compact and occasionally useful.
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 one-parameter lifecycle tool with no output schema and annotations already covering safety, the description supplies billing, idle-timeout, and endpoint context. It does not state the return shape, but with no output schema that is a minor gap.
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 single sessionId parameter is already documented in the schema as coming 'from web_session_open.' The description 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?
States a specific verb and resource ('Closes the browser session') that pairs cleanly with the sibling web_session_open, and the schema reference back to 'web_session_open' reinforces the lifecycle pairing. An agent can tell exactly what this does 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?
It gives implicit when-to-use guidance by noting the session 'closes itself after a minute without use,' which tells the agent closing is optional and only needed for immediate teardown. It does not name an explicit alternative or exclusion, but the auto-close caveat is real routing context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens a browser session and returns the map of controls. Opening costs 2.5 credits plus the requested outputs; the first minute is included. Further started minutes cost 2 credits with an account key. Use web_act to interact and web_session_close when done. API key and credits required. Reference: https://oassis.dev/openapi.json
| Name | Required | Description | Default |
|---|---|---|---|
| No | Options for the `pdf` format: `format` (a4, letter, legal…), `landscape`, `printBackground`, `scale` 0.1 to 2. | ||
| url | Yes | Page to process. | |
| json | No | For the `json` format: a `prompt` describing what to pull out, a JSON `schema` to fill, or both. | |
| wait | No | When to consider the page loaded: `until` (load, domcontentloaded, networkidle0, networkidle2), `selector` to wait for, `timeout` in ms. | |
| block | No | What not to load, which makes a render faster and cheaper. `resourceTypes` takes image, font, stylesheet, media… and `urlPatterns` are regular expressions, not globs: `\.svg$`, not `*.svg`. | |
| links | No | Options for the `links` format: `visibleOnly`, `excludeExternal` to keep only internal links. | |
| maxAge | No | Accept an answer up to this many milliseconds old. A cache hit costs $0.0002 instead of the format price. Leave it out to force a fresh render. | |
| formats | No | Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt` or `json.schema`. | |
| request | No | How to make the request: `headers`, `cookies`, `userAgent`, and `auth` for basic authentication. | |
| binaryAs | No | How a screenshot or a PDF comes back. `base64` is the only value today. | base64 |
| controls | No | Options for the `controls` format: `visibleOnly`, and `limit` (1 to 1000) to cut the map. | |
| viewport | No | The window to render in: `width`, `height`, `deviceScaleFactor`. | |
| selectors | No | CSS selectors for the `elements` format. | |
| screenshot | No | Options for the `screenshot` format: `fullPage` for the whole page, `type` (png, jpeg, webp), `quality` 1-100 (not with png), `omitBackground`, `selector` to capture one element, and its own `viewport`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true), so the description's added value is the cost model (2.5 credits plus requested outputs, first minute included, 2 credits per further started minute) and the API key/credit requirement. That is genuinely useful pre-invocation context, though it omits session lifetime/expiry 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?
Five short sentences, front-loaded with purpose, then cost, then next-step routing, then prerequisites and a reference link. No filler, though the two cost sentences could be tightened.
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 14-parameter tool with full schema coverage and no output schema, the description covers purpose, cost, auth needs, and workflow handoff, and states the return value (map of controls). Remaining gaps like session expiry are minor given the schema's completeness.
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 each parameter carries its own inline description (pdf, json, wait, block, screenshot, formats, etc.), so the schema already does the heavy lifting. The description only alludes to "the requested outputs" without adding syntax or format detail beyond the schema, matching the baseline of 3.
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: "Opens a browser session and returns the map of controls." It also distinguishes itself from siblings by naming the follow-up tools (web_act to interact, web_session_close when done), so an agent can place it in the workflow 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 clear lifecycle context: interact via web_act and close with web_session_close when done, plus API key/credit prerequisites. It does not address when NOT to open a session versus one-shot siblings like web_scrape, so the routing guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stops a task using its owning API key, or its legacy access_token. No new operations start. Cancellation is free; unused account credit reservations are released. Cancelling a finished task changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The task id, from web_task_start. | |
| access_token | No | Task-scoped access token returned by web_task_start; not an API key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish non-read-only, idempotent, non-destructive behavior, so the description earns credit for going further: cancellation is free, in-flight credit reservations are released, no new operations start, and the finished-task no-op case. It does not cover failure modes (invalid/expired token, unknown id) or the response shape.
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, front-loaded sentences; the action and auth mode come first, then cost and no-op behavior. No filler or restatement of the tool name.
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 no output schema, the description must stand alone, and it covers cost, credit release, and the no-op case well. It leaves error conditions and what the caller receives after a successful cancel unspecified, which for a mutation tool is a modest gap rather than a severe 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: the credential is the task's *owning* API key and the access_token is explicitly the legacy/alternate path. The schema alone labels access_token but does not convey the two-auth-mode relationship the description clarifies.
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 ('Stops a task') plus the ownership mechanism ('using its owning API key, or its legacy access_token'). This is unambiguous and immediately separable from siblings like web_task_start and web_task_status within the web_task_* family.
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 context is only implied. The description notes that cancelling a finished task 'changes nothing', which hints at when the call is pointless, but it never says when to cancel versus checking web_task_status first, nor names any alternative tool or prerequisite ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts a research task: a question answered by reading public pages, with sources, progress and cost. Requires an API key and credits. The maximum budget is reserved, actual execution cost is charged, and unused credits are released. Returns a task id: check it with web_task_status.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Only research is available: read public pages and answer. | research |
| task | Yes | What to find out, in plain words. Be specific about what to compare. | |
| urls | No | Pages to read first, up to 5. Public http or https urls only. | |
| limits | No | Bounds on cost, time and steps. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, open-world, non-idempotent behaviour, so the bar is lower; the description still adds real value by disclosing the credit model: max budget reserved up front, actual cost charged, unused credits released. It doesn't flag that this is asynchronous with no on-chain refund, though the schema's max_cost_usd note covers the transport nuance.
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 sentences, front-loaded with the purpose, then prerequisites, then billing and the return handle. No filler and nothing repeated from the schema.
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?
There is no output schema, and the description compensates by stating the return value (a task id) and where to check it (web_task_status), along with cost and auth expectations. For an async, credit-consuming tool this covers everything an agent needs before invoking.
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 each parameter (task, urls, mode, limits) is already documented with constraints and defaults. The description's budget-reservation sentence touches max_cost_usd but adds no syntax or constraint detail beyond what the schema states, 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 ('Starts a research task') and immediately defines the scope: a question answered by reading public pages, returning sources, progress and cost. This separates it from web_scrape, web_crawl and web_search_exa, which an agent can rule out 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?
Gives the operative context (a question to be answered from public pages) and an explicit prerequisite (API key and credits), plus routes follow-up to web_task_status. It stops short of saying when to prefer this over web_act or a plain scrape, so the exclusion side is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a task's status, progress, sources, limitations, result and billing. Only your own tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The task id, from web_task_start. | |
| access_token | No | Task-scoped access token returned by web_task_start; not an API key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds real behavioral context beyond that: an authorization scoping rule ('only your own tasks') and the fact that the response carries billing, limitations and sources, not just a status flag.
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 with zero filler. The purpose is front-loaded and the ownership restriction is appended where it reads naturally.
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 no output schema, the description carries the return-value burden and does so by naming the fields returned. Combined with 100% schema coverage and full annotations, an agent has what it needs to call and interpret this tool; only explicit sibling routing 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% with only two parameters, both documented in-schema, including the useful clarification that access_token is task-scoped rather than an API key. The description adds nothing further about parameters, 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 task's status') and enumerates the payload an agent gets back (progress, sources, limitations, result, billing). It distinguishes itself from web_batch_status by scoping to a single task, though it never names that sibling 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?
The clause 'Only your own tasks' establishes an ownership constraint, and the schema ties the id back to web_task_start, implying the polling-after-start flow. But there is no explicit when-to-use guidance or routing to alternatives such as web_batch_status or web_task_cancel.
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.
web_act2 fields changedInput schema / properties / binaryAs / enumPrevious value: -[
- "base64",
- "url"
-]New value: +[
+ "base64"
+]Input schema / properties / json / properties / modelRemoved value: -{
- "minLength": 1,
- "type": "string"
-}web_crawl2 fields changedInput schema / properties / binaryAs / enumPrevious value: -[
- "base64",
- "url"
-]New value: +[
+ "base64"
+]Input schema / properties / json / properties / modelRemoved value: -{
- "minLength": 1,
- "type": "string"
-}web_scrape2 fields changedInput schema / properties / binaryAs / enumPrevious value: -[
- "base64",
- "url"
-]New value: +[
+ "base64"
+]Input schema / properties / json / properties / modelRemoved value: -{
- "minLength": 1,
- "type": "string"
-}web_scrape_batch2 fields changedInput schema / properties / binaryAs / enumPrevious value: -[
- "base64",
- "url"
-]New value: +[
+ "base64"
+]Input schema / properties / json / properties / modelRemoved value: -{
- "minLength": 1,
- "type": "string"
-}web_session_open2 fields changedInput schema / properties / binaryAs / enumPrevious value: -[
- "base64",
- "url"
-]New value: +[
+ "base64"
+]Input schema / properties / json / properties / modelRemoved value: -{
- "minLength": 1,
- "type": "string"
-}web_batch_status1 field changedInput schema / properties / cancel / descriptionPrevious value: -"Stop the batch and refund what it did not read."New value: +"Stop pending pages and refund pages that never started. An in-flight read may finish and is billed; failed reads are refunded."web_crawl_status1 field changedInput schema / properties / cancel / descriptionPrevious value: -"Stop the crawl and refund what it did not read."New value: +"Stop pending pages and refund pages that never started. An in-flight read may finish and is billed; failed reads are refunded."web_map1 field changedInput schema / properties / includePage / descriptionPrevious value: -"Render the page too, to catch urls the sitemap does not list. `false` uses no browser at all, so it costs less: $0.001 against $0.0015."New value: +"Render the page too, to catch urls the sitemap does not list. `false` uses no browser at all, so it costs less: $0.002 against $0.003."web_task_cancel1 field changedInput schema / requiredPrevious value: -[
- "id",
- "access_token"
-]New value: +[
+ "id"
+]web_task_start1 field changedInput schema / properties / limits / properties / max_cost_usd / descriptionPrevious value: -"Most the task may cost, in USD. Execution budget. Free over MCP; charged as a fixed package over HTTP/x402. No automatic on-chain refund."New value: +"Most the task may cost, in USD. Execution budget. Reserved against account credits over MCP/HTTP with an API key; charged as a fixed package over HTTP/x402. No automatic on-chain refund."web_task_status1 field changedInput schema / requiredPrevious value: -[
- "id",
- "access_token"
-]New value: +[
+ "id"
+]web_task_cancel2 fields changedInput schema / properties / access_tokenAdded value: +{
+ "description": "Task-scoped access token returned by web_task_start; not an API key.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "id"
-]New value: +[
+ "id",
+ "access_token"
+]web_task_start1 field changedInput schema / properties / limits / properties / max_cost_usd / descriptionPrevious value: -"Most the task may cost, in USD. Reserved up front; the rest is returned."New value: +"Most the task may cost, in USD. Execution budget. Free over MCP; charged as a fixed package over HTTP/x402. No automatic on-chain refund."web_task_status2 fields changedInput schema / properties / access_tokenAdded value: +{
+ "description": "Task-scoped access token returned by web_task_start; not an API key.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "id"
-]New value: +[
+ "id",
+ "access_token"
+]web_task_cancelweb_task_startweb_task_statusweb_map1 field changedInput schema / properties / includePage / descriptionPrevious value: -"Render the page too, to catch urls the sitemap does not list. `false` uses no browser at all and costs a third."New value: +"Render the page too, to catch urls the sitemap does not list. `false` uses no browser at all, so it costs less: $0.001 against $0.0015."web_act37 fields changedInput schema / properties / actions / descriptionPrevious value: -"Actions, in order."New value: +"What to do, in order: click, type, select, scroll, hover, press, navigate, wait. One to twenty-five per call."Input schema / properties / actions / items / anyOfAdded value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "navigate": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "navigate"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "click": {
+ "additionalProperties": false,
+ "properties": {
+ "ref": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "selector": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "click"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "type": {
+ "additionalProperties": false,
+ "properties": {
+ "clear": {
+ "type": "boolean"
+ },
+ "ref": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "selector": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "text"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "select": {
+ "additionalProperties": false,
+ "properties": {
+ "ref": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "selector": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "value"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "select"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "press": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "press"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "scroll": {
+ "additionalProperties": false,
+ "properties": {
+ "by": {
+ "type": "number"
+ },
+ "to": {
+ "enum": [
+ "top",
+ "bottom"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "scroll"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "wait": {
+ "additionalProperties": false,
+ "properties": {
+ "ms": {
+ "maximum": 30000,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "selector": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "wait"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "back": {
+ "const": true,
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "back"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / actions / items / typeRemoved value: -"object"Input schema / properties / actions / maxItemsAdded value: +25Input schema / properties / actions / minItemsAdded value: +1Input schema / properties / binaryAsAdded value: +{
+ "default": "base64",
+ "description": "How a screenshot or a PDF comes back. `base64` is the only value today.",
+ "enum": [
+ "base64",
+ "url"
+ ],
+ "type": "string"
+}Input schema / properties / blockAdded value: +{
+ "additionalProperties": false,
+ "description": "What not to load, which makes a render faster and cheaper. `resourceTypes` takes image, font, stylesheet, media… and `urlPatterns` are regular expressions, not globs: `\\.svg$`, not `*.svg`.",
+ "properties": {
+ "resourceTypes": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "urlPatterns": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Input schema / properties / controlsAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `controls` format: `visibleOnly`, and `limit` (1 to 1000) to cut the map.",
+ "properties": {
+ "limit": {
+ "maximum": 1000,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "visibleOnly": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / formats / defaultAdded value: +[
+ "controls"
+]Input schema / properties / formats / descriptionPrevious value: -"Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt`."New value: +"Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt` or `json.schema`."Input schema / properties / formats / maxItemsAdded value: +9Input schema / properties / formats / minItemsAdded value: +1Input schema / properties / json / additionalPropertiesAdded value: +falseInput schema / properties / json / descriptionPrevious value: -"For the `json` format: `prompt` and/or `schema`."New value: +"For the `json` format: a `prompt` describing what to pull out, a JSON `schema` to fill, or both."Input schema / properties / json / properties / modelAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / json / properties / prompt / minLengthAdded value: +1Input schema / properties / json / properties / schema / additionalPropertiesAdded value: +{}Input schema / properties / linksAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `links` format: `visibleOnly`, `excludeExternal` to keep only internal links.",
+ "properties": {
+ "excludeExternal": {
+ "type": "boolean"
+ },
+ "visibleOnly": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / maxAge / maximumAdded value: +604800000Input schema / properties / maxAge / minimumAdded value: +0Input schema / properties / maxAge / typePrevious value: -"number"New value: +"integer"Input schema / properties / pdfAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `pdf` format: `format` (a4, letter, legal…), `landscape`, `printBackground`, `scale` 0.1 to 2.",
+ "properties": {
+ "format": {
+ "enum": [
+ "letter",
+ "legal",
+ "tabloid",
+ "ledger",
+ "a0",
+ "a1",
+ "a2",
+ "a3",
+ "a4",
+ "a5",
+ "a6"
+ ],
+ "type": "string"
+ },
+ "landscape": {
+ "type": "boolean"
+ },
+ "printBackground": {
+ "type": "boolean"
+ },
+ "scale": {
+ "maximum": 2,
+ "minimum": 0.1,
+ "type": "number"
+ }
+ },
+ "type": "object"
+}Input schema / properties / requestAdded value: +{
+ "additionalProperties": false,
+ "description": "How to make the request: `headers`, `cookies`, `userAgent`, and `auth` for basic authentication.",
+ "properties": {
+ "auth": {
+ "additionalProperties": false,
+ "properties": {
+ "password": {
+ "type": "string"
+ },
+ "username": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "username",
+ "password"
+ ],
+ "type": "object"
+ },
+ "cookies": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "httpOnly": {
+ "type": "boolean"
+ },
+ "name": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "secure": {
+ "type": "boolean"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "headers": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "userAgent": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Input schema / properties / screenshotAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `screenshot` format: `fullPage` for the whole page, `type` (png, jpeg, webp), `quality` 1-100 (not with png), `omitBackground`, `selector` to capture one element, and its own `viewport`.",
+ "properties": {
+ "fullPage": {
+ "type": "boolean"
+ },
+ "omitBackground": {
+ "type": "boolean"
+ },
+ "quality": {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "selector": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "png",
+ "jpeg",
+ "webp"
+ ],
+ "type": "string"
+ },
+ "viewport": {
+ "additionalProperties": false,
+ "properties": {
+ "deviceScaleFactor": {
+ "maximum": 3,
+ "minimum": 0.1,
+ "type": "number"
+ },
+ "height": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "width": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+}Input schema / properties / selectors / descriptionPrevious value: -"CSS selectors for `elements`."New value: +"CSS selectors for the `elements` format."Input schema / properties / selectors / items / minLengthAdded value: +1Input schema / properties / selectors / minItemsAdded value: +1Input schema / properties / sessionId / descriptionPrevious value: -"The one web_session_open returned."New value: +"The session to act on, from `web_session_open`."Input schema / properties / sessionId / minLengthAdded value: +1Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / viewportAdded value: +{
+ "additionalProperties": false,
+ "description": "The window to render in: `width`, `height`, `deviceScaleFactor`.",
+ "properties": {
+ "deviceScaleFactor": {
+ "maximum": 3,
+ "minimum": 0.1,
+ "type": "number"
+ },
+ "height": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "width": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+}Input schema / properties / wait / additionalPropertiesAdded value: +falseInput schema / properties / wait / descriptionPrevious value: -"When to consider the page loaded: `until`, `selector`, `timeout`."New value: +"When to consider the page loaded: `until` (load, domcontentloaded, networkidle0, networkidle2), `selector` to wait for, `timeout` in ms."Input schema / properties / wait / properties / selector / minLengthAdded value: +1Input schema / properties / wait / properties / timeout / maximumAdded value: +60000Input schema / properties / wait / properties / timeout / minimumAdded value: +100Input schema / properties / wait / properties / timeout / typePrevious value: -"number"New value: +"integer"web_batch_status1 field changedInput schema / properties / jobId / descriptionAdded value: +"The batch, from web_scrape_batch."web_crawl33 fields changedInput schema / properties / binaryAsAdded value: +{
+ "default": "base64",
+ "description": "How a screenshot or a PDF comes back. `base64` is the only value today.",
+ "enum": [
+ "base64",
+ "url"
+ ],
+ "type": "string"
+}Input schema / properties / blockAdded value: +{
+ "additionalProperties": false,
+ "description": "What not to load, which makes a render faster and cheaper. `resourceTypes` takes image, font, stylesheet, media… and `urlPatterns` are regular expressions, not globs: `\\.svg$`, not `*.svg`.",
+ "properties": {
+ "resourceTypes": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "urlPatterns": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Input schema / properties / controlsAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `controls` format: `visibleOnly`, and `limit` (1 to 1000) to cut the map.",
+ "properties": {
+ "limit": {
+ "maximum": 1000,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "visibleOnly": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / excludePaths / descriptionAdded value: +"Discard urls whose path contains one of these. Up to twenty. It wins over `includePaths`."Input schema / properties / excludePaths / items / minLengthAdded value: +1Input schema / properties / excludePaths / maxItemsAdded value: +20Input schema / properties / formats / descriptionPrevious value: -"Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt`."New value: +"Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt` or `json.schema`. A screenshot or a PDF is not available here: every result is kept until you collect it. Ask for those one url at a time on web_scrape."Input schema / properties / formats / items / enumPrevious value: -[
- "html",
- "markdown",
- "links",
- "screenshot",
- "pdf",
- "elements",
- "json",
- "accessibility",
- "controls"
-]New value: +[
+ "html",
+ "markdown",
+ "links",
+ "elements",
+ "json",
+ "accessibility",
+ "controls"
+]Input schema / properties / includePaths / descriptionAdded value: +"Keep only urls whose path contains one of these. Up to twenty."Input schema / properties / includePaths / items / minLengthAdded value: +1Input schema / properties / includePaths / maxItemsAdded value: +20Input schema / properties / includeSubdomains / descriptionAdded value: +"Treat subdomains of the same site as part of it."Input schema / properties / jsonAdded value: +{
+ "additionalProperties": false,
+ "description": "For the `json` format: a `prompt` describing what to pull out, a JSON `schema` to fill, or both.",
+ "properties": {
+ "model": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "prompt": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "schema": {
+ "additionalProperties": {},
+ "type": "object"
+ }
+ },
+ "type": "object"
+}Input schema / properties / limit / defaultAdded value: +25Input schema / properties / limit / descriptionPrevious value: -"Pages it may read (default 25, max 200)."New value: +"Pages this crawl may read, up to 200. Charged up front; what it does not read comes back."Input schema / properties / limit / maximumAdded value: +200Input schema / properties / limit / minimumAdded value: +1Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / linksAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `links` format: `visibleOnly`, `excludeExternal` to keep only internal links.",
+ "properties": {
+ "excludeExternal": {
+ "type": "boolean"
+ },
+ "visibleOnly": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / maxAge / maximumAdded value: +604800000Input schema / properties / maxAge / minimumAdded value: +0Input schema / properties / maxAge / typePrevious value: -"number"New value: +"integer"Input schema / properties / maxDepth / defaultAdded value: +2Input schema / properties / maxDepth / descriptionPrevious value: -"How far to follow links (default 2, max 5)."New value: +"How far from the starting page to follow links. 0 reads only the starting page."Input schema / properties / maxDepth / maximumAdded value: +5Input schema / properties / maxDepth / minimumAdded value: +0Input schema / properties / maxDepth / typePrevious value: -"number"New value: +"integer"Input schema / properties / requestAdded value: +{
+ "additionalProperties": false,
+ "description": "How to make the request: `headers`, `cookies`, `userAgent`, and `auth` for basic authentication.",
+ "properties": {
+ "auth": {
+ "additionalProperties": false,
+ "properties": {
+ "password": {
+ "type": "string"
+ },
+ "username": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "username",
+ "password"
+ ],
+ "type": "object"
+ },
+ "cookies": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "httpOnly": {
+ "type": "boolean"
+ },
+ "name": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "secure": {
+ "type": "boolean"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "headers": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "userAgent": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Input schema / properties / selectorsAdded value: +{
+ "description": "CSS selectors for the `elements` format.",
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / url / descriptionPrevious value: -"Where to start."New value: +"Page to process."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / viewportAdded value: +{
+ "additionalProperties": false,
+ "description": "The window to render in: `width`, `height`, `deviceScaleFactor`.",
+ "properties": {
+ "deviceScaleFactor": {
+ "maximum": 3,
+ "minimum": 0.1,
+ "type": "number"
+ },
+ "height": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "width": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+}Input schema / properties / waitAdded value: +{
+ "additionalProperties": false,
+ "description": "When to consider the page loaded: `until` (load, domcontentloaded, networkidle0, networkidle2), `selector` to wait for, `timeout` in ms.",
+ "properties": {
+ "selector": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "timeout": {
+ "maximum": 60000,
+ "minimum": 100,
+ "type": "integer"
+ },
+ "until": {
+ "enum": [
+ "load",
+ "domcontentloaded",
+ "networkidle0",
+ "networkidle2"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+}web_crawl_status1 field changedInput schema / properties / jobId / descriptionAdded value: +"The crawl, from web_crawl."web_feedback11 fields changedInput schema / properties / comment / maxLengthAdded value: +2000Input schema / properties / comment / minLengthAdded value: +1Input schema / properties / reference / descriptionPrevious value: -"The jobId or sessionId it happened on."New value: +"The jobId or sessionId it happened on, so it can be looked up."Input schema / properties / reference / maxLengthAdded value: +200Input schema / properties / reference / minLengthAdded value: +1Input schema / properties / route / descriptionPrevious value: -"Which tool or endpoint it is about."New value: +"Which tool or endpoint it is about, as you called it."Input schema / properties / route / maxLengthAdded value: +120Input schema / properties / route / minLengthAdded value: +1Input schema / properties / url / descriptionPrevious value: -"The page that came out wrong."New value: +"The page that came out wrong: usually the fastest way to reproduce it."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / verdict / descriptionAdded value: +"Did the answer do the job or not."web_map17 fields changedInput schema / properties / excludePaths / descriptionAdded value: +"Discard urls whose path contains one of these. Up to twenty. It wins over `includePaths`."Input schema / properties / excludePaths / items / minLengthAdded value: +1Input schema / properties / excludePaths / maxItemsAdded value: +20Input schema / properties / includePage / descriptionPrevious value: -"Render the page too (default true)."New value: +"Render the page too, to catch urls the sitemap does not list. `false` uses no browser at all and costs a third."Input schema / properties / includePaths / descriptionAdded value: +"Keep only urls whose path contains one of these. Up to twenty."Input schema / properties / includePaths / items / minLengthAdded value: +1Input schema / properties / includePaths / maxItemsAdded value: +20Input schema / properties / includeSubdomains / descriptionAdded value: +"Treat subdomains of the same site as part of it."Input schema / properties / limit / defaultAdded value: +1000Input schema / properties / limit / descriptionPrevious value: -"Urls to return (default 1000, max 5000)."New value: +"Urls to return. Up to 5000."Input schema / properties / limit / maximumAdded value: +5000Input schema / properties / limit / minimumAdded value: +1Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / search / maxLengthAdded value: +200Input schema / properties / search / minLengthAdded value: +1Input schema / properties / url / descriptionPrevious value: -"The site to map."New value: +"Page to process."Input schema / properties / url / formatAdded value: +"uri"web_scrape33 fields changedInput schema / properties / binaryAsAdded value: +{
+ "default": "base64",
+ "description": "How a screenshot or a PDF comes back. `base64` is the only value today.",
+ "enum": [
+ "base64",
+ "url"
+ ],
+ "type": "string"
+}Input schema / properties / blockAdded value: +{
+ "additionalProperties": false,
+ "description": "What not to load, which makes a render faster and cheaper. `resourceTypes` takes image, font, stylesheet, media… and `urlPatterns` are regular expressions, not globs: `\\.svg$`, not `*.svg`.",
+ "properties": {
+ "resourceTypes": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "urlPatterns": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Input schema / properties / controlsAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `controls` format: `visibleOnly`, and `limit` (1 to 1000) to cut the map.",
+ "properties": {
+ "limit": {
+ "maximum": 1000,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "visibleOnly": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / formats / defaultAdded value: +[
+ "markdown"
+]Input schema / properties / formats / descriptionPrevious value: -"Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt`."New value: +"Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt` or `json.schema`."Input schema / properties / formats / maxItemsAdded value: +9Input schema / properties / formats / minItemsAdded value: +1Input schema / properties / html / descriptionPrevious value: -"Raw HTML instead of `url`."New value: +"Raw HTML instead of `url`, for a page you already have. Nothing leaves for the network."Input schema / properties / html / minLengthAdded value: +1Input schema / properties / json / additionalPropertiesAdded value: +falseInput schema / properties / json / descriptionPrevious value: -"For the `json` format: `prompt` and/or `schema`."New value: +"For the `json` format: a `prompt` describing what to pull out, a JSON `schema` to fill, or both."Input schema / properties / json / properties / modelAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / json / properties / prompt / minLengthAdded value: +1Input schema / properties / json / properties / schema / additionalPropertiesAdded value: +{}Input schema / properties / linksAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `links` format: `visibleOnly`, `excludeExternal` to keep only internal links.",
+ "properties": {
+ "excludeExternal": {
+ "type": "boolean"
+ },
+ "visibleOnly": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / maxAge / maximumAdded value: +604800000Input schema / properties / maxAge / minimumAdded value: +0Input schema / properties / maxAge / typePrevious value: -"number"New value: +"integer"Input schema / properties / pdfAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `pdf` format: `format` (a4, letter, legal…), `landscape`, `printBackground`, `scale` 0.1 to 2.",
+ "properties": {
+ "format": {
+ "enum": [
+ "letter",
+ "legal",
+ "tabloid",
+ "ledger",
+ "a0",
+ "a1",
+ "a2",
+ "a3",
+ "a4",
+ "a5",
+ "a6"
+ ],
+ "type": "string"
+ },
+ "landscape": {
+ "type": "boolean"
+ },
+ "printBackground": {
+ "type": "boolean"
+ },
+ "scale": {
+ "maximum": 2,
+ "minimum": 0.1,
+ "type": "number"
+ }
+ },
+ "type": "object"
+}Input schema / properties / requestAdded value: +{
+ "additionalProperties": false,
+ "description": "How to make the request: `headers`, `cookies`, `userAgent`, and `auth` for basic authentication.",
+ "properties": {
+ "auth": {
+ "additionalProperties": false,
+ "properties": {
+ "password": {
+ "type": "string"
+ },
+ "username": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "username",
+ "password"
+ ],
+ "type": "object"
+ },
+ "cookies": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "httpOnly": {
+ "type": "boolean"
+ },
+ "name": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "secure": {
+ "type": "boolean"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "headers": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "userAgent": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Input schema / properties / screenshotAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `screenshot` format: `fullPage` for the whole page, `type` (png, jpeg, webp), `quality` 1-100 (not with png), `omitBackground`, `selector` to capture one element, and its own `viewport`.",
+ "properties": {
+ "fullPage": {
+ "type": "boolean"
+ },
+ "omitBackground": {
+ "type": "boolean"
+ },
+ "quality": {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "selector": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "png",
+ "jpeg",
+ "webp"
+ ],
+ "type": "string"
+ },
+ "viewport": {
+ "additionalProperties": false,
+ "properties": {
+ "deviceScaleFactor": {
+ "maximum": 3,
+ "minimum": 0.1,
+ "type": "number"
+ },
+ "height": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "width": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+}Input schema / properties / selectors / descriptionPrevious value: -"CSS selectors for `elements`."New value: +"CSS selectors for the `elements` format."Input schema / properties / selectors / items / minLengthAdded value: +1Input schema / properties / selectors / minItemsAdded value: +1Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / viewportAdded value: +{
+ "additionalProperties": false,
+ "description": "The window to render in: `width`, `height`, `deviceScaleFactor`.",
+ "properties": {
+ "deviceScaleFactor": {
+ "maximum": 3,
+ "minimum": 0.1,
+ "type": "number"
+ },
+ "height": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "width": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+}Input schema / properties / wait / additionalPropertiesAdded value: +falseInput schema / properties / wait / descriptionPrevious value: -"When to consider the page loaded: `until`, `selector`, `timeout`."New value: +"When to consider the page loaded: `until` (load, domcontentloaded, networkidle0, networkidle2), `selector` to wait for, `timeout` in ms."Input schema / properties / wait / properties / selector / minLengthAdded value: +1Input schema / properties / wait / properties / timeout / maximumAdded value: +60000Input schema / properties / wait / properties / timeout / minimumAdded value: +100Input schema / properties / wait / properties / timeout / typePrevious value: -"number"New value: +"integer"Input schema / requiredRemoved value: -[]web_scrape_batch29 fields changedInput schema / properties / binaryAsAdded value: +{
+ "default": "base64",
+ "description": "How a screenshot or a PDF comes back. `base64` is the only value today.",
+ "enum": [
+ "base64",
+ "url"
+ ],
+ "type": "string"
+}Input schema / properties / blockAdded value: +{
+ "additionalProperties": false,
+ "description": "What not to load, which makes a render faster and cheaper. `resourceTypes` takes image, font, stylesheet, media… and `urlPatterns` are regular expressions, not globs: `\\.svg$`, not `*.svg`.",
+ "properties": {
+ "resourceTypes": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "urlPatterns": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Input schema / properties / controlsAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `controls` format: `visibleOnly`, and `limit` (1 to 1000) to cut the map.",
+ "properties": {
+ "limit": {
+ "maximum": 1000,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "visibleOnly": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / formats / descriptionPrevious value: -"Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt`."New value: +"Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt` or `json.schema`. A screenshot or a PDF is not available here: every result is kept until you collect it. Ask for those one url at a time on web_scrape."Input schema / properties / formats / items / enumPrevious value: -[
- "html",
- "markdown",
- "links",
- "screenshot",
- "pdf",
- "elements",
- "json",
- "accessibility",
- "controls"
-]New value: +[
+ "html",
+ "markdown",
+ "links",
+ "elements",
+ "json",
+ "accessibility",
+ "controls"
+]Input schema / properties / json / additionalPropertiesAdded value: +falseInput schema / properties / json / descriptionPrevious value: -"For the `json` format: `prompt` and/or `schema`."New value: +"For the `json` format: a `prompt` describing what to pull out, a JSON `schema` to fill, or both."Input schema / properties / json / properties / modelAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / json / properties / prompt / minLengthAdded value: +1Input schema / properties / json / properties / schema / additionalPropertiesAdded value: +{}Input schema / properties / linksAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `links` format: `visibleOnly`, `excludeExternal` to keep only internal links.",
+ "properties": {
+ "excludeExternal": {
+ "type": "boolean"
+ },
+ "visibleOnly": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / maxAge / maximumAdded value: +604800000Input schema / properties / maxAge / minimumAdded value: +0Input schema / properties / maxAge / typePrevious value: -"number"New value: +"integer"Input schema / properties / requestAdded value: +{
+ "additionalProperties": false,
+ "description": "How to make the request: `headers`, `cookies`, `userAgent`, and `auth` for basic authentication.",
+ "properties": {
+ "auth": {
+ "additionalProperties": false,
+ "properties": {
+ "password": {
+ "type": "string"
+ },
+ "username": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "username",
+ "password"
+ ],
+ "type": "object"
+ },
+ "cookies": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "httpOnly": {
+ "type": "boolean"
+ },
+ "name": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "secure": {
+ "type": "boolean"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "headers": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "userAgent": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Input schema / properties / selectors / descriptionPrevious value: -"CSS selectors for `elements`."New value: +"CSS selectors for the `elements` format."Input schema / properties / selectors / items / minLengthAdded value: +1Input schema / properties / selectors / minItemsAdded value: +1Input schema / properties / urls / descriptionPrevious value: -"The urls to read, 2 to 50. They do not have to share a site."New value: +"The pages of this batch. Two to fifty, no duplicates: a batch charges per url."Input schema / properties / urls / items / formatAdded value: +"uri"Input schema / properties / urls / maxItemsAdded value: +50Input schema / properties / urls / minItemsAdded value: +2Input schema / properties / viewportAdded value: +{
+ "additionalProperties": false,
+ "description": "The window to render in: `width`, `height`, `deviceScaleFactor`.",
+ "properties": {
+ "deviceScaleFactor": {
+ "maximum": 3,
+ "minimum": 0.1,
+ "type": "number"
+ },
+ "height": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "width": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+}Input schema / properties / wait / additionalPropertiesAdded value: +falseInput schema / properties / wait / descriptionPrevious value: -"When to consider the page loaded: `until`, `selector`, `timeout`."New value: +"When to consider the page loaded: `until` (load, domcontentloaded, networkidle0, networkidle2), `selector` to wait for, `timeout` in ms."Input schema / properties / wait / properties / selector / minLengthAdded value: +1Input schema / properties / wait / properties / timeout / maximumAdded value: +60000Input schema / properties / wait / properties / timeout / minimumAdded value: +100Input schema / properties / wait / properties / timeout / typePrevious value: -"number"New value: +"integer"web_search_exa14 fields changedInput schema / properties / domains / items / minLengthAdded value: +1Input schema / properties / domains / maxItemsAdded value: +20Input schema / properties / excludeDomains / items / minLengthAdded value: +1Input schema / properties / excludeDomains / maxItemsAdded value: +20Input schema / properties / limit / defaultAdded value: +10Input schema / properties / limit / descriptionPrevious value: -"Results (default 10, max 50)."New value: +"Results to return. Up to 50."Input schema / properties / limit / maximumAdded value: +50Input schema / properties / limit / minimumAdded value: +1Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / query / maxLengthAdded value: +500Input schema / properties / query / minLengthAdded value: +1Input schema / properties / since / maxLengthAdded value: +30Input schema / properties / since / minLengthAdded value: +4Input schema / properties / snippets / descriptionPrevious value: -"Text alongside each result (default true)."New value: +"Text alongside each result. On by default: a bare url is rarely enough."web_session_close1 field changedInput schema / properties / sessionId / descriptionAdded value: +"The session to close, from web_session_open."web_session_open30 fields changedInput schema / properties / binaryAsAdded value: +{
+ "default": "base64",
+ "description": "How a screenshot or a PDF comes back. `base64` is the only value today.",
+ "enum": [
+ "base64",
+ "url"
+ ],
+ "type": "string"
+}Input schema / properties / blockAdded value: +{
+ "additionalProperties": false,
+ "description": "What not to load, which makes a render faster and cheaper. `resourceTypes` takes image, font, stylesheet, media… and `urlPatterns` are regular expressions, not globs: `\\.svg$`, not `*.svg`.",
+ "properties": {
+ "resourceTypes": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "urlPatterns": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Input schema / properties / controlsAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `controls` format: `visibleOnly`, and `limit` (1 to 1000) to cut the map.",
+ "properties": {
+ "limit": {
+ "maximum": 1000,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "visibleOnly": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / formats / defaultAdded value: +[
+ "controls"
+]Input schema / properties / formats / descriptionPrevious value: -"Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt`."New value: +"Outputs you want in the same response. `controls` is the map of what can be clicked; `elements` needs `selectors`; `json` needs `json.prompt` or `json.schema`."Input schema / properties / formats / maxItemsAdded value: +9Input schema / properties / formats / minItemsAdded value: +1Input schema / properties / json / additionalPropertiesAdded value: +falseInput schema / properties / json / descriptionPrevious value: -"For the `json` format: `prompt` and/or `schema`."New value: +"For the `json` format: a `prompt` describing what to pull out, a JSON `schema` to fill, or both."Input schema / properties / json / properties / modelAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / json / properties / prompt / minLengthAdded value: +1Input schema / properties / json / properties / schema / additionalPropertiesAdded value: +{}Input schema / properties / linksAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `links` format: `visibleOnly`, `excludeExternal` to keep only internal links.",
+ "properties": {
+ "excludeExternal": {
+ "type": "boolean"
+ },
+ "visibleOnly": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / maxAge / maximumAdded value: +604800000Input schema / properties / maxAge / minimumAdded value: +0Input schema / properties / maxAge / typePrevious value: -"number"New value: +"integer"Input schema / properties / pdfAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `pdf` format: `format` (a4, letter, legal…), `landscape`, `printBackground`, `scale` 0.1 to 2.",
+ "properties": {
+ "format": {
+ "enum": [
+ "letter",
+ "legal",
+ "tabloid",
+ "ledger",
+ "a0",
+ "a1",
+ "a2",
+ "a3",
+ "a4",
+ "a5",
+ "a6"
+ ],
+ "type": "string"
+ },
+ "landscape": {
+ "type": "boolean"
+ },
+ "printBackground": {
+ "type": "boolean"
+ },
+ "scale": {
+ "maximum": 2,
+ "minimum": 0.1,
+ "type": "number"
+ }
+ },
+ "type": "object"
+}Input schema / properties / requestAdded value: +{
+ "additionalProperties": false,
+ "description": "How to make the request: `headers`, `cookies`, `userAgent`, and `auth` for basic authentication.",
+ "properties": {
+ "auth": {
+ "additionalProperties": false,
+ "properties": {
+ "password": {
+ "type": "string"
+ },
+ "username": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "username",
+ "password"
+ ],
+ "type": "object"
+ },
+ "cookies": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "httpOnly": {
+ "type": "boolean"
+ },
+ "name": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "secure": {
+ "type": "boolean"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "headers": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "userAgent": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Input schema / properties / screenshotAdded value: +{
+ "additionalProperties": false,
+ "description": "Options for the `screenshot` format: `fullPage` for the whole page, `type` (png, jpeg, webp), `quality` 1-100 (not with png), `omitBackground`, `selector` to capture one element, and its own `viewport`.",
+ "properties": {
+ "fullPage": {
+ "type": "boolean"
+ },
+ "omitBackground": {
+ "type": "boolean"
+ },
+ "quality": {
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "selector": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "png",
+ "jpeg",
+ "webp"
+ ],
+ "type": "string"
+ },
+ "viewport": {
+ "additionalProperties": false,
+ "properties": {
+ "deviceScaleFactor": {
+ "maximum": 3,
+ "minimum": 0.1,
+ "type": "number"
+ },
+ "height": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "width": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+}Input schema / properties / selectors / descriptionPrevious value: -"CSS selectors for `elements`."New value: +"CSS selectors for the `elements` format."Input schema / properties / selectors / items / minLengthAdded value: +1Input schema / properties / selectors / minItemsAdded value: +1Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / viewportAdded value: +{
+ "additionalProperties": false,
+ "description": "The window to render in: `width`, `height`, `deviceScaleFactor`.",
+ "properties": {
+ "deviceScaleFactor": {
+ "maximum": 3,
+ "minimum": 0.1,
+ "type": "number"
+ },
+ "height": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "width": {
+ "maximum": 4096,
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+}Input schema / properties / wait / additionalPropertiesAdded value: +falseInput schema / properties / wait / descriptionPrevious value: -"When to consider the page loaded: `until`, `selector`, `timeout`."New value: +"When to consider the page loaded: `until` (load, domcontentloaded, networkidle0, networkidle2), `selector` to wait for, `timeout` in ms."Input schema / properties / wait / properties / selector / minLengthAdded value: +1Input schema / properties / wait / properties / timeout / maximumAdded value: +60000Input schema / properties / wait / properties / timeout / minimumAdded value: +100Input schema / properties / wait / properties / timeout / typePrevious value: -"number"New value: +"integer"web_search_exa2 fields changedInput schema / properties / domains / descriptionPrevious value: -"Only these domains."New value: +"Only these domains, subdomains included: `example.com` also matches `docs.example.com`."Input schema / properties / excludeDomains / descriptionPrevious value: -"Never these domains."New value: +"Never these domains, subdomains included."web_actweb_batch_statusweb_crawlweb_crawl_statusweb_feedbackweb_mapweb_scrapeweb_scrape_batchweb_search_exaweb_session_closeweb_session_openScrape, crawl, map and extract the web. Pay per call in USDC, no account or API key.
Extract public webpages as Markdown, map sites, and run bounded crawl jobs. API key required.
Turn any URL into clean Markdown and structured data. Scrape, crawl, search and extract.
Cloud scraping & crawling API for AI agents. Turn any URL into clean, LLM-ready markdown.
Add one secure layer between your agents and this server.