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 declare destructive=true, idempotent=false and openWorld=true, so the bar is lower. The description still adds real value: steps run once per call, failures report which step failed plus the page HTML at that moment for retry, and billing is one request — context the annotations do not 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-loaded purpose sentence followed by a labeled 'Workflow:' segment and failure semantics; every sentence contributes. It is dense but slightly long, and the mid-sentence parenthetical action list is redundant with the step 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?

For a 7-param tool with a nested anyOf `steps` array and no output schema, the description covers failure returns, billing, and step-construction workflow. Minor gaps remain: optional knobs like proxy_country and wait_method/sleep_seconds are only explained by the (fully covered) schema, not the prose.

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 carries parameter documentation and the baseline is 3. The description adds meaning beyond the schema by explaining how `steps` should be constructed (discover selectors with `list_elements` first) and that steps execute once, which shapes how an agent authors the array.

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 first sentence names a specific verb chain (load in a real browser, run ordered actions, return HTML) and the resource (ScrapeUnblocker-backed page render). It clearly differentiates from siblings by emphasizing interaction, and the title reinforces the two-phase behavior.

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?

Explicit workflow routing: call `list_elements` first to discover selectors, then build `steps`. It also states a when-not ('never use them to buy, post, delete or change anything unless the user asked'), and names the prerequisite tooling, leaving little to inference.

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

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 readOnly, openWorld, and non-destructive behavior. The description adds meaningful context beyond that: anti-bot bypass, real browser rendering, and raw HTML output. It does not contradict the annotations, though it omits rate-limit or failure-mode details.

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 main action and return format, then gives concise routing guidance for alternatives. Every sentence has a clear purpose with no wasted prose.

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 tool is open-world and has six parameters, but the schema fully documents them and annotations cover safety. The description supplies the missing high-level behavior and return type, making it complete enough to call 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 the schema already documents all six parameters thoroughly. The description does not add parameter-specific meaning beyond what is already in the schema, which is acceptable at baseline 3.

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

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

The description gives a specific verb and resource: fetching fully rendered HTML of any web page via ScrapeUnblocker. It explicitly states the return format and distinguishes sibling tools like fetch_markdown and browse_page.

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 concrete conditions for use: normal fetch blocked by 403/429, captcha, access denied, or when a real browser is needed to render. It also routes users away to fetch_markdown for reading/summarising and browse_page for interactions.

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/non-destructive, and the description adds real context beyond them: real browser rendering, the size reduction (2-25% of HTML), that it defeats 403/429/captcha blocks, and the billing unit ('one request'). These are operational traits an agent cannot get from 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?

Four dense sentences, front-loaded with what it returns, then capabilities, then the sibling routing rule, then cost. Every sentence carries distinct information and none repeats the schema or annotations.

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?

Despite no output schema, the description specifies the return format precisely (clean Markdown, absolute links, stripped chrome), covers failure/blocking scenarios, and states the billing model. An agent has everything needed to invoke it correctly and interpret the result.

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

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

Schema description coverage is 100% and every parameter is documented in the schema, so the baseline is 3. The description only gestures at the render-wait capability ('browser steps') and adds no syntax or defaults beyond the schema, so it neither helps nor hurts.

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 (fetch a web page, return clean Markdown) and immediately specifies the output shape: main content with absolute links, no scripts/styles/nav/footer. It also names the sibling it is not — fetch_html — so an agent can distinguish them without opening either schema.

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

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

Gives explicit use cases ('read, quote or summarise a page') and an explicit routing rule with the alternative: 'Use fetch_html instead when you need the markup, selectors or browser steps.' It also names the conditions that select this tool (JS-rendered pages, 403/429, captcha). Nothing 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.

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), and the description adds genuinely non-obvious behavior: the graceful degradation to rendered HTML when no structured data exists, plus a billing implication tied to fetch_html. It does not discuss rate limits, proxy/auth requirements, or latency, so it is strong but not exhaustive.

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

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

Three tight sentences: capability and output format first, target use case second, fallback/billing caveat last. Every clause carries information an agent needs, with no restatement of the title or 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 carries the return-value burden by describing structured JSON, its fallback, and cost behavior. The one remaining gap is that the shape of the parsed JSON (field naming, nesting) is left unspecified, though that is arguably discoverable from the response itself.

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

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

