HasData

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

Annotations already declare readOnly, non-destructive, and open-world behavior, so the safety profile is covered. The description adds genuine value beyond annotations by disclosing pagination via nextPageToken and listing the returned fields (id/url, price per night and total, rating, reviews, coordinates, photos), which matters since there is no output 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?

Lead sentence is front-loaded with the core action and search dimensions, followed by the return payload and use cases. Content is dense but each part contributes; no meaningful padding.

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

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

With 12 parameters at full schema coverage, annotations covering safety, and no output schema, the description usefully compensates by enumerating return fields and pagination. It is essentially complete for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema, including the location-vs-bounding-box interaction. The description adds only a high-level restatement of the search dimensions, so 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?

States a specific verb and resource: searches Airbnb for available stays by location/bbox and date range. It is clearly a list/search operation, distinguishable from the sibling getAirbnbPropertyDetails (detail lookup). It does not name or contrast the sibling explicitly, so it stops 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?

Provides domain use cases (travel planning, rental market analysis, pricing research, lead lists), which implies when the tool is valuable. However, it offers no when-not-to-use guidance and does not route the agent to the sibling details tool for single-property lookups. Use cases are present but routing guidance is absent.

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 that this is a full-page fetch keyed by a valid listing URL, but discloses no rate limits, auth requirements, or edge-case behavior, so the marginal behavioral value is modest.

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

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

Front-loaded with purpose, then return contents, then use cases – a sensible order. The use-case list is slightly long and marketing-flavored, but each clause carries routing value, so it is efficient without being maximally tight.

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

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

With no output schema, the description carries the return-value burden and does list the major returned fields (title, location, rating, host, room/bed/bath, photos, amenities). It is complete enough to call correctly; only marginal items like error cases are 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% and the single 'url' parameter is fully documented in the schema as needing a valid Airbnb listing URL. The description's 'by listing URL' phrasing is a restatement rather than added syntax or format guidance, so baseline 3 applies.

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

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

Specific verb+resource: 'Fetches the full Airbnb property page by listing URL', then enumerates the returned fields. It also implicitly distinguishes itself from the listing-search sibling by describing this as enrichment of 'listings discovered via the listing-search endpoint'.

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?

Clear context is given through named use cases (travel planning, rate research, photo/amenity enrichment, compliance audits) and it references the listing-search endpoint as the discovery path. It does not state explicit when-not or failure conditions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: delivery-zone-aware pricing when a zip/location is set, and the fact that the other-sellers block only appears when otherSellers=true. It omits the credit cost (that lives only in the schema) and any rate-limit or failure 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?

The purpose sentence is front-loaded and the alternative/conditional notes come after. The long enumerated list of return fields and the use-case tail make the second paragraph dense, but since no output schema exists the field enumeration is largely earning its place.

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

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

With no output schema, the description usefully enumerates the returned fields (price, Buy Box seller, variants, offers block) and covers the main conditional behaviors, making it callable with confidence. It leaves out cost/credit implications for the extra request and any pagination or error handling, which are minor for a single-item fetch.

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 tying parameters to outcomes — the otherSellers=true flag producing the other-sellers offers block and the zip/location inputs enabling zone-aware pricing. That conditional linkage adds meaning beyond the flat field descriptions.

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

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

The description states a specific verb and resource ('Fetches a single Amazon product page by ASIN') plus the domain scope, which cleanly separates it from the sibling tools that fetch reviews, search results, or seller data. An agent can identify the tool's job without opening the schema.

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

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

It names concrete scenarios (price/stock monitoring, catalog enrichment, listing QA, Buy Box tracking, cross-locale analysis) and flags the conditional otherSellers=true path, giving clear context for when to reach for it. It stops short of explicit exclusions or naming a sibling to prefer instead, so it does not reach 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 establish readOnlyHint=true and destructiveHint=false, and the description usefully adds that the fetch is paginated and enumerates the returned fields (title, body, stars, author, media URLs, rating histogram). It omits page-size limits, rate limits, and auth requirements, so it is above baseline 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?

It is front-loaded with the action and scope before diving into filter and return-value detail, and the two sentences map well onto the tool's two concerns. The second sentence is quite dense and partly padding ('feeding review-summarization or Q&A agents'), but overall it earns its length for a 10-parameter tool.

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

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

With no output schema, the description correctly compensates by enumerating the returned review fields and the aggregate rating histogram, and it discloses pagination coverage. It lacks details on page-size behavior, maximum pages, or rate limiting, which are the remaining gaps for a network-bound external fetch.

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 7 of 10 parameters are enums, so the schema already documents filter semantics fully. The description restates the filter families (star rating, reviewer type, media-only, format, keyword, sort) but adds no syntax, defaults, or interaction 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?

The description names a specific verb and resource ('Get Amazon Product Reviews') and immediately scopes it to a single Amazon ASIN, which cleanly separates it from the sibling tools dealing with product details, search results, and sellers. An agent can identify the resource and granularity without opening the schema.

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

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

It lists concrete use cases (voice-of-customer analysis, sentiment extraction, competitor benchmarking, review-summarization agents) that make the intended context explicit. However, it never names an alternative tool or a condition under which a different sibling (e.g. product details) should be preferred, so routing guidance is incomplete.

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), and the description adds real context beyond them: the returned fields (ASIN, price, list price, Prime/sponsored flags, position), pagination behavior, and location/zip scoping. It does not mention auth requirements, rate limits, or result caps, which keeps it short of a 5.

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

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

Front-loads the purpose in the first sentence and the return shape in the second, with no filler. The second sentence is dense with field enumerations but each clause carries information; only slight trimming would improve it.

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 listing the returned fields, and it covers pagination, sorting, and location scoping for a seven-parameter tool. Auth/permission and result-limit details are absent, but for a read-only public search endpoint the definition is otherwise sufficient to invoke 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 all seven parameters are already documented in the schema, including enums for domain, sortBy, and language. The description restates the sort options in human-readable form and mentions delivery scoping, but adds no syntax or format detail 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 verb (keyword search) and resource (Amazon results on a chosen domain) and enumerates the scope knobs (pagination, delivery location, sort order). The sibling set is all product/review/seller detail lookups, so the search-SERP framing clearly distinguishes this tool from 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?

Explicitly lists usage contexts: SERP monitoring, share-of-shelf tracking, competitor discovery, ASIN harvesting to feed the product/reviews endpoints, and price-comparison agents. The mention of feeding downstream product/reviews endpoints implicitly routes the agent away from this tool for detail lookups, but no explicit when-not-to-use statement is given.

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 structurally. The description adds useful behavioral context by characterizing the profile as 'public' and enumerating the returned fields (ratings breakdown, feedback counts, address, contact, customer service), though it omits auth requirements, rate limits, and pagination.

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 verb and resource, then supplies return detail and use cases in a logical order with no filler. The opening line duplicates the title, and the return-field inventory plus five-item use-case list push length, but each element is informative.

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 enumerated return fields replace what an output schema would normally provide, and the annotations cover the safety profile. Three parameters at 100% coverage leaves nothing material about calling the tool unexplained.

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

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

Schema description coverage is 100% and both enums (domain, language) are self-documented with defaults and constraints. The description only restates sellerId and the domain/language selection, adding no format, range, or dependency detail 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 verb ('Fetches') and resource ('public storefront profile for an Amazon seller') and identifies the key ('by sellerId') plus scope ('chosen domain/language'). This is clearly distinguishable from siblings like getProductDetails, getProductReviews, and getSellerProducts, so an agent can route without opening schemas.

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

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

