scrapeunblocker-mcp-remote

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

Going well beyond the readOnly/openWorld/non-destructive annotations, it discloses the IP-based currency inference behavior, the automatic ISP-proxy routing by proxy_country, the reported exitCountry/exitProvider metadata, and the unit-based billing model. These are non-obvious operational traits an agent could not derive from annotations or schema.

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

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

It is front-loaded with the return payload, then behavior, then args/billing, and most sentences carry weight. The closing sentence about listing plugins billing per result page and keeping 'max_results' modest is irrelevant boilerplate for a single-product tool with no max_results parameter, which is the one clear waste.

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 compensates by enumerating the returned fields (title, brand, price/currency, availability, rating, images, etc.) plus the meta fields exitCountry/exitProvider. Combined with argument selection rules, defaults, currency behavior and billing, an agent has everything needed to call it correctly.

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 already 100%, so the baseline is 3, but the description adds real meaning: why proxy_country matters (prices are returned in the currency of the inferred delivery location) and how url subsumes asin/marketplace. It does not, however, document edge cases such as invalid ASIN handling or unsupported marketplaces.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Fetches a single Amazon product and returns it as JSON') and even enumerates the returned fields, so the agent knows exactly what comes back. The word 'single' implicitly separates it from amazon_search/amazon_reviews, but no sibling is named explicitly, which keeps it short of a 5.

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 concrete invocation guidance: identify the product with either 'asin' (plus 'marketplace') or a full product 'url', and explains that proxy_country defaults to the marketplace's home country. It never states when to prefer this tool over amazon_search for keyword discovery or amazon_reviews for review data, so it stops short of the explicit when/when-not/alternatives rubric.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior: reviewsGated gating on amazon.com, null-when-absent field semantics, proxy country reporting via exitCountry/exitProvider, and per-page billing. It doesn't cover rate limits or retry/failure behavior, so a 3 is fair against the annotation baseline.

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, and the long field enumeration earns its place because there is no output schema. Some sentences are run-ons, but no content is filler given the missing output 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?

With no output schema, the description must carry the full return-value burden and does: rating, reviewCount, histogram, customersSay aspects/excerpts, and per-review fields are all enumerated, plus gating and null-fill semantics. Nothing an agent needs to interpret the response is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the four parameter descriptions already document the asin/marketplace/url relationship, the marketplace enum list and the proxy_country default. The description largely restates this ('Identify the product with asin (plus marketplace) or a product url'), so it adds little 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?

Opens with a specific verb+resource: returns Amazon product-page review data as JSON. It clearly delineates scope ('public slice on the product page') versus a full review export, which is exactly the line that separates it from amazon_product (details) and search siblings.

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?

Explains how to invoke it (identify product via asin+marketplace or url) and gives a strong negative-scope statement ('not a complete review export', 5-13 top reviews). It does not explicitly name sibling tools to use instead, but the context of use is unambiguous.

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

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

Beyond the readOnly/openWorld annotations it discloses non-obvious behavior: price-less cards return `price: null` and are retained rather than dropped, `proxy_country` defaults to the marketplace home country to keep currency consistent, and notably the billing model (one unit per result page, keep max_results modest). That cost/rate context is exactly what annotations cannot convey.

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 return shape in the first sentence, then layers filtering, pagination, edge-case price behavior and billing, with no filler sentences. It is a dense single paragraph, but each clause adds information an agent can act on.

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 full burden of describing returns and does so field-by-field, plus it covers the null-price edge case, default currency behavior and cost. Nothing material is missing for a 7-parameter search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented, and the description largely restates the sort enum and the proxy/marketplace currency defaults rather than adding new syntax or constraints. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Searches) plus resource (any regional Amazon marketplace listings), and enumerates the returned card fields, so an agent knows exactly what it gets. It also distinguishes itself from the sibling amazon_product by handing off full-detail fetches to that tool.

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 routes detail lookups to `POST /marketplace/amazon-product`, which is genuine sibling differentiation against amazon_product. It also spells out how to filter, order and page, though it never says when to prefer this over ebay_search, walmart_search or google_shopping for product queries.

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

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

