Read, map and crawl the web, and drive a real browser. Pay per call, no key, no signup.
Scored across 11 tools
Each tool targets a distinct web operation: search, map, scrape, crawl, batch scrape, interactive session actions, and status/feedback. Overlaps like scrape vs. scrape_batch and map vs. crawl are explicitly clarified by descriptions (e.g., crawl discovers links while batch does not). No two tools appear to do the same thing.
All tools share the `web_` prefix and snake_case, making them easy to scan. However, the set mixes verb-first (web_act, web_scrape) and noun-first (web_batch_status, web_session_open) forms, so it is not a strict verb_noun pattern throughout.
11 tools is well-scoped for a web-for-agents server, covering search, discovery, reading, batch operations, interactive sessions, and status polling without bloat. Each tool earns its place.
The surface covers the full web access lifecycle: search, map, scrape (single/file), batch scrape, crawl, interactive session open/act/close, async status checks, and feedback. No obvious gaps remain for an agent needing to discover, read, and interact with the web.
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 per action.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page to process. | |
| json | No | For the `json` format: `prompt` and/or `schema`. | |
| wait | No | When to consider the page loaded: `until`, `selector`, `timeout`. | |
| 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 | Actions, in order. | |
| 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`. | |
| selectors | No | CSS selectors for `elements`. | |
| sessionId | Yes | The one web_session_open returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses failure semantics ('stops at the first failure and tells you where'), that it returns resulting state, and pricing ('$0.0005 per action'). It omits session-expiry or permission behavior, but the core behavioral traits are 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?
Extremely dense and front-loaded: purpose first, then the action grammar, then the ref provenance, then failure and pricing. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action mutation tool with no annotations and no output schema, the description covers the essential invocation surface (action grammar, failure behavior, cost). It could say more about the shape of the returned 'resulting state', but that gap is modest given the tool's scope.
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 baseline is 3, but the description adds real meaning beyond the schema: the `actions` items are untyped objects in the schema, and the description supplies their shape ({click:{ref}}, {type:{ref,text,clear}}, etc.) and clarifies that `ref` comes from the `controls` output. This compensates for the schema's generic array items.
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 ('runs actions') and resource ('an open session') and enumerates the exact action vocabulary (navigate, click, type, select, press, scroll, wait, back). This clearly separates it from siblings like web_scrape, web_crawl, and web_session_open, which don't operate on an already-open session.
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 phrase 'against an open session' implies the prerequisite that web_session_open must run first, and the action list implies interactive driving. However, it never explicitly states when to use this over web_scrape or web_batch, nor any when-not conditions.
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. Pass cancel: true to stop it and get the urls it never read refunded.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| limit | No | Results to return (default 50). | |
| cancel | No | Stop the batch and refund what it did not read. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose two real behavioral traits: the call is free, and cancel:true is destructive in a specific way (stops the batch and refunds unread urls), which is more precise than the schema's "refund what it did not read." It still omits whether the check itself mutates or consumes quota, and what state the job is left in after cancel.
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 sentences, front-loaded with the return payload, then the cost, then the abort flag. The one-word "Free." fragment earns its place by answering the cost question immediately.
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, so the description must characterize the return; it does so at a high level (status, done count, results) which is sufficient for an agent to know what it is polling. The only real gap is how to obtain jobId and how limit interacts with large result sets, both left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: limit and cancel are already documented in structured fields, and the prose on cancel largely restates them. jobId is undocumented in both places, and the description never says where jobId comes from (presumably web_scrape_batch), so it does not compensate for the coverage gap.
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 batch of scrapes") and enumerates what comes back: status, completion count, and results. An agent can tell it apart from web_scrape_batch, but it never names a sibling or says explicitly that it pairs with web_scrape_batch rather than web_crawl_status.
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 phrase "a batch of scrapes" suggests calling it after web_scrape_batch, and the cancel flag hints at an abort path. No when-to-use, when-not-to-use, or alternative tool (web_crawl_status) is named, so the agent must infer the routing.
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. Charged up front for the pages it is allowed to read (limit), and the pages it never reads are refunded. Use web_map first if you only need the urls.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Where to start. | |
| limit | No | Pages it may read (default 25, max 200). | |
| 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`. | |
| maxDepth | No | How far to follow links (default 2, max 5). | |
| excludePaths | No | ||
| includePaths | No | ||
| includeSubdomains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and does well: it discloses the async job pattern (returns jobId, poll with web_crawl_status) and the unusual billing model (charged up front for `limit` pages, unread pages refunded). No auth requirements or rate limits are mentioned, but the async and cost behavior are the non-obvious traits.
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, all front-loaded and earned: purpose first, then the async contract and cost model, then the routing alternative. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an async, no-output-schema, no-annotation crawl tool, the description covers the critical facts an agent needs: what it does, how to retrieve results, cost behavior, and when to prefer web_map. Missing only the semantics of the path-filter parameters.
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 63% with 8 parameters. The description reinforces the billing meaning of `limit` (charged for the pages it is allowed to read), adding value beyond the schema's 'Pages it may read'. But excludePaths, includePaths, and includeSubdomains receive no explanation in either place, and the `formats`/`magAge` semantics live only in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: follows a site's links and reads every page. It explicitly separates itself from the sibling web_map by noting to use web_map first if only urls are needed, so an agent can distinguish them without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear alternative condition (use web_map if you only need urls) and explains the follow-up workflow (poll with web_crawl_status). It does not, however, address when to choose this over web_scrape or how it relates to the batch tools.
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. Pass cancel: true to stop it and get the unread pages refunded.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| limit | No | Pages to return (default 50). | |
| cancel | No | Stop the crawl and refund what it did not read. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses cost ('Free') and the side effect/refund behavior of `cancel: true`, but omits permissions, rate limits, whether the crawl keeps running, and error behavior — meaningful gaps for a job-status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with what is returned, then the cancellation option. No filler and no redundancy.
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 enumerates the return payload and the cancel side effect, which is the key missing information. It falls short on auth/rate-limit context and the undocumented `jobId` parameter is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: `limit` and `cancel` are documented in the schema, while `jobId` is undocumented in both places. The description repeats the cancel/refund semantics already present in the schema rather than adding new meaning, so it does little beyond the structured fields.
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 fields returned (status, pages read, discovered, queued, pages). It is distinguishable from the sibling web_crawl (which starts one) by implication, but it never names or contrasts the sibling to make the routing explicit.
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 intended context (polling an in-flight crawl) is implied, and it surfaces a real alternative mode via `cancel: true`. However there is no explicit guidance on when to call this versus web_batch_status or when to re-check, so the agent must infer the usage pattern.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The page that came out wrong. | |
| route | No | Which tool or endpoint it is about. | |
| comment | No | What you expected and what you got. | |
| verdict | Yes | ||
| reference | No | The jobId or sessionId it happened on. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that feedback is free, requires a URL or jobId for reproduction, and is the only way the system learns about bad page reads, but it does not explain what happens after submission, whether it is anonymous or stored, or any 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?
The description is front-loaded with the core action and remains reasonably concise. The final sentence provides a justification for using the tool, which is helpful but slightly verbose.
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 simple feedback tool with no output schema and 80% schema coverage, the description adequately explains when to use it and what to provide. It lacks details on post-submission behavior, but that is not critical for a correctly invoked call.
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 80%, so the baseline is 3. The description reinforces the use of 'url' or 'jobId' (reference) for reproduction and implies the verdict is 'good' or 'bad', but adds little meaning beyond the schema's own descriptions.
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 clear verb+resource: submit feedback ('Tell us an answer was good or bad') on web tool output quality. It does not explicitly name sibling tools or distinguish itself from them, but the name and context make the purpose obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear condition for use: 'Use it when a result is wrong' with concrete examples (empty markdown, missing button, mismatched data). It also implies use for good results via 'good or bad', but offers no when-not-to-use guidance or alternative tools.
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. $0.0003 with includePage: false (no browser at all), $0.0015 with the page.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The site to map. | |
| limit | No | Urls to return (default 1000, max 5000). | |
| search | No | Keep only urls containing this text. | |
| includePage | No | Render the page too (default true). | |
| excludePaths | No | ||
| includePaths | No | ||
| includeSubdomains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden, and it delivers real behavioral context: exact cost at both modes and the important fact that includePage:false uses 'no browser at all'. It stops short of stating auth requirements, rate limits, or return format, which leaves some gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with what the tool returns, then the usage rule, then the cost. Every clause earns its place and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema and no annotations, the description covers the core operation, the recommended usage ordering, and the cost tradeoff well, but says nothing about the path-filtering or subdomain parameters or the shape of what comes back, leaving the agent to infer those.
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 57%, and several parameters (excludePaths, includePaths, includeSubdomains) have no description at all. The description richly enriches includePage with cost and browser-mode semantics, but does not compensate for the undocumented array parameters, so the schema still does most of the heavy lifting.
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 - enumerating every URL of a site via its sitemap, with the optional page-link expansion. The agent can immediately distinguish this 'map' operation from the sibling crawl/scrape tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it 'BEFORE crawling, to see what is there and decide what is worth reading', which both defines the trigger and positions it relative to the sibling web_crawl tool. This is a genuine when-to-use statement, not an implied one.
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 $0.001 per output. A url pointing at a PDF, Word, Excel or CSV file is converted to markdown instead, with no browser, for $0.002.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page to process. | |
| html | No | Raw HTML instead of `url`. | |
| json | No | For the `json` format: `prompt` and/or `schema`. | |
| wait | No | When to consider the page loaded: `until`, `selector`, `timeout`. | |
| 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`. | |
| selectors | No | CSS selectors for `elements`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses partial-failure semantics ('a partial failure does not void the rest'), cost per output, cache pricing for maxAge, and that file URLs are converted without a browser. It stops short of covering auth requirements 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?
Three tight sentences, front-loaded with the core capability and output list, then failure/cost behavior, then the special file-conversion case. No filler and nothing buried.
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?
No output schema exists, and the description compensates by enumerating every returnable format and the `controls` semantics. Missing pieces are minor: no mention of authentication, rate limits, or what an error response looks like when all formats fail.
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 baseline is 3, but the description adds real meaning: maxAge's cache-hit pricing and fresh-render default, the dependency of `elements` on `selectors` and `json` on `json.prompt`, and the alternate non-browser path for file URLs.
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 ('Processes a page') and enumerates exactly what comes back (markdown, html, links, screenshot, PDF, accessibility, elements, json, controls). It is distinguishable from a plain crawler by the multi-output single-call framing, though it never names a sibling to sharpen 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?
It never says when to choose this over web_crawl, web_search_exa, or web_scrape_batch, nor when a targeted alternative is preferable. The 'one call' phrasing implies a preference for batching outputs but no explicit selection criteria are given.
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. Charged up front per url; urls that fail and urls served from the cache are refunded. Poll it with web_batch_status.
| Name | Required | Description | Default |
|---|---|---|---|
| json | No | For the `json` format: `prompt` and/or `schema`. | |
| urls | Yes | The urls to read, 2 to 50. They do not have to share a site. | |
| wait | No | When to consider the page loaded: `until`, `selector`, `timeout`. | |
| 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`. | |
| selectors | No | CSS selectors for `elements`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses the async job model (returns a jobId, must be polled), upfront per-url charging, and that failed and cache-served urls are refunded. It does not cover auth requirements or rate limits, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, zero waste, with the core action, the explicit exclusion, the billing model, and the polling requirement each front-loaded in turn. Nothing is padding.
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 an async batch tool with no output schema, the description supplies the essential contract: input shape, returned handle (jobId), cost model, and the required status-polling tool. Only fine details like job-id lifetime or partial-failure semantics are absent, which is acceptable given the sibling status tool exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter including the nested json/wait objects. The description reinforces the url count range (2 to 50) and site-agnosticism plus cache pricing, but adds little syntax beyond what the schema states. 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 ('reads a list of urls... returns a jobId') and explicitly distinguishes itself from the sibling web_crawl by noting it 'discovers nothing on its own.' An agent can separate this from web_scrape and web_crawl 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 both the when (batch read of a user-supplied url list) and the when-not ('for that use web_crawl'), plus the required follow-up action ('Poll it with web_batch_status'). The alternative and the next step in the workflow are both named.
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 — today $0.007 per search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results (default 10, max 50). | |
| query | Yes | What to search for. | |
| since | No | Only results published after this ISO date. | |
| domains | No | Only these domains. | |
| snippets | No | Text alongside each result (default true). | |
| excludeDomains | No | Never these domains. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the return fields, the cost model ($0.007 per search, pass-through with no markup, read from a payment challenge on every call), and the downstream tool. It omits auth requirements, rate limits, and pagination behavior, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then return shape, then the follow-up route, then cost. Every sentence carries information, though the final pricing clause is dense and slightly overlong relative to its value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter search tool with no output schema, the description supplies purpose, return fields, cost, and the hand-off to web_scrape_batch. Parameters are fully covered by the schema, so the only real gap is auth/rate-limit context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter (limit, query, since, domains, snippets, excludeDomains) is already documented in the schema with defaults and constraints. The description adds no parameter-level detail beyond the query-vs-url framing, which is the expected baseline when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search the web with Exa's index') and immediately distinguishes itself from URL-based siblings with 'a query instead of a url'. The return shape (title, url, snippet) is named, so an agent knows exactly what this produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use condition ('for when you do not know where to look') and names the correct alternative and follow-up path ('pass the urls to web_scrape_batch'). The division of labor between search and scrape is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Closes a session and stops billing browser time. Free. If you do not close it, it closes itself after a minute without use.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well by disclosing that closing stops billing, that the call is free, and that abandonment triggers automatic closure after ~60s idle. It stops short of covering failure modes (invalid or already-closed sessionId) or what happens to session artifacts.
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 sentences, zero filler, with the primary action and effect front-loaded before the billing and auto-close details. Every sentence earns its place.
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 single-parameter lifecycle tool with no output schema and no annotations, the description supplies the key operational facts (billing stop, cost, auto-close). Only the parameter's origin/format is unaddressed, a minor gap given the obvious name.
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 0% and the description never mentions sessionId, so nothing clarifies where the identifier comes from or what form it takes. The self-descriptive parameter name is the only signal, which is thin compensation for a fully undocumented field.
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 (closes) and resource (session) plus the operational effect (stops billing browser time). It is unambiguously distinct from siblings like web_session_open, web_scrape, or web_search_exa; an agent can pick it 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?
Usage is only implied: the agent infers it should be called when finished with a session, since the description notes the session self-closes after a minute of inactivity. There is no explicit when-to-use, when-not-to-use, or named alternative, and no prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens a browser on a page and leaves it open, returning the map of controls. Use it when something has to be FILLED IN or CLICKED, not just read: inside the session the controls references keep working and you can act on the same state. $0.005 plus the outputs. Close it with web_session_close when you are done.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page to process. | |
| json | No | For the `json` format: `prompt` and/or `schema`. | |
| wait | No | When to consider the page loaded: `until`, `selector`, `timeout`. | |
| 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`. | |
| selectors | No | CSS selectors for `elements`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it discloses meaningful traits: the session state persists ('leaves it open', 'controls references keep working'), cost ($0.005 plus outputs, $0.0002 cache hit), and the required close call. It does not touch auth/rate-limit or session-lifetime/expiry behavior, which would be the remaining gap for a stateful tool.
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, zero waste, front-loaded with the core action and its statefulness, then the usage rule, then cost and cleanup. Every sentence earns its place.
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?
No output schema exists, and the description covers the return concept (map of controls), the persistent-session model, pricing and the close path. For a 6-param nested-schema tool it is nearly complete; session lifetime/timeout expectations and whether the returned controls survive navigation are unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented in the schema. The description adds only the conceptual 'controls references' note, not format/syntax guidance for wait, maxAge, formats or selectors. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('opens a browser on a page and leaves it open, returning the map of controls') and explicitly distinguishes the tool from read-only alternatives via 'when something has to be FILLED IN or CLICKED, not just read'. An agent can separate this from web_scrape/web_crawl without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use condition (interactive fill/click versus read) plus the lifecycle exit ('Close it with web_session_close when you are done'), naming the sibling responsible for cleanup. Nothing essential is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
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.
Fetch, crawl, and browse protected pages with anti-bot handling - renders in a real browser and
Crawl, scrape, search the web, and automate browsers at scale with anti-bot bypass.
Programmatic headless browser sessions: create, interact, browse, and extract - rendered in a real
Add one secure layer between your agents and this server.