Schema description coverage is 100%, so url, rules_hint, and proxy_country are already fully documented in the schema. The description implies rules_hint's guiding role but adds no syntax, format, or edge-case detail beyond the structured fields, so the baseline of 3 applies.

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

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

Specific verb (fetch) plus explicit output contract: AI-parsed structured JSON rather than raw HTML, with examples (product details, article content). It implicitly distinguishes itself from fetch_html by naming that alternative's output format, so an agent can tell the two apart 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?

"Best for extracting fields from product, listing or article pages without writing your own HTML parsing" gives clear positive selection criteria, and the fallback sentence tells the agent what happens on pages lacking structured data. It stops short of an explicit "use fetch_html when you want raw HTML" routing statement, which keeps it from 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 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful scope information that results are organic-only and returned as structured JSON via a third-party unblocker service, but says nothing about rate limits, blocking, cost, or failure modes for that external dependency.

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 filler, with the core action and output format front-loaded and the usage hint second. Nothing is repeated from the name or 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?

For a 3-parameter read-only search with full schema coverage and annotations, this is nearly complete; the only gap is that with no output schema the description does not sketch what the structured JSON contains beyond 'organic results'.

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 keyword, proxy_country and pages_to_check are already fully documented in the schema. The description adds no parameter-level meaning beyond hinting that results are organic; 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 (run a Google search) plus the mechanism (ScrapeUnblocker) and output shape (organic results as structured JSON). It positions itself against the fetch_* siblings by framing itself as a URL-discovery step, but does not distinguish itself from search_and_read or the other search-family 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?

'Use this to discover URLs before fetching them' gives a concrete when-to-use and implicitly chains to the fetch tools. There are no explicit exclusions, so an agent still has to infer whether to pick this over search_and_read or google_shopping.

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 pagination limits ('one render returns the first page'), known data gaps ('no per-product URL, so `url` is omitted and `image` is best-effort'), and billing behavior ('billed like an API request... one unit per result page'). These are exactly the constraints an agent needs before calling.

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

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

Dense and front-loaded: purpose and return shape come first, then configuration, then caveats and billing. It is a long single paragraph, but nearly every clause carries new information an agent would otherwise have to discover by trial.

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 job of listing return fields and does so explicitly, plus flags the omitted/approximate fields. Combined with annotations and full schema coverage, an agent has everything needed to call this 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 all six parameters are already documented, and the description mostly restates the same semantics (region-specific prices, price filters). It adds value on return identifiers (productId/catalogId/offerId stable across searches) but not on parameter meaning, 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?

Names the specific vertical (`udm=28`) and resource ('product cards') and enumerates the returned fields, so the agent knows exactly what this produces. It implicitly distinguishes itself from google_search by scoping to the Shopping vertical, but never explicitly names a sibling as the alternative.

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?

Guidance exists for configuring the call ('set proxy_country/gl to target a market', 'min_price/max_price to filter', 'keep max_results modest'), but there is no statement of when to reach for this over amazon_search, walmart_search, or google_search. Usage is implied by context rather than declared.

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, and the description reinforces with 'Read-only and does not interact with the page' while adding non-obvious context: fetching happens via ScrapeUnblocker (an external proxy service) and the response is a JSON element list with selectors and attributes. It stops short of covering failure behavior (blocked pages, non-HTML content) or proxy fallback, so it is strong but not exhaustive.

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

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

Two sentences, both front-loaded: the first states the action and the return shape, the second supplies the workflow linkage. No filler, and the discovery-only constraint is stated before the sibling hand-off.

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 does describe the return payload (element kinds, selector, tag/text/attributes). What an agent would still want — behavior on blocked or non-HTML pages, and whether element listing is capped — is absent, keeping it just below a 5.

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

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

Schema description coverage is 100% and both parameters (`url`, `proxy_country`) are documented in-schema, so the description need only not contradict them. It mentions loading 'a page' but adds no format or semantics beyond the schema, which lands at the baseline of 3.

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

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

States a concrete verb and resource ('Load a page ... return a JSON list of its notable elements') and enumerates what is returned, including the ready-to-use `selector` per element. The opening verb+resource pair makes it immediately distinguishable from sibling fetch tools such as fetch_html or browse_page.

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 frames the tool as the 'discovery half of interactive scraping' and names the follow-up path: pass matching `steps` to `browse_page`. This gives an agent both when-to-use and the concrete alternative it complements, with no inference required.

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 read-only, non-destructive, open-world behavior, but the description adds the pricing model that no structured field carries: 'Each run is billed like an API request; listing plugins bill one unit per result page they fetch, so keep max_results modest.' It also states the return type (JSON) and how to discover parameter names, which meaningfully reduces misuse risk.

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?