Annotations already carry the safety profile (readOnly, openWorld, non-destructive), so the bar is lower, yet the description adds genuine operational context beyond them: pagination ('across pages') and the billing/rate model ('billed like an API request', 'one unit per result page'). That billing detail materially affects how an agent should size max_results.

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 usage tips and billing caveat in a logical order. Slightly redundant: JSON output is mentioned twice ('returns the properties as JSON' and 'Returns JSON'), which costs a little space.

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 carries the return-value burden by listing the returned fields (name, price, reviewScore, address, coordinates, image, url), plus pagination and billing behavior. Nothing an agent needs to call or interpret this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter is already documented in the schema. The description restates the tunable knobs (adults, children, rooms, currency, max_results) and the checkin/checkout-for-prices rule, but adds little syntax or constraint information beyond what the schema provides. 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 ('Searches Booking.com for `location`') and enumerates the returned fields, so an agent immediately knows what this tool produces. It is the only hotel-scraping sibling, so distinction from the amazon/google/zillow tools is unambiguous.

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 real usage condition: prices only appear when check-in/check-out dates are provided, so an agent knows what to supply to get pricing. It also advises keeping max_results modest. It stops short of naming alternatives, though no close sibling competes with it.

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

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

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), yet the description adds substantial extra behavior: the exactMatches=false plus notice fallback for loosely-related suggestions, and the billing model (per-result-page units, keep max_results modest). This is real context beyond the 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?

Front-loaded with purpose and return shape, then filters, then the exactMatches caveat and billing. Dense but every sentence carries information; the enumeration of return fields is slightly list-heavy but justified since no output schema exists.

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 13-parameter tool with no output schema, the description adequately covers both input groups and the response shape, and it flags the non-obvious eBay fallback behavior that would otherwise mislead an agent. Nothing essential to correct invocation appears 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%, so the schema already documents all 13 parameters including defaults and the marketplace enum list. The description restates the filter/sort/paging groups but adds no syntax or format detail beyond the schema, so the baseline 3 applies. It also references a 'max_results' knob that does not exist in the schema, a minor inconsistency.

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 (searches) and resource (eBay listings), names the scope (any regional marketplace), and enumerates the exact return fields including normalised conditionCode. An agent can distinguish this from amazon_search or walmart_search purely from the definition since it is explicitly eBay-scoped.

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 context for marketplace selection ('prices, currency and availability differ between ebay.com, ebay.de, ebay.co.uk') and how filtering/sorting/paging work. It never states when NOT to use this tool or points to a sibling alternative, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context like bypassing anti-bot protection and using a real browser, which helps the agent understand what happens under the hood. It also notes that steps are non-idempotent in the schema, though not in the main description—still, it adds enough value beyond annotations.

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

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

Two sentences, front-loaded with the core purpose and key differentiator (anti-bot bypass). The alternative-trigger guidance and list_elements hint are placed efficiently without redundancy. 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 tool with a detailed schema and read-only annotations, the description covers the essential points: what it does, when to use it, what it returns, and how to prepare for interactive steps. No critical missing information for an agent to invoke it correctly.

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 documented. The description adds a small amount of guidance for the steps parameter ('interact with the page... use the list_elements tool first'), but this is a usage hint rather than new semantic meaning. Baseline 3 is appropriate; 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?

Clearly states the specific action ('Fetch the fully rendered HTML of any web page') and resource (web page via ScrapeUnblocker API). It differentiates from siblings like fetch_parsed (raw vs parsed HTML) and google_search (search vs fetch). No ambiguity about what the tool does.

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 when to use: 'Use when a normal fetch is blocked (403/429, captcha) or the page needs a real browser.' It also directs the agent to use list_elements first for steps, providing clear alternative tool usage guidance.

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

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

Annotations already declare readOnly/openWorld/no-destructive, so the safety profile is covered; the description adds meaningful behavior on top — the fallback to rendered HTML when no structured data is found and that this fallback is billed like fetch_html. It leaves out latency, rate limits, and failure modes, so it is good 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?

Two sentences, zero waste: the primary purpose and return type come first, the edge-case fallback and its billing implication second. Everything is front-loaded and each clause 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?

With no output schema, the description carries the return-value burden and does so well by naming the JSON categories and the HTML fallback. It is nearly complete for a 2-parameter read tool, missing only detail on how the 'no structured data' signal is surfaced in the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters (url, proxy_country) are fully documented in the schema, so the baseline is 3. The description adds no extra meaning about the URL format or what proxy_country changes about the fetch.

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 (fetch a web page and return AI-parsed structured JSON) and explicitly contrasts the return type with raw HTML, which cleanly separates it from the sibling fetch_html. The parenthetical examples of structured payloads (product details, article content, listings) make the resource scope concrete.

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 names the alternative (fetch_html) and the condition under which the result degrades to it, giving the agent a decision rule. It doesn't state when to prefer fetch_html outright or preconditions such as auth/rate limits, so it falls short of an explicit when/when-not pair.

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

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

