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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), and the description usefully adds the proxy-routing model, IP-derived currency behavior, and the `exitCountry` reporting detail. However, the closing sentence about billing says 'keep max_results modest' even though this tool has no max_results parameter — a confusing artifact that undercuts otherwise good behavioral disclosure.

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 field enumeration is front-loaded and earns its place given there is no output schema, but the text repeats 'Returns JSON' twice and ends with an off-topic billing/max_results sentence that has no bearing on this tool. Slightly bloated and not cleanly structured.

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-shape burden and adds proxy, currency, and billing context. Gaps remain around failure behavior (invalid ASIN, unavailable product) and rate limiting, but the essential call-time information is present.

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 beyond it by explaining why `proxy_country` defaults to the marketplace's home country (currency consistency) and that the serving proxy is echoed as `exitCountry`. That causal context is not present in the schema and materially helps an agent choose parameter values.

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 and resource ('Fetches a single Amazon product') and immediately enumerates the returned fields, so it is clearly distinguishable from amazon_search (list) and amazon_reviews (reviews) siblings. An agent knows exactly what this returns 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 identify a product ('either `asin` (plus `marketplace`) or a full product `url`'), which is input selection rather than tool selection. It never says when to prefer this over browse_page, fetch_html, fetch_markdown, or amazon_search for the same URL, so usage is only implied by the single-product framing.

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 read-only and open-world safety, but the description goes further: it explains that only 5 to 13 signed-out reviews are available, that gated pages return reviewsGated=true with an empty reviews array while rating and histogram still come back, that every field is present and null when absent, and that billing is per request or per result page.

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 return shape is front-loaded and the caveats follow in a logical order (scope, gating, nulls, proxy, billing). It is dense and long, but each sentence carries a fact an agent needs; the items are packed into long parenthetical lists, which slightly hurts readability.

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

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

For a scrape tool with no output schema, the description fully covers unknown return shape, the gating edge case, null semantics, proxy behavior, and cost. Nothing an agent needs in order to call it or interpret the result 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 both identity parameters and proxy_country are already fully documented. The description restates that asin/marketplace or url identifies the product and notes exitCountry, but adds no syntax or constraint beyond the schema. The baseline of 3 is appropriate.

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

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

The first sentence names a specific verb and resource: it returns the review data an Amazon product page shows to a signed-out visitor, as JSON. The scope constraint (public slice, not a full export) separates it from amazon_product and any bulk review export tool without needing the sibling's schema.

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

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

It states the context clearly: use this tool when you need the reviews, rating, histogram, or customers-say summary for an Amazon product, given an ASIN/marketplace or url. It also explains when coverage is limited (reviewsGated). However, it never names an alternative tool or an explicit exclusion, such as 'for product details use amazon_product'.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context beyond that: it is free, 'calls nothing', explains the '*' required marker, and describes what each argument mode returns. Minor gap: it doesn't say how large the full plugin list is or whether results are paginated.

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

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

Front-loaded with the core purpose and the decision rule, with operational details after. The long parenthetical list of example sites is somewhat verbose but earns its place by making the tool discoverable for site-specific queries.

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 must explain return behavior; it does: no arguments lists every plugin with parameters, name returns full parameter docs, and plugins return clean structured JSON. Nothing essential 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 baseline is 3, but the description adds real semantics beyond the schema: the default no-argument behavior, the narrowing effect of category/search, that name returns one plugin's full parameter docs, and that '*' means required. This is meaningful added value.

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 ... site plugins') and immediately clarifies what a plugin is: a scraper for a specific site returning parsed JSON. It also names the sibling it replaces for known sites ('fetch_html'), so an agent can distinguish it 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?

Explicitly says to check here before scraping a known site with fetch_html, and explains the three narrowing modes: no args for all plugins, category/search to narrow, name for one plugin's full docs. When-to-use and alternatives are both stated.

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 safety hints provided in the annotations, the description adds valuable behavioral context, such as the nature of the output (JSON), the operational constraint of the `proxy_country` default (clearing Google's consent wall), and the billing model.

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 highly dense with information, but it is structured effectively. It leads with the output format, then provides input identification methods, followed by operational constraints.

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

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

Given that there is no output schema, the description is remarkably complete by listing the specific fields returned (name, address, rating, hours, etc.). This gives the AI agent a full mental model of what the tool produces.

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?

Despite 100% schema coverage, the description adds significant value by clarifying the expected formats for the identifiers (`place_id` e.g., 'ChIJ...', `feature_id` e.g., '0xHEX:0xHEX') and explaining the functional requirement of the `proxy_country` parameter.

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 explicitly states the purpose is to return the 'full data for one Google Maps place as JSON.' It clearly differentiates itself from broader search tools by focusing on scraping detailed attributes from a specific identifiable 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?

The description provides detailed usage advice by stating that `feature_id` resolves a place directly and is 'location-neutral.' It also gives critical operational advice regarding billing ('keep max_results modest').

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 (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description adds genuinely non-obvious context: each run is billed like an API request and plugin listing bills per result page, with advice to keep max_results modest. It does not describe error behavior when a plugin name/param combination is invalid, which matters for a pass-through executor.

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

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

Front-loaded with the core action, then prerequisites, then param conventions, then cost caveats — a logical ordering with no filler. The example list is slightly long for the space it occupies, though it does aid recognition of what 'plugin' means.

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 states the return is the plugin's own JSON, which is appropriate since the shape necessarily varies by plugin. Combined with the discovery prerequisite and cost semantics, an agent has what it needs to call this correctly; only failure-mode 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 coverage is 100%, so the enum and object shape are already documented; the description still adds value by stating params use the exact snake_case names list_plugins reports and that array values are acceptable where a parameter takes several. It does not flag whether unknown/extra param keys are rejected, despite additionalProperties=false on the outer object.

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 plus resource ('Run one ScrapeUnblocker site plugin and return its JSON') and grounds it with concrete examples (Target/Walmart search, Zillow listings, Google Trends, App Store reviews). An agent immediately understands this is the generic executor behind the plugin catalog, which is materially different from the named sibling wrappers like amazon_search or zillow_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?

'Find the plugin and its parameters with list_plugins first' is an explicit prerequisite that routes the agent through the correct discovery tool before invocation. It does not explicitly say when to prefer run_plugin over the dedicated sibling tools (amazon_search, walmart_search, youtube_transcript), which is the one real ambiguity given both exist side by side.

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.