Roughly sixty words in four sentences, front-loaded with the action and its output, then the prerequisite, then the param convention, then the cost warning. No sentence is filler; the billing note directly shapes a calling decision.

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

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

Covers action, discovery path, param conventions, return type and cost for a meta-dispatch tool over 100+ enum values, which is substantial. Remaining gaps are failure modes (invalid plugin/param handling) and the sibling-overlap question; with no output schema, a brief note on response shape would also have helped.

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 would be 3, and the description earns above that by explaining that `params` keys must match the snake_case names list_plugins reports and that list values are acceptable where a parameter takes several — a naming contract the schema's generic `additionalProperties` object cannot express. It stops short of describing what happens on unknown parameter names.

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 immediately grounds it with four concrete examples spanning search, listings, trends and reviews. It also names its companion tool (list_plugins) so an agent can distinguish discovery from execution 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 a clear prerequisite workflow: 'Find the plugin and its parameters with list_plugins first.' That is explicit and actionable. However, it never resolves the obvious overlap with siblings that share plugin names (amazon_search, walmart_search, zillow_search, indeed_jobs, google_images) — an agent cannot tell from this text whether to call run_plugin(name="amazon_search") or the dedicated amazon_search 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?

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint. The description adds real context beyond them: the response composition (AI Overview, per-page Markdown, organic title/URL/snippet) and the cost model (one request plus one per page read). It stops short of noting auth, rate limits, or failure modes.

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, fully front-loaded with the action and the return shape before the usage hint and billing note. Every clause carries information; the docs link earns its place as a reference.

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 does the work of describing returns (AI Overview, Markdown pages, snippets) and pairing that with the billing model. Combined with annotations covering the safety profile, nothing critical for correct invocation 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 documents all three parameters, including min/max bounds. The description restates the `results` default and cap but adds nothing about `proxy_country` or query formatting, so baseline 3 is appropriate.

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

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

States a specific compound verb (search Google + read top results) and the exact resource, and crisply describes what it returns. The 'in one call' phrasing implicitly distinguishes it from the search-only and fetch-only siblings like google_search and fetch_markdown.

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?

"Use it to answer a question from the live web" gives a clear use context, and the compound nature of the tool implies when it beats a plain search. However, it never names an alternative such as google_search or fetch_markdown, nor states when not to use it, so it lacks explicit 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 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 cover the read-only/safe profile, and the description adds real behavioral context beyond them: the billing model ('Billed like an API request'), the output shape, and the language-prefix matching behavior. The closing clause 'listing plugins bill one unit per result page they fetch, so keep max_results modest' is a copy-paste artifact — this tool has no max_results parameter — which injects mild noise, keeping it from 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?

A single dense paragraph that front-loads the return contract, then input forms, then use cases, then cost — a sensible order with no wasted sentences. It loses a point for the trailing `max_results` billing clause, which belongs to a different tool family and should have been trimmed.

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

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

With no output schema, the description does the heavy lifting by enumerating returned fields, and it discloses billing and language-fallback behavior for a 4-parameter read-only tool. What's missing is error/empty behavior (no captions available, region-blocked video) and whether cost scales with video length or segments, which matters given the stated per-request billing.

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 all four parameters are already documented in the schema, establishing a baseline of 3. The description reinforces the `video` and `lang` semantics ('Pass a video id or any YouTube video URL', 'choose a caption language with lang') but adds no format or proxy_country guidance beyond what the schema already says.

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 upfront: 'Returns a YouTube video's captions as JSON', then enumerates the exact return fields (segments, text, availableLanguages, isAutoGenerated, title, author, lengthSeconds). The purpose is unmistakable, though it never explicitly contrasts itself with youtube_search or browse_page, so the sibling differentiation comes mostly from the tool name.

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 usage contexts ('Ideal for LLM/RAG pipelines, subtitles and content analysis') and tells the agent what input forms are accepted ('Pass a video id or any YouTube video URL'), plus how to pick a language. But there is no explicit when-to-use-this-vs-youtube_search guidance and no statement of what happens when a video has no caption tracks at all, which is the main failure branch an agent must anticipate.

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.