Annotations cover read-only/safe/open-world status, but the description adds substantial non-obvious behavior beyond them: exact return field semantics (e.g., `imageUrl` is the full-resolution origin, except for PDF-embedded images where it is a Google thumbnail), billing per page, page limits (~400-500 per query), and pagination behavior up to 5 pages.

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?

It is information-dense but front-loads the main purpose and then walks through parameters in a logical order. It is somewhat long and could be tightened, but every sentence carries useful operational detail.

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 8-parameter, no-output-schema tool, it covers purpose, output shape, parameter interactions, limits, and billing. An agent has enough information to call it correctly without opening 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 description coverage is 100%, so the baseline is 3; however, the description adds meaning not fully captured by the schema, such as how `proxy_country` automatically sets `gl` unless overridden, and clarifies `time_range`/`date_from`/`date_to` semantics for repeated scans.

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 the Google Images vertical') and resource, and identifies the concrete output artifact (image results as JSON) with field-level detail. It is clearly distinguished from siblings like google_search, google_shopping, and google_local by naming the `udm=2` vertical.

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 context for several parameters: use `time_range`/`date_from`/`date_to` for repeated new-result scans, set `proxy_country` to target a market, and keep `max_results` modest due to billing. It does not explicitly say when to prefer this over google_search or other image-capable siblings, but the vertical-specific purpose largely makes that unnecessary.

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

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

Annotations cover the safety profile (readOnly, openWorld, non-destructive), and the description adds genuinely new behavior: phone/website come back null when Google doesn't render them, service businesses usually carry both, and billing is one unit per result page fetched. Cost and data-availability disclosure beyond the annotations is exactly the value-add expected.

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 and return shape, then tacks on location and billing caveats; every sentence carries information. Minor redundancy in restating 'Returns JSON' after already saying results come back as JSON.

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 compensates by listing all returned fields and flagging which can be null. Combined with location and billing guidance, an agent has everything needed to call and interpret the tool.

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 goes further by explaining the purpose of proxy_country plus gl/hl as a location-targeting mechanism rather than restating their type. It adds intent the schema alone doesn't convey.

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 a Google Local (`tbm=lcl`) search for `keyword`') and enumerates the returned fields, which cleanly separates it from google_search and maps_place_details. An agent can tell this is the SERP-scraping local-results 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?

Gives clear operational context: local results are location-sensitive, so set proxy_country and optionally gl/hl to target a market, and keep max_results modest because of billing. It stops short of naming an alternative (e.g., maps_place_details) or stating when not to use this tool.

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

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

The annotations already indicate read-only, open-world, and non-destructive behavior. The description adds that it uses an external API but does not disclose further behavioral details such as rate limits, network dependencies, or potential result variance.

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 a single, concise sentence with no redundancy or irrelevant information. It clearly communicates the action, the method, and the expected output format.

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?

The description provides essential context: it performs a search, uses a specific API, and returns JSON with organic results. While there is no output schema, the description gives enough shape for a typical search-result response and the parameter schema fills in the remaining details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter having a clear description, so the description does not need to repeat parameter details. The schema itself adequately documents keyword, proxy_country, and pages_to_check.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs a Google search via the ScrapeUnblocker API and returns organic results as JSON. This distinguishes it from sibling tools like fetch_html or list_elements, which are more generic scraping/list operations.

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 when Google search results are needed and specifies the output format, but it does not explicitly state when to use this tool versus the sibling tools or mention limitations. There is no direct alternative comparison.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful behavioral context beyond them: one render returns only the first page of products, Google Shopping exposes no per-product URL so `url` is omitted, `image` is best-effort, and the cost model (one unit per result page; billed like an API request). It stops short of noting rate limits or auth requirements, so not a full 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 what the tool returns, then guidance, then caveats and billing in a logical order with no filler. It is dense for a single paragraph but every clause carries information; slightly long for a 6-param 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?