Gives concrete when-to-use scenarios (due-diligence/vetting, brand protection, MAP-violation investigations, leaderboards, directory enrichment), which is strong context. However, it never states when not to use it or names the natural alternative (getSellerProducts for listing a seller's catalog), leaving that inference to the agent.

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 real value beyond them by disclosing pagination behavior and enumerating the returned row fields (ASIN, title, image, URL, price/list price, currency, rating, review count). It omits auth/prerequisite and rate-limit details, 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?

The core scoping sentence is front-loaded and dense with useful detail, and the use-case list is compact. The opening 'Get Amazon Seller Products' restates the title rather than adding information, which is minor waste but slightly dilutes an otherwise efficient structure.

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 pagination and the domain/seller scoping. It does not explain how pagination terminates (total pages/next page) or output envelope, which would help since no output schema exists.

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

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

Schema description coverage is 100%, so page, domain, language, and sellerId are all documented in the schema with enums for domain and language. The description only echoes sellerId and 'chosen domain' without adding format, default, or interaction detail 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 and resource (paginated listing of a seller's storefront catalog by sellerId/domain) and distinguishes it from neighbors by pointing to the product and reviews endpoints for per-ASIN drill-downs. An agent can tell it apart from getSellerDetails, getProductDetails, and getSearchResults without opening any schema.

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

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

Gives explicit usage contexts (mapping a competitor's assortment, detecting SKU launches, building watchlists, price-intelligence, seeding deep-dives) and names the sibling endpoints for follow-up. It stops short of stating when NOT to use it (e.g., single-product or keyword lookups), so it is clear context rather than full when/when-not routing.

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/non-destructive, lowering the bar. The description adds genuine behavioral detail: the returned fields (title, url, snippet, displayed url, position) plus related searches, and the location/lat/lon precedence rule. It omits rate limits and rate/error behavior, 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?

Two tightly packed sentences: purpose first, then parameter scope, return contents, and use cases. Every clause earns its place and nothing is repeated or padded.

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

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

With no output schema, the description correctly compensates by describing the return shape (organic results plus related searches). Annotations cover the safety profile and the schema covers all parameters, so the definition is nearly self-sufficient; minor gaps like pagination limits or proxy behavior are not covered.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema does the heavy lifting. The description still adds value by grouping the 11 parameters into functional clusters (geo, market, country, safesearch, language, filters, device, pagination), which helps an agent reason about interactions even though the individual semantics live in the schema.

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

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

States a specific verb and resource ('Fetches Bing SERPs for a query') and immediately enumerates the functional scope: geo targeting, market, country, safesearch, language, filters, device, and pagination. There are no sibling tools to disambiguate against, but the purpose is unambiguous and complete.

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

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

Provides clear positive use cases ('SEO rank tracking, SERP feature monitoring, Bing-specific visibility audits, and training/eval data for search agents'). It gives strong context for when to reach for the tool, but offers no exclusions or alternatives (none exist among siblings), so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds real value by enumerating what is returned (identity, policies, price, rating, photos, room suites) and noting prices/availability are real-time, though it says nothing about auth, rate limits, or error cases.

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

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

The opening line 'Get Booking Hotel Details' merely restates the title and is wasted space. The remainder is a dense but informative sentence followed by a use-case list; it is not bloated, but the redundant lead-in and heavy enumeration keep it from being tightly front-loaded.

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 of explaining return values, and it does so thoroughly (identity, policies, price, rating, photos, room suites). For a read-only detail endpoint it is essentially complete, missing only error/failure behavior.

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 restates the stay-date and guest-composition inputs but adds no syntax, format, or constraint detail beyond what the schema already provides, making the baseline 3 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 (fetches) and resource (a single Booking.com property by full URL), and explicitly distinguishes itself from the sibling search endpoint by describing this as the 'fetch full details after discovering the property URL via the Booking Search endpoint' step.

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 four concrete use cases (enrich listings, monitor a competitor, validate amenities/photos, fetch details after search) and names the discovery-then-detail workflow with the sibling tool. It lacks explicit when-not-to-use exclusions, so it falls 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 cover the safety profile (readOnlyHint, openWorldHint, destructiveHint=false), so the bar is lower. The description adds genuinely useful behavior beyond them: page-based pagination at 25 results/page, plus a detailed return-shape summary (price semantics, rating, policies, photo) that compensates for the absent output schema. It omits rate limits and auth requirements, keeping it short of a 5.

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

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

Front-loads purpose in the opening line and wastes little, but the body is a single dense run-on sentence enumerating filters and return fields, some of which restate the schema. Efficient overall, with mild redundancy in the return-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?

For a 28-parameter search tool with no output schema, the description does the heavy lifting: it outlines the filter dimensions and describes the returned hotel fields, so an agent knows what comes back. Only operational details like error behavior or rate limits are missing, which is a minor gap.

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

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

Schema description coverage is 100%, so the schema already documents all 28 parameters including pagination, locale, price bounds and child ages. The description adds no syntax or constraint detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Searches Booking.com for accommodations') and enumerates the scope precisely (destination keyword, stay dates, guest composition, rich filter list, pagination, locale). It also names the sibling endpoint it feeds into (`hotelId`/URL into Booking Place), so an agent can distinguish search from place-details 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 names target scenarios (travel-planning agents, OTA price/inventory monitoring, competitor analysis, lead-gen) and routes to the sibling when full property details are needed. It stops short of stating exclusions or prerequisites (e.g. valid date/guest constraints beyond what the schema enforces), so it is clear context rather than a complete routing rule.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description goes well beyond that by disclosing statelessness (no memory of earlier requests), that language follows the prompt, that web search is conditionally triggered, and that every consulted source is returned with full metadata. This is meaningful behavioral context an agent needs to invoke it correctly.

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

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

The opening sentence is a dense list of return fields, then usage guidance follows, so it is reasonably front-loaded and every sentence carries information. It is close to the upper bound of comfortable length for a two-parameter tool, costing a point against truly tight 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?

There is no output schema, yet the description fully specifies the return payload (answer, sources with metadata, links, title, model, search flag), plus behavior and usage. Nothing an agent needs to select or call the 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 description coverage is 100%, so both parameters are already fully documented in the schema (character limit, language behavior, IANA timezone framing). The description restates the language and timezone semantics but adds no syntax or format detail beyond what the structured fields already provide, so baseline 3 applies.

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

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

States a specific verb and resource (send a prompt to ChatGPT, get the answer) and then enumerates exactly what comes back: markdown answer, web sources with domain/title/snippet/date/thumbnail, inline links, conversation title, model, and search flag. An agent can tell this is a prompt-to-answer Q&A tool rather than a SERP scraper 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 concrete use cases (answer questions with cited sources, ground a RAG pipeline, summarise current events, build datasets) and a key constraint ('a fresh conversation with no memory of earlier ones'). It does not explicitly name the most obvious alternative, hasdata_perplexity_chat_getPerplexityAnswer, or state when not to use it, so it falls short of full when/when-not/alternatives guidance.

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

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

Annotations already declare readOnly=true, openWorld=true, destructive=false, so the safety profile is covered. The description still adds real value beyond that: it discloses what the response contains (organic results, ads, Search Assist AI answer) and the pagination contract — the token is pre-signed, must be used as-is, cannot be constructed, and is absent when there are no more pages. Auth requirements and rate limits remain undisclosed.

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?

Purpose and scope are front-loaded in the first sentence, and the second sentence packs parameters and return shape compactly. The long parenthetical field list is informative rather than wasteful, though it pushes the description toward the verbose side for a fetch call.

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 of describing returns and does so by enumerating the result fields, ads, and AI answer. Combined with the seven fully documented parameters and the pagination caveat, an agent has enough to call this correctly; only operational details like auth and limits are 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%, so the schema already documents every parameter, including that kl takes precedence over cc/setLang. The description's '(kl, or cc+setLang)' is only a light restatement of that precedence and adds no syntax or edge-case detail beyond the schema, 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?

Opens with a specific verb and resource ('Fetches DuckDuckGo SERPs for a query') and the platform qualifier immediately separates it from the Google/Bing SERP siblings. The enumeration of tuning knobs and returned data leaves no ambiguity about what the tool produces.

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

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

Names four concrete use cases ('SEO rank tracking, SERP feature monitoring, DuckDuckGo-specific visibility audits, and training/eval data for search agents'), which gives clear context for when to reach for it. It stops short of naming an alternative (e.g. the Google or Bing SERP tools) or stating when-not to use it, so it doesn't reach the top band.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, open-world). The description adds genuinely useful behavior: the feed is walked three posts per request via pagination.nextPageToken and each request is billed separately. It stops short of describing failure modes or rate limits, so a 4 rather than 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?

Purpose is front-loaded, then return fields, then pagination, then use cases. The long comma-delimited enumeration of returned fields is dense but each item is informative; it borders on oversized but nothing is truly 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 no output schema, the description carries the full burden of explaining return values, and it does so thoroughly — listing all key fields, the nested post structure, and pagination semantics. An agent has everything needed to call and interpret 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 the schema already documents handle formats, the language enum's effect on localized strings, and the pagination token. The description only restates the pagination walk, adding no syntax or edge-case detail beyond the schema. Baseline 3 applies when the schema carries the load.

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

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

The description states a specific verb and resource ('Fetches a public Facebook page or profile by handle') and enumerates the concrete return contents (page id, name, category, likes, followers, posts). An agent knows exactly what it retrieves and at what granularity, with no ambiguity from a sibling set (none exist).

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 explicit use contexts — enrich company/creator records, verify brand reach and contact details before outreach, monitor competitors, build datasets. It does not name when *not* to use it, though the schema does note groups and private accounts are unsupported. Clear context, but no exclusion guidance in the description itself.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by enumerating what the call returns (title, company, rating, location, salary estimate, posted date, description, qualifications/benefits), which is important given there is no output schema. It omits any note on 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?

The core action and resource are front-loaded in the first two sentences, with the use-case list following. The five-item use-case enumeration is somewhat long but still earns its place by orienting downstream consumers; nothing is padded or redundant.

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

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

For a single-parameter read tool with no output schema, the description supplies both the input semantics (vacancy URL) and a solid enumeration of the returned fields, which is what an agent needs to decide to call it. It does not cover failure behavior or URL validation, leaving a small gap.

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

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

Only one parameter and schema coverage is 100%, so the schema already documents the required url field. The description's phrase 'by its vacancy URL' adds only a mild hint about the expected URL shape and nothing about format or validation, so this lands at the baseline 3.

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

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

States a specific verb and resource ('Fetches a Glassdoor job posting by its vacancy URL') and names the returned entity precisely. It is clearly distinguishable from the sibling hasdata_glassdoor_listing_getJobListings, since this one operates on a single posting identified by URL.

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 contexts for use (ATS ingestion, job aggregators, comp benchmarking, company-profile enrichment, LLM matching/resume tailoring), which tells the agent when this tool is appropriate. It stops short of naming an alternative or stating exclusions, so it does not reach 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it describes the returned job fields and notes that nextPageToken pagination preserves the original filters. It does not disclose rate limits or authentication requirements, but that is a minor gap given the annotation coverage.

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

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

The description is front-loaded with a direct statement of purpose, then moves through filters, return values, and use cases in a single efficient paragraph. It is slightly dense and could be better structured with bullet points, but every sentence carries relevant information and there is no filler.

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

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

For a 12-parameter search tool with no output schema, the description is complete enough: it explains the search surface, the returned fields (title, company, location, salary estimate, posted date, job URL, jobId, page tokens), and the pagination behavior. Combined with annotations that cover safety and open-world scope, an agent has what it needs to invoke the tool 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 12 parameters in detail. The description summarizes filter categories (date posted, distance, salary range, company rating, easy apply, remote), sort, domain, and pagination behavior, but adds little semantic detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Searches Glassdoor job listings by keyword and location') and enumerates supported filters and pagination. It also distinguishes itself from the sibling tool:'collect URLs for downstream full-detail scraping via the Glassdoor Job endpoint' points to the separate job-details endpoint.

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 clear usage contexts ('build job feeds, monitor hiring trends for roles/companies/regions, power candidate sourcing tools') and identifies the downstream sibling for full-detail scraping. However, it does not explicitly state when not to use this tool or list alternatives beyond that one reference, so it stops short of the 5-level specificity.

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 behavior beyond that: page-based pagination via ijn and the exact shape of each returned image record. It omits operational caveats such as auth requirements, rate limits, or scraping failure modes, which keeps 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?

Purpose is front-loaded in the first sentence, followed by capability detail and use cases. Both sentences carry information, though the multi-item use-case list is the most expendable element and could be trimmed without losing call-relevant guidance.

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 11-parameter, single-required-argument scraper with no output schema, the description usefully summarizes the return record fields (title, source URL, image URL, thumbnail, dimensions, source name, position) and pagination. That covers the main gap left by the absent output schema; remaining gaps are operational rather than structural.

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 carries full parameter documentation (including the exhaustive tbs filter syntax and enum values). The description's summary of filter categories and pagination maps onto parameters already documented and adds no syntax or default details, so the 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?

Opens with a specific verb+resource ('Get Image Search Results', 'Scrapes Google Images for a query') and enumerates both the filter dimensions and the returned fields. An agent knows exactly what operation this performs 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?

Provides a concrete list of intended scenarios ('visual-asset discovery, reverse-image workflows, dataset collection for ML/CV training, brand/logo monitoring, stock-image sourcing'), which gives clear context for when to reach for it. It stops short of stating exclusions or prerequisites, and there are no sibling tools to route against.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the pagination model (nextPageToken) and the per-review return shape (rating, text, date, place name/address, photos, owner responses), which is useful behavioral context beyond the annotations.

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

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

Three sentences, front-loaded with the core purpose followed by return shape and use cases. Every sentence earns its place, though the return-field list is fairly dense.

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 enumerates the returned per-review fields, compensating well. Combined with annotations covering the safety profile and the 100%-covered schema, an agent has enough to call this correctly; minor gaps remain around pagination termination behavior.

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 parameters are already fully documented in the schema (gl, hl, num, contributorId, nextPageToken). The description restates language/country targeting and pagination in prose but adds no syntax or constraint detail beyond the schema, so the baseline 3 is correct.

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: lists Google Maps reviews authored by a specific Local Guide/contributor, keyed on contributorId. This clearly distinguishes it from the sibling hasdata_google_maps_reviews_getMapReviews, which returns reviews for a place rather than a contributor.

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

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

Provides explicit usage contexts (reviewer reputation checks, fake/bot detection, local-guide activity analysis, trust scoring). It gives clear when-to-use guidance but no explicit when-not or named alternative sibling to route against, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds genuine behavioral context beyond that: the result set is paginated via nextPageToken, filterable by categoryId, and each item carries an image URL plus thumbnail. Auth requirements and rate limits remain undisclosed, keeping it short of a 5.

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

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

Front-loaded with the core action, then mechanism, then use cases, in three tight sentences. The leading 'Get Place Photos' largely restates the title and is mildly redundant, but nothing else 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 no output schema, the description compensates by stating what each returned photo contains, and it explains pagination and filtering. All parameters are optional and the mutual dataId/placeId requirement is handled by the schema, so little is missing; only error/edge behavior is absent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description usefully ties categoryId to filtering and nextPageToken to pagination, but adds no format or syntax detail beyond the schema's own parameter descriptions.

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

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

States a specific verb (fetches) and resource (the photo gallery of a Google Maps place) plus the keying identifiers, so it is instantly distinguishable from siblings like getPlaceDetails, getMapReviews, and getMapPosts. An agent can tell what it returns (photos with image URL and thumbnail) 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 concrete application scenarios (restaurant-menu extraction, venue/ambience audits, place detail pages, POI imagery sourcing) that make the intended use clear. However, it names no alternatives or exclusions, so an agent must infer when to prefer this over getPlaceDetails or getMapPosts rather than being routed explicitly.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the return payload composition and the fetchWebResults side effect ('extra request to Google and costs 5 credits on top of the base'), which an agent needs for cost-aware planning.

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, followed by return contents and the fetchWebResults caveat. The long enumeration of returned fields is informative rather than padded, though it could be trimmed slightly; overall it is efficient and well-ordered.

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

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

There is no output schema, and the description compensates by enumerating the returned fields in detail, including the webResults sub-shape, so an agent knows what comes back. Safety is covered by annotations; the only mild gap is that it does not state where placeId originates beyond the schema note.

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 hl, domain, placeId and fetchWebResults are all documented in the schema itself. The description restates placeId-based lookup and localization and elaborates on what fetchWebResults yields, but adds no syntax or format detail beyond the schema, warranting the baseline 3.

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

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

The description opens with a specific verb+resource ('Fetches full Google Maps place data by placeId') and enumerates the returned fields, so the agent knows exactly what it retrieves. It does not explicitly contrast itself with the other *getPlaceDetails siblings (yelp, yellowpages, booking) or with performMapSearch, but the 'Google Maps place' scope is unambiguous from the name and text.

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 offers a list of use cases (local SEO audits, POI enrichment, lead generation, competitor mapping), which implies when it is useful, but gives no explicit when-to-use vs alternatives and no exclusions. It never says to obtain placeId from performMapSearch first or to route review queries to getMapReviews, leaving sibling selection 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 declare readOnlyHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds real value beyond that by disclosing the return shape (per-post title, description, image, posted_at, link, source/business name) in the absence of an output schema, and noting the dataId/placeId input flexibility, though it omits pagination or rate-limit 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?

Two sentences, front-loaded with the core action and followed by the return fields and use cases. The use-case list is somewhat padded but each clause remains relevant; no significant 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 naming the per-post return fields, and it clarifies the input identifiers and language targeting. Complete enough for an agent to invoke it correctly, missing only finer operational details like limits or pagination.

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 three parameters (hl, dataId, placeId) are already documented in the schema, including the 'either dataId or placeId' rule. The description merely restates 'by dataId or placeId, with language targeting' and adds no syntax or format detail, matching the baseline of 3.

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

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

The description uses a specific verb (Fetches) plus the resource (Google Maps Posts) and even enumerates the content type (offers, events, announcements, notices) fetched by dataId or placeId. It is clear enough to distinguish from most siblings, though it never explicitly contrasts itself with near-namesakes like google_maps_reviews or google_maps_place.

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 intended scenarios ('small-business intelligence, local-marketing monitoring, competitor activity tracking'), which is genuine when-to-use guidance. However, it offers no exclusions and does not route the agent to an alternative (e.g., reviews tool for reviews), so the guidance remains implied rather than decisive.

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, non-destructive, and openWorld, so safety is covered. The description adds genuine behavioral context beyond that: it discloses pagination, the available sort modes, a topicId filter, and the per-review fields returned. It omits auth requirements and rate-limit behavior, keeping it short of a 5.

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

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

Front-loaded with the verb and scope, then structured into retrieval behavior, returned fields, and use cases. The trailing list of use cases is somewhat long but each clause carries a distinct application, so waste is limited.

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

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

With no output schema, the description usefully enumerates the returned per-review fields (author, rating, text, dates, likes, owner response, photos, local-guide flag), which compensates for the missing output schema. The main gap is the absence of guidance on the dataId/placeId choice and pagination flow, but overall it is complete enough to invoke 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 every parameter, including the sort enum and the dataId/placeId duality. The description restates the sort values, topicId, and language but adds no format, precedence, or pagination-token guidance beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb and resource ('Paginated fetch of Google Maps reviews for a place by dataId or placeId') and names the scoping input keys. It implies a place-level scope that separates it from the contributor-reviews sibling, but never names that sibling or any other alternative explicitly, so differentiation relies on inference.

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

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

Gives clear usage contexts ('reputation management, sentiment and topic mining, competitor review benchmarking, feeding review data into summarization or trust-score LLMs'), which tells an agent when this tool fits. However it offers no when-not conditions and does not route to sibling tools like the contributor-reviews or place-details endpoints.

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=false, so the safety profile is covered. The description adds value by enumerating the exact result fields (placeId, rating, review count, price level, hours, etc.) and by noting that ll is required when start is present, though it says nothing about quotas, cost, or error behavior for what is an open-world scrape.

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

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

Two sentences, front-loaded with what the tool does before the field list and use cases. The long middle list of return fields is dense but each item is informative rather than filler.

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

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

With no output schema, the description correctly compensates by listing the returned fields, and it covers the required query plus the optional location, language, domain, and pagination controls. It is slightly thin on the ll/start interaction detail (only partially echoed from the schema) and on rate-limit or auth expectations, but an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents q, gl, hl, ll, start, and domain in detail. The description only summarizes them ('language, country, domain, and offset-based pagination'), adding no format or constraint detail beyond the schema, which matches the baseline of 3.

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

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

States a specific verb and resource (runs a Google Maps search by keyword plus optional coordinates) and enumerates the returned local-pack fields. It also distinguishes itself from the Maps Place, Reviews, and Photos siblings by naming them as downstream consumers of the placeIds it returns.

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 contexts (local lead generation, competitor density mapping, hyperlocal directories) and explains that placeIds feed the Maps Place/Reviews/Photos endpoints, which is genuine routing guidance. It never states when NOT to use this tool or how it compares to sibling search tools such as yelp_search or google_serp_serp, so it falls 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 the safe read-only, open-world profile; the description adds substantial value by enumerating what is returned (title, parties, court, dates, docket numbers, cited cases grouped with a ready-to-call hasdataLink), which is meaningful behavioral context absent from the annotations.

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

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

Front-loads purpose in the first line, then supplies sourcing detail and use cases. It is slightly dense but every sentence carries information; nothing is redundant.

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 fully by describing the return payload, the single required parameter's origin, and the intended workflow, so 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 adds meaning beyond the schema by detailing where caseId comes from (asSdt court-scope searches and citedCases in other case-law results), which is more actionable than the schema's brief note.

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 ('Looks up a Google Scholar Case Law opinion by its caseId'), and ties the resource to the broader google/scholar organic-result and citedCases context so it is distinguishable from the search and citation sibling tools.

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

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

Gives clear context for use ('build legal-research and case-law-analysis workflows, or walk a citation graph one cited case at a time') and explains where the required caseId originates, but does not explicitly name alternative siblings such as getScholarSearchResults or getScholarCitationFormats or state when-not to use 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 it is a safe read (readOnlyHint=true, destructiveHint=false), lowering the bar. The description still adds useful context: it operates on a single result, and enumerates the concrete outputs (MLA/APA/Chicago/Harvard/Vancouver plus BibTeX/EndNote/RefMan/RefWorks), which is behavior an agent cannot infer from annotations.

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

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

Two tight paragraphs, front-loaded with the core action and followed by dependency and output detail. Every sentence carries operational value; nothing is padding.

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

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

For a read-only single-result lookup with no output schema, the description compensates by enumerating the returned citation formats and export links. Combined with annotations and full schema coverage, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so both parameters (q, hl) are fully documented in the schema, establishing the baseline of 3. The description restates that resultId comes from google/scholar, echoing rather than extending the schema text, so no uplift is warranted.

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 ('Looks up citation formats and export links') scoped to a single Google Scholar organic result identified by resultId. This clearly distinguishes it from the sibling google_scholar_scholar_getScholarSearchResults, which produces the resultId this tool consumes.

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 when-to-use guidance ('build citation/bibliography features or complete a research workflow started with google/scholar') and names the upstream dependency that produces the required resultId. It stops short of explicitly naming the sibling alternative, but the dependency routing is enough to select it correctly.

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 real value beyond them by disclosing the return shape (organic results with cited-by/related/versions links, caseHasdataLink for case-law results) and the asSdt court-code semantics, which 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?

Core purpose is front-loaded in the opening clause, followed by parameter coverage and return/use-case detail. The first sentence is a dense run-on enumerating many parameters, but each clause carries information rather than filler.

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

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

For a 15-parameter tool with no output schema, the description compensates by describing the result fields and the case-law link behavior, and annotations cover the safety profile. Coverage is strong; only the absence of an explicit alternative-selection rule against the cite sibling leaves a minor gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining parameter intent: cites/cluster as lookups keyed off returned IDs, asSdt court-code values (2006 all courts, 2003 Federal), review-article and citation-inclusion filters, and scisbd sort modes. This adds meaning beyond the schema text.

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

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

States a specific verb (scrapes) and resource (Google Scholar search results) and immediately distinguishes the tool from its scholar siblings by calling out cited-by/all-versions lookups and routing case-law results onward. An agent can identify this as the general Scholar search entry point 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?

Explicitly lists when to use it (academic research, literature review automation, citation tracking, grounding research agents) and points to the sibling google/scholar-case-law flow for case law. It does not state when NOT to use it or contrast against hasdata_google_scholar_cite, but the context is clear.

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, open-world, non-destructive behavior, lowering the disclosure burden. The description adds useful behavioral detail beyond annotations: it returns conversational response text, cited source links, subtopic breakdowns, and a subsequentRequestToken when continuable is set for multi-turn continuation.

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 first two sentences are front-loaded and earn their place by specifying the operation and return fields. The remainder is an overlong, overlapping list of use cases and examples ('person/company data enrichment', 'lead enrichment, sales research, people search, and filling in contact/attribute gaps for CRM records') that bloats the definition without adding distinct decision value.

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

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

There is no output schema, so the description carries the return-value burden and mostly succeeds by naming the main response components. It does not cover error handling, authentication, or rate limits, but for a read-only scraping endpoint with fully documented parameters and clear safety annotations, this is close to 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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the relationship between continuable and subsequentRequestToken for multi-turn AI Mode continuation, though it does not expand on q, gl, hl, uule, or location.

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: 'Get AI Mode SERP Results' and 'Captures Gemini-powered AI Mode answers from Google Search.' It clearly distinguishes the tool from generic Google SERP and AI Overview siblings by naming the AI Mode/Gemini conversational answer output.

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

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

Provides clear usage contexts ('Use for next-gen search interfaces, AI-answer monitoring, citation tracking, content research agents...') and concrete examples like `Who is the CEO of HasData?`. It does not, however, name when-not-to-use it or explicitly route the agent to sibling alternatives such as ai_overview or regular SERP tools.

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/non-destructive, so safety is covered; the description adds the lazy-loaded nature, the 1-minute token window, and the shape of the payload (answer text, source URLs, expanded subtopics). It does not describe failure behavior when the token expires, which is the one notable gap.

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

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

Front-loaded with a short title line followed by a dense but purposeful paragraph; every sentence carries either mechanism, timing, or use case. Slightly verbose in the final list of use cases but not wasteful.

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

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

With no output schema, the description correctly takes on the burden of describing the return payload, and it does so at a useful level of detail. A brief note on token-expiry failure handling would make it fully 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?

Only one parameter and schema coverage is 100%, so the schema already documents pageToken fully. The description repeats the token's origin and 1-minute validity rather than adding 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 (fetches) and resource (the lazy-loaded Google AI Overview block) and explains the mechanism (via a pageToken from Google SERP). An agent can distinguish this from hasdata_google_serp_serp_getSearchResults because the description frames it as a dependent follow-up rather than a primary search.

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

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

Explicitly positions the tool as a follow-up call to Google SERP and names three concrete use cases (SEO AI-citation tracking, fact-checking, LLM grounding). No explicit 'do not use when' or named sibling alternative, but the context 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?

Annotations only cover the safety profile (readOnly/openWorld/non-destructive), and the description adds real behavioral value beyond them: it enumerates the returned fields (venue, map link, ticket sources with official/unofficial flags, primary ticket link) and discloses a time-sensitive constraint — the token expires a few minutes after being minted, so it must be called promptly.

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

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

Three sentences, front-loaded with the core action and then the source/expiry, with no filler. Slightly dense but each sentence carries information an agent needs.

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

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

With no output schema, the description carries the return-value burden and does so fully, plus the expiry constraint and the token's origin. Nothing essential for a correct single-parameter lookup 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 single parameter is already documented; baseline would be 3. The description earns above baseline by clarifying that the token can also be taken from the adjacent ready-to-call `hasdataLink`, a detail the schema does not mention.

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: 'Looks up a single Google event by the pageToken'. It also scopes the input to the `eventsResults` array of a `google/serp` response, differentiating it from the sibling search tools that return the SERP itself.

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 ('Use to enrich an events search result with full venue and ticketing information') and states the prerequisite source of the token. It implicitly excludes using it for what the SERP widget already shows inline, but never names an explicit alternative tool or a when-not condition.

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 safety (readOnlyHint, non-destructive, openWorld); the description adds real behavioral value by disclosing that moreStores raises the merchant count from the default 3–5 to ~13 and that the nextPageToken paginates stores. It stops short of describing rate limits or error behavior, so a 4 rather than 5.

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

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

Front-loads the core action and expands the token context in the second sentence; the merchant-count and pagination notes are dense but relevant. The use-case list at the end is mildly padded but not wasteful.

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

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

With no output schema, the description carries the return-value burden and does so well: multi-store offers (merchant, price, shipping, URL), specs, images, ratings, and storesNextPageToken. Missing only failure modes or how much the token payload varies, but it is otherwise sufficient to call the tool 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 all three parameters are already documented in the schema, including the 3–5 vs ~13 store behavior that the description repeats. The description adds no format, constraints, or edge cases beyond what the schema states, so baseline 3 applies.

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

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

States a specific verb and resource ('Expands the Google Shopping Immersive Product pop-up given an immersiveProductPageToken'), which is concrete and actionable. It implicitly distinguishes itself from the generic sibling getProductInformation by scoping to the immersive pop-up, but never names that sibling, so the differentiation is left to inference.

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

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

The 'Use for price-comparison bots, merchant discovery, dropshipping research' list describes audiences/use cases rather than conditions for selecting this tool over alternatives like google_serp_shopping or google_serp_product. No when-not-to-use or prerequisite (e.g., where the token comes from) is stated beyond the token's origin.

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, openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing the return payload (title, snippet, source, published date, thumbnail, URL, navigation tokens) and the token-based mode switching, which annotations do not convey. It omits rate limits, pagination, and auth requirements.

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?

Well front-loaded: the lead line names the resource before the retrieval-mode detail, and the use-case sentence is placed last. It is dense but each sentence (modes, return fields, use cases) carries distinct information; only the redundant opening echo of the name is mild 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?

For an 8-parameter read tool with no output schema, the description covers the retrieval modes, the mutual-exclusion constraints among tokens, and the return contents, which is enough for an agent to invoke it correctly. Missing only secondary operational detail such as pagination or result limits, which is acceptable given rich schema coverage and safety annotations.

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 baseline is 3; the description adds a mode-selection framing by grouping the tokens into named retrieval strategies and clarifying that storyToken is a 'full-coverage cluster with sort by relevance/date' (explaining the so parameter's purpose). It repeats several schema examples rather than supplying new syntax, so it only modestly exceeds baseline.

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 ('Retrieves') and resource ('Google News results') and enumerates the five retrieval modes (free-text query, topicToken, sectionToken, publicationToken, storyToken), making the scope concrete. However, it never names or contrasts with siblings like serp_getSearchResults for non-news web results, so an agent must infer the news-only boundary 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?

Explicitly lists use cases ('news monitoring, brand/PR tracking, topical aggregators, publisher-specific feeds, and drilling into full story coverage'), giving clear triggering context. It stops short of when-NOT-to-use or naming an alternative sibling (e.g. general SERP search), so it does not reach the 5 bar.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description usefully notes that the returned payload varies with searchType and enumerates the returned fields, but adds no auth, rate-limit, or pagination caveats beyond what the schema's 'start' description already supplies.

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 three dense sentences that front-load the core action and then summarize inputs before closing with use cases. Every sentence contributes, though the parenthetical filter gloss in sentence one is slightly redundant with the schema and could be trimmed.

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

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

For a nine-parameter read tool with full schema coverage but no output schema, the description does the necessary work of describing the return payload (title, images, price, ratings, specs, merchant offers, review text) and its dependence on searchType. What remains thin is the absence of any guidance on failure/empty cases, but overall it is sufficient for correct invocation.

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

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

With schema description coverage at 100%, the schema already documents all nine parameters thoroughly, including enum values and the filter grammar. The description echoes the searchType values and filter categories (free shipping, used-condition, sort options) but introduces no syntax or semantics beyond what the schema provides, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource: it 'pulls detailed product data from Google Shopping by productId,' which is a concrete scope. The 'by productId' phrasing implicitly distinguishes it from the search-oriented siblings like shopping_getSearchResults, but it never names those alternatives directly, so differentiation is inferred rather than stated.

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 clear usage context via concrete scenarios (price intelligence, catalog enrichment, review mining, competitor spec comparison, shopping assistants). However it offers no when-not conditions and never points the agent to a sibling tool, so selection between this and the shopping search tools 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 declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond annotations: the full set of returned features (ads, knowledge graph, PAA, local pack, AI Overview pageToken) and the constraint that 'num' is capped at 10 without tbm. It does not cover rate limits or auth, but it goes well beyond the safety hints.

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 first sentence is front-loaded, but the body is one extremely long run-on sentence that packs features, parameters, use cases, and a long enrichment example list together. Every clause is informative, yet the density and example enumeration make it harder to parse than necessary.

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 describe return values — and it does, listing organic results, ads, knowledge graph, related searches, PAA, local pack, featured snippets, and AI Overview token. With all parameters documented in the schema, the definition is complete enough to invoke 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 19 parameters in detail. The description adds marginal value by grouping parameter capabilities (location/uule, gl, hl/lr, tbs filters, tbm verticals, offset/num) and noting the num/tbm interaction. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description states a clear verb+resource ('Get Google Search Results', 'Full-featured Google Search scraper') and enumerates the verticals and features it covers. It implicitly contrasts with lighter siblings via 'Full-featured', but never names an alternative tool (e.g., serp_light, bing_serp), so an agent must infer the distinction.

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 provides explicit use-case contexts — SEO rank tracking, keyword research, SERP-feature monitoring, competitor analysis, LLM grounding, and person/company enrichment with concrete example queries. However, it offers no when-not guidance or named alternative (e.g., use bing_serp or serp_light instead).

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, non-destructive, open-world), and the description layers on substantial extra context: the complete set of returned blocks, the blocks explicitly excluded from this layout, the num cap, and the performance/cost tradeoff. This is far beyond what the annotations provide.

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 purpose is front-loaded and every sentence carries information (returned blocks, excluded blocks, parameters, use cases). It is dense and slightly run-on, but no sentence is filler, so it stays efficient for a tool of this complexity.

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 of describing return values and does so thoroughly, enumerating every result block returned. Combined with full parameter coverage and explicit limitations, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so parameters are already fully documented, establishing a baseline of 3. The description summarizes the supported filters (gl, hl/lr, domain, safesearch, tbs with qdr/cdr, offset/num), but it introduces a discrepancy by stating 'num capped at 10' while the schema declares num ranges from 10 to 100, which could mislead an agent on pagination.

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 ('Get Google Light Search Results') and immediately distinguishes itself from the full SERP API sibling by describing the lightweight no-JS layout and its cheaper/faster tradeoff. An agent can tell it apart from hasdata_google_serp_serp_getSearchResults 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 names intended use cases (high-volume keyword monitoring, bulk rank tracking, backlink discovery, AI Overview presence tracking) and, by listing the block types it does NOT serve (shopping, news, videos, jobs), implicitly signals when the full SERP API should be used instead. It stops short of naming the alternative tool explicitly or stating a hard when-not rule.

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, so the safety profile is covered. The description adds real behavioral value by enumerating the returned fields (title, price, merchant, rating, reviews, thumbnail, productId, immersiveProductPageToken) and explaining the filter-chip/hasdata_link refinement loop, which is not derivable from the schema. It does not mention auth or rate limits, keeping it at a 4.

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 in sentence one and packs filter dims and return/usage context into sentence two with no filler. It is dense but every clause carries information, so it is appropriately sized rather than merely short.

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 10 parameters, no output schema, but full annotation coverage, the description does the heavy lifting an agent needs: it enumerates the return payload and the downstream id/token handoffs. It leaves pagination mechanics and error behavior to the schema/annotations, which is acceptable given no output schema forces it to describe returns 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 the schema already documents all 10 parameters in detail. The description groups them ('location/uule, country/language/domain, time/date filters, device type, shoprs filter-helper IDs, and offset pagination') but adds no syntax or format meaning beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Scrapes Google Shopping listings for a query') and the scope of filters it accepts. It also distinguishes itself from adjacent tools by naming the Product API and Immersive Product API as consumers of its output. An agent can tell it apart from the generic serp_getSearchResults sibling by the explicit 'Shopping' 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 concrete when-to-use contexts ('e-commerce price tracking, catalog building, promotion discovery') and names alternatives, explaining that productIds feed the Product API and tokens feed the Immersive Product API for deeper data. It stops short of stating explicit exclusions (e.g. when to prefer the plain SERP instead), so it is clear context without full routing rules.

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 read-only, non-destructive, open-world behavior, so the bar is lower. The description goes on to disclose the return surface (title, thumbnail, duration, source platform, channel, direct URL, platform video ID, profile handle) and the hasdataLinks follow-up capability, which is genuinely useful behavioral context. It omits rate limits and response envelope details, keeping it below 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?

The definition is front-loaded with the core action, then output, then use cases — a logical progression with no filler sentences. Length is proportionate to a 10-parameter tool with no 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 takes on the burden of describing return fields, which it does thoroughly, and it covers the parameter envelope and intended use cases. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all 10 parameters in detail and the baseline is 3. The description groups them (location/uule, country gl/cr, language hl/lr, device type, page pagination, tbs filters), which adds light interpretive structure but does not clarify the gl-vs-cr or hl-vs-lr distinction 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?

The description states a specific verb and resource — scraping the Google Short Videos carousel (explicitly TikTok, YouTube Shorts, Instagram Reels) — which is concrete and distinguishable from the generic google_serp_serp_getSearchResults and platform-specific tiktok/youtube siblings. An agent can tell 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?

It gives clear context for use (short-form content discovery, viral-trend monitoring, influencer research, cross-platform aggregation, sourcing clips for LLM summarization/embedding). It does not, however, state when NOT to use it or explicitly name alternatives such as the general SERP or TikTok search tools, so routing between overlapping siblings 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 declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: which fields come back only for searches Google shaped itself (typical price, discount, destination photo), that a date range is derived from the query, and the breadth of filtering. It omits auth needs and any rate/limit behavior, so it doesn't reach 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?

The core mechanism and origin-airport scoping are front-loaded, and the return-field enumeration follows. It is dense and somewhat long, but nearly every clause carries information an agent needs (conditional fields, derived date range, filter categories) rather than filler.

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

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

For a 21-parameter tool with no output schema and no siblings, the description compensates well by enumerating the return payload fields and the conditional nature of some of them, plus an overview of the filter surface. What remains missing (auth, pagination/limits) is minor given the read-only annotation profile.

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 the schema documents all 21 parameters in depth, including the critical arrivalId dependency and filter interactions. The description only summarizes the filter categories (trip type, cabin class, stops, dates, trip length, price/duration ceilings, airlines, party size) without adding syntax or constraints beyond the schema, 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?

States a specific verb and resource ('Get Google Flights Deals Results') and immediately explains the distinctive mechanism: a plain-language trip description becomes flight deals from one origin airport with Google choosing destinations and dates. There are no siblings to distinguish from, so this is as clear as it needs to be.

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

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

Explicitly names intended uses ('inspiration-driven travel search, seasonal and event-based fare discovery, deal alerting, and travel-content generation'), which tells the agent when this tool fits. No when-not or exclusion guidance, and there are no alternative tools to route against, so 4 is the ceiling here.

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=false, so safety is covered. The description adds valuable behavioral context beyond that: it details the return payload (price, duration, stops, legs, aircraft, CO2 emissions) and the token flow for round-trip/booking follow-ups, though it omits rate limits, auth, and pagination.

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 a clear purpose line followed by a dense but informative summary of inputs and outputs. The mega-sentence is long and the trailing use-case list is somewhat filler, but nothing is materially 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?

For a 31-parameter tool with no output schema, the description usefully compensates by describing the return structure and the departureToken/bookingToken follow-up flow. Required parameters and their formats are covered by the schema; only operational details like errors and rate limits are 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%, so the schema already documents all 31 parameters with enums and examples. The description's summary of the parameter space (passenger mix, class, bags, max price, sort, stops, airline filters, time windows, layover, deep search) adds framing but no syntax or format 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 and resource ('Searches Google Flights for one-way, round-trip, or multi-city itineraries') and enumerates the concrete filtering scope, making it unmistakably distinct from the sibling deals and hotels tools. An agent can identify the tool's function 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 closing sentence lists intended audiences and scenarios ('travel-planning agents, fare monitoring, corporate travel dashboards, emission-aware trip optimization'), which implies usage but gives no conditions for choosing this tool over getGoogleFlightsDeals or getGoogleHotels. No explicit when-not or alternative guidance is provided.

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 value by enumerating what the call actually returns (rates, price comparisons, reviews, images, deals, pagination tokens), which matters because no output schema exists; it still omits auth/rate-limit 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?

Purpose is front-loaded in the first sentence, but the second sentence is a very long run-on enumeration of return fields. That inventory earns some of its length given the absence of an output schema, yet it is undifferentiated and would be more usable as a structured 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?

For a 25-parameter, no-output-schema tool, the description covers the filter surface, the hotel-vs-rental mode distinction, and the return payload inventory. Missing pieces are operational (auth, rate limits, pagination workflow) rather than selection-critical.

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, including the hotel*/rental* prefix semantics and enum meanings. The description's category listing largely restates those fields without adding format or constraint detail, so the baseline 3 applies.

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

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

The description opens with a specific verb and resource ('Searches Google Hotels for hotels and vacation rentals') and scopes it with check-in/check-out, guest mix, localization, and filter categories. It is unambiguous about what the tool does, though there are no sibling tools against which it must differentiate itself.

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 lists target audiences ('travel research agents, hotel rate monitoring, OTA dashboards, and competitive analysis'), which implies usage context, but gives no explicit when-to-use/when-not guidance, no prerequisites, and no workflow hints (e.g., how to continue pagination or switch to vacation-rental mode).

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 value beyond that by disclosing the return content (interest-over-time series, geo breakdowns, rising/top related topics/queries with relative scores), which matters because no output schema exists. Minor imprecision: it says "one or more queries" while relatedTopics/relatedQueries accept only a single query, though the schema corrects this.

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 a short title line, followed by one dense capability sentence and one returns/use-case sentence. It is reasonably sized, though the capability enumeration partially duplicates what the 100%-covered schema already provides.

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 tool with no output schema, the description covers both the input dimensions and the shape of the returned data, which is what an agent most needs. It leaves out return value ranges/normalization detail and any mention of rate limits or pagination, but nothing critical 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 fully documents all 8 parameters with examples and enum meanings, setting the baseline at 3. The description only restates the parameter concepts at a high level (geo, region, date, category, tz, gprop, dataType) without adding syntax or format 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?

The description states a specific verb and resource ("Pulls Google Trends data") and enumerates the concrete capabilities (geo targeting, region granularity, date range, gprop, dataType) so the agent knows exactly what the tool produces. It doesn't explicitly differentiate from any sibling by name, but the Google Trends resource is unique within the sibling set, so confusion risk is low.

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 offers a use-case list (keyword/content strategy, demand forecasting, seasonality analysis, topic discovery, campaign timing), which gives implied usage context. However, there is no when-not guidance, no prerequisites, and no routing to alternative tools, so the agent must infer selection on its own.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral value by enumerating what is returned (title, company, location, salary, employment type, description, benefits) and noting it works on a single posting. No rate-limit or auth detail, but nothing contradicts the annotations.

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

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

Front-loaded with the core action, followed by return payload and use cases. Every sentence earns its place, though the use-case list is slightly long and not all items are equally informative.

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 and only one required parameter, the description carries the return-value burden itself and does so by enumerating returned fields. Nothing an agent needs in order to call this 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% for the single parameter, giving a baseline of 3. The description goes beyond the generic schema text ('URL of the job vacancy') by specifying it must be a 'viewjob URL', which constrains the expected input format meaningfully.

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 ('Fetches a single Indeed job posting by its viewjob URL') and explicitly distinguishes itself from the sibling listing endpoint. An agent can tell it apart from hasdata_indeed_listing_getJobListings and hasdata_glassdoor_job_getJobDetails without opening any schema.

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

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

Gives concrete usage contexts (ATS/CRM enrichment, compensation benchmarking, resume-to-JD matching, archival) and names the Listing endpoint as the discovery counterpart. It doesn't state exclusions or prerequisites, but the context is clear enough to select the tool correctly.

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/open-world, and the description layers on genuinely useful behavior: the returned field set, the warning that jobKey is the only reliable dedup key for sponsored postings, and the sponsoredOnly quirk where requests exit from the domain's country (Canadian results served as sponsored). These are non-obvious traits not derivable from annotations.

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

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

A single front-loaded paragraph that leads with purpose then progresses through filters, return shape, edge cases, and use cases. Dense but each clause carries information; slight overload on return-field enumeration.

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 correctly compensates by listing the returned job fields and the stable jobKey. For an 8-parameter read tool with full annotation coverage, no call-critical information 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 semantic value beyond the schema: it clarifies jobKey's dedup role and the sponsoredOnly country-domain behavior. The remoteType country-vs-city nuance largely restates the schema description.

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 job listings by keyword and location') and enumerates the filter scope. It also distinguishes itself from the sibling hasdata_indeed_job_getJobDetails by framing its output as URL lists to feed into the Indeed Job endpoint.

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 application contexts (job-market dashboards, hiring-trend analysis, sourcing pipelines, URL-list generation for the Job endpoint). Clear when-to-use, but no explicit exclusions or statement of when the sibling detail endpoint should be preferred instead.

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?

Goes well beyond the readOnly/openWorld annotations by disclosing pagination mechanics: the first page returns the full post plus initial comments while later pages return comments only, server-side page sizing of ~10-15 comments, and nextPageToken handling. It also notes includeMusic triggers an extra upstream request and is ignored when nextPageToken is set.

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

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

Front-loads the purpose in the first sentence, then layers pagination and return-shape detail. It is dense, and the long parenthetical enumerating every post field is heavy, but that content earns its place because there is no 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 carries the full burden of describing return values and does so thoroughly: post fields, carousel childPosts, comment fields (text, timestamp, likes, replies, owner with hasdataLink), and music fields. 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 baseline is 3, but the description adds beyond it by enumerating accepted URL forms (/p/, /reel/, /tv/, with or without the username segment) and clarifying the interaction between includeMusic and nextPageToken. Most other parameter detail is already in the schema, so it is not fully additive.

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 ('Fetches the comments on a public Instagram post or reel from its URL'), and its scope clearly separates it from sibling tools like getInstagramPosts and profile endpoints. An agent can immediately tell this returns comments rather than posts or profiles.

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

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

Provides concrete use cases (sentiment analysis, engagement research, comment datasets) and explicitly routes the agent from the posts API, whose items carry a hasdataLink to this endpoint. It does not state when to avoid the tool or name a competing comments source, so it falls 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 cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description still adds meaningful behavior: token-based pagination via nextPageToken to walk older posts, and that private/nonexistent/hidden handles return an error field instead of posts. No rate limits or result-cap behavior are mentioned, keeping it short of a 5.

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

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

Front-loaded with the purpose, then return fields, then pagination, then error behavior, then use cases — a sensible ordering with little waste. The field enumeration is long but justified given there is no 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 carries the return-value burden and does so by listing caption, hashtags, mentions, engagement counts, video/Reels play counts, media URLs, and timestamps. Combined with pagination semantics and error behavior for private accounts, nothing an agent needs to call this 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 each of the three parameters is already documented with its own description. The description adds only a light gloss on pagination ('walk older posts'); it adds no syntax or format detail 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 verb and resource ('Fetches the latest posts of a public Instagram account by username') and enumerates the returned fields, which cleanly separates it from sibling tools like instagram_profile and instagram_comments. An agent can tell 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?

Gives concrete use cases ('monitor competitor content, track engagement of creator posts, or build datasets... for vetting and analytics'), which is clear when-to-use context. It does not, however, name alternative tools or state when not to use it (e.g., profile metadata or comments go to sibling tools).

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, openWorldHint=true, and destructiveHint=false, so the low-level safety profile is covered. The description adds the meaningful constraint that only *public* profiles are fetched and enumerates the returned fields, which goes beyond the annotations, but it says nothing about rate limits, failures on missing/private handles, or freshness.

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

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

Two sentences, front-loaded with the operation and its return payload, followed by use cases. The use-case list is somewhat expansive but each item is a plausible agent routing cue, so little 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?

For a single-parameter read tool with rich annotations but no output schema, the description covers purpose, scope, and return shape, which is most of what an agent needs. Minor gaps (behavior on invalid/private handles) are tolerable given the simplicity and annotation coverage.

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 single handle parameter is already documented in the schema, including the no-@-symbol requirement. The description only restates 'by username (handle)' and adds no new syntax or format meaning, 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?

States a specific verb (Fetches) and resource (public Instagram profile by username) and lists exactly what the response contains (full name, bio, link, picture, follower/following counts, verified/private flags). This clearly separates it from content-oriented siblings like instagram_posts and instagram_comments, though no sibling is named explicitly.

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

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

Provides concrete usage contexts (CRM enrichment, influencer vetting, competitor monitoring, dataset building) that tell the agent when this tool is appropriate. It offers no exclusions or named alternatives (e.g. TikTok/Facebook profile tools), so it stops short of full routing guidance.

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

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

Annotations only cover the safety profile (readOnly/openWorld/non-destructive); the description adds genuinely new behaviour — it runs anonymously, always performs a web search (usedWebSearch normally true), returns sources instead of relying on the model alone, each request is a fresh thread with no memory, and answer language follows the prompt. That is substantial context beyond 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 the core action and return shape, and every sentence carries information — the enumeration of return fields is justified because there is no output schema. The single dense paragraph is slightly run-on but not padded.

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

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

With no output schema, the description compensates by naming every returned field and its structure, and it covers statelessness, language behaviour and timezone framing. An agent has everything needed to invoke and interpret the tool 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 both parameters are already fully documented in the schema, and the description largely restates them (language follows the question, timezone sets the current date for 'today'/'latest'). No additional syntax or edge-case meaning is added, so the baseline 3 applies.

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

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

States a specific verb and resource — sends a question to Perplexity and returns the answer plus sources, related questions, thread URL, model and country. It clearly distinguishes itself from the many SERP/scraper siblings by naming Perplexity and its cited-source output.

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

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

Provides explicit use cases (cited Q&A, grounding an agent/RAG pipeline in live web results, topic summarisation with sources, building answer+citation datasets) plus the statelessness caveat. It stops short of naming a sibling alternative (e.g. chatgpt_chat_getChatgptAnswer) or when-not-to-use conditions, so 4 rather than 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/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: results are paginated, and a street-address or building-name input collapses to a single property card where the `type` parameter no longer applies. Auth and rate-limit behavior are not mentioned, which keeps it below 5.

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

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

Front-loaded with the operation and mode, then details. The return-field enumeration is long, but it substitutes for a missing output schema, so it earns its space. Slight density, but no redundant sentences.

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 59-parameter, no-output-schema tool, the description covers purpose, input modes, result-shape variation, returned fields, and the sibling relationship. Nothing essential to a correct call is left unstated.

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

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

Schema coverage is 100% and the schema already spells out every filter and enum, so baseline is 3. The description earns above baseline by documenting a semantic rule the schema never states: that required `type` is ignored for address/building searches, plus the set of location formats `keyword` truly accepts.

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 precise verb+resource (search for-sale/for-rent/sold Redfin listings) and its scope (pagination, location input forms). It explicitly distinguishes itself from the sibling by noting that deep-dive details come from the Redfin Property endpoint, so an agent can route 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.