With no output schema, the description carries the burden and delivers: it enumerates the return fields, discloses the missing `url` and best-effort `image`, states the single-page v1 limitation, and explains the billing units. An agent has enough to call it correctly and set expectations on results and cost.

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 and the schema already documents every parameter. The description still adds value by explaining the interaction between proxy_country and gl (region-specific prices/merchants) and the v1 first-page constraint on max_results, going beyond the field-level text.

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 the Google Shopping vertical (udm=28)') and enumerates the returned fields, which cleanly separates it from google_search, amazon_search, walmart_search and ebay_search siblings. An agent can identify what this tool 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?

The description explains how to target a market (proxy_country/gl) and filter by price, and warns to keep max_results modest due to per-page billing, which implies usage context. However, it never states when to prefer this tool over its many shopping/search siblings (amazon_search, ebay_search, google_search) or any exclusions, leaving routing to inference.

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

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

Annotations only cover the safety profile (readOnly/openWorld/non-destructive), and the description adds substantially more: Cloudflare + PerimeterX anti-bot handling, that sponsored placements appear in results, and the billing model (per result page fetched, billed like an API request). The cost/cadence disclosure is exactly the kind of behavior annotations cannot express.

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

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

A single dense, front-loaded paragraph with no filler sentences; outputs are listed before filter/sort guidance. The run-on style and stacked parentheticals make it slightly harder to scan than a bulleted alternative, but nothing is wasted.

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

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

With 11 parameters and no output schema, the description carries the return-shape burden and does so by naming every returned field, plus discloses cost, anti-bot handling, and pagination behavior. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already defines every parameter; baseline would be 3. The description still adds meaning beyond the schema by glossing `days` as posting age, explaining that sort='date' returns collected jobs newest-first with sponsored included, and noting max_results spans pages.

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?

Opens with a specific verb+resource ('Searches Indeed for `query` in `location`') and enumerates the returned fields, so the agent immediately knows what comes back. No sibling tool covers job listings, so it is unambiguously the right pick among the search scrapers.

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 guidance on how to narrow results (country, job_type, days, remote) and ordering (sort), plus a cost-motivated caution to keep max_results modest. It lacks explicit when-not-to-use or alternative-tool routing, but there is no competing sibling for this resource.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds concrete behavioral context: it fetches via ScrapeUnblocker API, returns a specific JSON structure {url, count, elements:[...]} with ready-to-use selectors, and that it replaces raw HTML. It doesn't cover error cases or rate limits, but the safety profile is already annotated, so a high score is warranted.

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, no wasted words. The purpose is front-loaded, followed by the output format and usage guidance. Every clause contributes to the agent's decision-making.

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, so the description compensates by specifying the return JSON shape ({url, count, elements:[...]}) and that selectors are ready-to-use. It covers the essential workflow (discover then drive). Minor omissions like pagination or error behavior are acceptable for a read-only inspection tool.

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 fully documents all 5 parameters. The description does not add parameter-level detail beyond the schema, but it does mention the `steps` param of fetch_html as a follow-up, which is tangential. Baseline 3 is appropriate given the schema's thoroughness.

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 ('Fetch a page... return its interactive elements') and resource (ScrapeUnblocker API). It explicitly contrasts with raw HTML and names the sibling fetch_html, making it clear this tool is for element discovery rather than general page fetching.

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?

Provides explicit usage direction: 'Use it to discover what to target, then drive the page with the `steps` param of fetch_html.' This tells the agent when to use this tool and points to the alternative for subsequent actions, leaving no ambiguity.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds genuinely new behavioral context: 'Free - it calls nothing', which tells the agent there is no network cost or side effect, plus the no-argument default behavior.

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

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

Front-loaded with purpose and routing guidance before the long enumeration of supported sites. The site list is somewhat bloated but serves real discovery value for an agent judging coverage. Every sentence carries information.

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

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

There is no output schema, so the description must convey returns; it does, describing the listing format, the required-parameter marker, and the single-plugin docs mode. Combined with full schema coverage, an agent has enough to call it correctly, though the handoff to run_plugin is not spelled out.

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. The description goes further by explaining the interaction of the three optional params: no arguments lists all plugins, `category`/`search` narrow the list, and `name` returns one plugin's full parameter docs, plus the '* = required' convention used in the output.

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 ('List ScrapeUnblocker's ready-made site plugins') and immediately clarifies what a plugin is ('scrapers for specific sites that return clean structured JSON'). It also differentiates from the sibling fetch_html by noting a plugin returns data already parsed.

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 routes the agent: 'Check here before scraping a known site with fetch_html'. That is a clear when-to-use with a named alternative. It does not, however, mention run_plugin, which is the sibling that actually executes a discovered plugin, leaving the discovery-to-execution step implicit.

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

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

Annotations already cover readOnly/openWorld/destructive, so the description is free to add operational context - the billing model ('billed like an API request', one unit per result page) and the consent-wall proxy behavior. These are genuinely beyond the annotations. The stray 'keep max_results modest' advice references a parameter this tool doesn't expose, which slightly muddies the picture.

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 payoff (the field list) and is dense with no filler, so the long enumeration earns its place given there is no output schema. Minor redundancy in stating 'as JSON' then 'Returns JSON', and the max_results sentence refers to something outside this tool's 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?

With no output schema, the description correctly compensates by enumerating return fields, and it covers identification methods, proxy/consent behavior, and billing. The only gap is the irrelevant max_results note, but nothing needed to call the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents gl, hl, raw, url, place_id, feature_id, and proxy_country. The description mostly restates the identification parameters (place_id 'ChIJ...', feature_id '0xHEX:0xHEX') rather than adding syntax or constraints beyond the schema, 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 action and resource: 'Returns the full data for one Google Maps place as JSON', and enumerates the returned fields. The 'one place' scope cleanly distinguishes it from the search-oriented siblings (google_local, google_search) without needing to name them.

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?

Explains the three ways to identify a place (place_id, url, feature_id) and notes feature_id is fastest, which is useful invocation context, but never states when to reach for this tool versus a sibling like google_local or when-not to use it. Usage is implied rather than routed.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely useful context beyond that: each run is billed like an API request and listing plugins bills per result page, plus the advice to keep max_results modest.

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 purpose, then usage, then billing in a tight sequence with no filler. Slightly dense in the middle with the example list, but every clause (examples, list_plugins pointer, billing) carries navigational or cost 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?

With no output schema, the description states it returns the plugin's JSON, and it covers the two hard parts of calling this tool: discovering the plugin name/params and anticipating cost. For an open-world, enum-heavy dispatcher this is nearly complete; only a note on error or rate-limit behavior is absent.

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 would be 3, but the description adds real semantics: params must use the snake_case parameter names that list_plugins exposes, and a list value is acceptable wherever a parameter takes several. That is meaning beyond the schema's generic anyOf array definition.

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 ('Run one ScrapeUnblocker site plugin and return its JSON') and then anchors it with concrete examples (Target/Walmart search, Zillow listing search, Google Trends, App Store reviews). An agent can immediately tell this is the generic plugin executor, distinct from list_plugins, fetch_html and google_search.

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 directs the agent to 'Find the plugin and its parameters with list_plugins first', which is a real prerequisite and names the sibling. It lacks an explicit contrast against fetch_html/fetch_parsed/google_search for when a dedicated fetch or search tool is preferable, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnly and openWorld, so safety is covered. The description adds meaningful behavioral detail beyond that: the billing model ('billed like an API request'), that listing plugins bill per result page fetched, and how pagination interacts with cost. It does not mention rate limits or auth, but the cost/pagination behavior is a genuine value-add.

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 and response shape, which is good, but the middle sentence is a dense run-on packing pagination and seven filters into one line. It is informative but not tightly structured, and the filter list partly duplicates 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?

With 11 params, no output schema, and no annotations for return shape, the description appropriately documents the response structure (company summary fields, reviews array fields) and pagination mechanics. The billing note covers a real concern for a scraping tool. It could mention rate limits or failure modes, but it is largely complete.

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 parameters are already documented. The description reinforces the key semantics - page/pages with 20 reviews per page, stars/sort/language/date/search/verified/replies as filters - but adds little syntax beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (scrape/returns) and resource (a company's Trustpilot profile and reviews) and names the required identifier. Clearly distinct from siblings like amazon_reviews, which target a different source.

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?

Implied usage is scraping Trustpilot reviews for a domain, but the description never says when to prefer this over alternatives or when not to use it. It does add the billing note about keeping max_results modest, which offers practical guidance on volume rather than tool selection.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely non-obvious behavior: API-style billing where listing plugins charge one unit per result page fetched, which materially affects how an agent should size max_results.

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 verb and resource, then return shape, then controls, then cost. No filler and nothing repeated unnecessarily.

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, but the description compensates by enumerating the returned product fields and the JSON format. Combined with full schema coverage of all 7 params and the billing note, an agent has what it needs; only cross-sibling selection guidance is absent.

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 per-parameter descriptions including defaults and enum-like sort values, so the schema carries the burden. The description only restates sort/min_price/max_price/max_results at a high level and adds no format or edge-case detail beyond 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+resource ('Searches Walmart for `query`') and enumerates the exact return fields (name, price, wasPrice, rating, reviewCount, brand, seller, availability, image, url), which immediately distinguishes it from amazon_search/ebay_search/google_shopping siblings on the same platform-search axis.

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 usage context: sort with `sort`, narrow with `min_price`/`max_price`, and gather up to `max_results` across pages, plus a cost-driven caveat to 'keep max_results modest'. It does not, however, say when to prefer this over the sibling marketplace searches.

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

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

Annotations already establish readOnly/openWorld/non-destructive, so the bar is lower, and the description adds real value beyond them: it discloses billing behavior ('billed like an API request; one unit per result page') and advises keeping max_results modest. It stops short of stating pagination mechanics 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?

Front-loaded with purpose, then return shape, then filtering and billing. The field enumeration is long but each item is informational; the billing sentence earns its place. Minor verbosity in the field list.

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 admirably enumerates the returned fields, and it covers filtering, pagination, and cost. The only notable gap is the unexplained `proxy_country` parameter, which an agent cannot infer.

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 baseline is 3. The description restates the `type` and `sort` option sets and notes pagination behavior for `max_results`, but adds no syntax or semantics beyond the schema and says nothing about `proxy_country`.

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?

Opens with a specific verb+resource: 'Searches YouTube for `query` and returns the results as JSON.' It also enumerates the returned fields, clearly separating it from the sibling youtube_transcript (search results vs. transcript).

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: it explains how to filter with `type`/`sort` and how to control volume with `max_results` and a billing caution. There is no explicit guidance on when to pick this over siblings like youtube_transcript or google_search, nor any exclusions.

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint=false, and the description adds real context: the exact return shape, auto-generated caption flag, availableLanguages, and the billing model (one unit per API request). The trailing note about 'listing plugins bill one unit per result page they fetch, so keep max_results modest' references a parameter this tool does not have, which is stray noise rather than contradiction.

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

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

One dense, well front-loaded paragraph that leads with the return contract before inputs and cost. It is efficient overall, but the billing sentence about listing plugins and max_results is irrelevant to this tool and costs it a point.

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 full burden of describing return values and does so completely (segments with start/dur/text, joined text, language metadata, video metadata). Combined with full parameter coverage, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents lang, video, format and proxy_country; the description only re-summarizes video (id or URL) and lang. Baseline 3 is appropriate since it adds minimal meaning beyond 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+resource (returns a YouTube video's captions) and enumerates the exact return fields, so it is unmistakable against youtube_search or fetch_html. An agent knows precisely what this produces 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 intake guidance ('Pass a video id or any YouTube video URL') and named use cases (LLM/RAG pipelines, subtitles, content analysis), plus a language-selection condition. It never names an alternative tool or states when not to use it, so it stops short of the top band.

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

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

Annotations cover the safety profile (readOnly, openWorld, non-destructive), and the description adds genuinely useful behavior: the per-page billing model, the advice to keep max_results modest, and a detailed handling of apartment-building rental results (isBuilding, no zpid, lotId, rent range, units/availableUnits). That is well beyond what the structured fields convey.

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 and return shape before moving to filters, sorting and the rental edge case, with no filler sentences. It is dense and slightly long, but each clause (billing, building results) carries information an agent would otherwise miss.

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 takes on the burden of describing return fields and does so thoroughly, including the anomalous isBuilding result shape. Combined with the billing note, an agent has everything needed to call this correctly and cheaply.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented in the schema; the description mostly restates the same filter names without new syntax or format detail. Baseline 3 is appropriate for a fully-covered schema where the description only echoes the 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?

Opens with a specific verb+resource (searches Zillow for a location) and enumerates the exact fields returned, so an agent knows precisely what it gets back. It is the only Zillow-family tool among the siblings, and the listing/scraping scope is unmistakable.

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 in-tool guidance: which parameters filter (status, price range, beds/baths, home_type), which sorts, and how max_results collects across pages. It does not, however, say when to prefer this over neighbouring tools such as booking_hotels or google_search, so the routing guidance stops short of exclusions.

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