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

With no annotations, the description carries the full behavioral burden and does well: it discloses cost (~2 points/call), latency (~30s, flagged slow), mode trade-offs, the fact that followups >5 degrade performance, ToS-compliance constraints, and an upstream data quirk (the misspelled 'sponsered' key to match verbatim). It stops short of describing auth or error/empty-result behavior, so it is strong but not exhaustive.

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

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

The content is front-loaded with purpose and organized under labeled sections (Use when / Don't use / Returns / Pair with / Cost / Tips), which aids scanning. It is dense and the Returns block is long, but that length substitutes for a missing output schema rather than being pure 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?

There is no output schema, so the description must explain return values, and it does so in detail, enumerating the response shape, the AI Overview/organic/related/sponsered item types, and the meaning of the 'position' field. Combined with usage, cost, and mode guidance, nothing an agent needs to invoke 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 description coverage is 100%, so the schema already documents every parameter with examples, which sets a baseline of 3. The description adds selection guidance beyond the schema — preferring 'overview' for single queries and reserving 'ai_mode' for decomposed multi-turn work, plus the followups[1..5] direction — earning it above 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?

The description states a specific verb and resource ('Scrape publicly-available Google search results') and immediately scopes the source (Google SERP, AI Overview, organic, related searches). It explicitly differentiates itself from siblings by naming search_amazon for on-Amazon needs and keyword_trends for trend-only work, so an agent can route 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?

It provides an explicit 'Use when:' block with concrete trigger phrases ('Google for me', 'external demand', 'Reddit/Quora pain points') and a 'Don't use:' block that names the two alternative tools and the conditions selecting them. Both positive and negative routing are covered.

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?

With no annotations, the description carries the full burden and does well: it discloses cost (~1 point/page, ~5s), the backend pagination cap (size max 10), the US-only marketplace limitation, and the pass-through behavior of extraFilters. It does not explicitly state authentication requirements or reversibility, but for a read-only filter endpoint this is a strong disclosure.

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

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

Long but tightly front-loaded with labeled sections (Use when / Don't use / Returns / Pair with / Cost / Tips), so an agent can scan to the relevant part. Slightly over-dense with the full field enumeration, but each section is purposeful.

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, the description compensates fully: it enumerates the returned data shape, pagination fields, cost, and constraints. An agent has everything needed to select and 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 coverage is 100% so the baseline is 3, but the description adds value beyond the schema: the provenance of categoryId (from search_categories / get_category_children), the recommended required values ('l7d', 'all_asin'), the default marketplaceId, and the long-tail pass-through contract for extraFilters. The pagination semantics (1-based page, hasNext) are also spelled out.

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 ('Filter categories by dozens of metrics') and immediately names what it is not, distinguishing it from filter_niches, list_category_products, and get_category_paths. It also clarifies the dual role as a single-category detail endpoint, which an agent could not infer otherwise.

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?

Contains explicit 'Use when' trigger phrases, a 'Don't use' section routing each alternative use case to the correct sibling, and a 'Pair with' workflow showing upstream (search_categories/get_category_children) and downstream (list_category_products/list_bestsellers) tools. Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and does so: it discloses pagination semantics (hasNext, page, size cap), a hard marketplace limitation (US only, others fail/fall back), cost (~1 point/call, ~5s), and the fact that size is capped at 10. These are the operational traits an agent needs that structured fields do not supply.

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 Use/Don't-use/Returns/Pair-with/Cost/Tips in a scannable order. It is dense and long, and the Returns field list is somewhat verbose, but nearly every line aids correct invocation, 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 24-parameter, no-output-schema tool, the description supplies the return shape (so no output schema is needed), pagination behavior, pairing guidance (get_amazon_product, categoryId derivation), and the missing-categoryId caveat. Nothing an agent needs to call it correctly is absent.

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

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

Schema coverage is 100%, yet the description still adds meaning: it explains extraFilters as the pass-through for 50+ long-tail filters, gives the concrete blue-ocean filter combo with the correct field names, clarifies returnRateT360Max as a 0-1 upper bound, and notes marketplaceId defaults to US. This is genuine value 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 ('Filter Amazon Niches') and immediately disambiguates the concept ('a finer-grained demand cluster than categories'), plus discloses a dual mode ('niche detail' endpoint for one niche). An agent can distinguish this from filter_categories and list_category_products 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?

Explicit 'Use when' section with concrete user utterances (blue ocean, low return-rate, niche scouting) and an explicit 'Don't use' section naming the correct siblings for full categories, products in a niche, and plain keyword search. Routing 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?

With no annotations the description carries the full burden, and it delivers real behavioral disclosure: point costs (5 for extraction, +20 per answered region, 0/5/25/45 totals), zero cost for valid no-question results and service failures, and 5 points for an invalid ASIN. It does not cover authentication mechanics, rate limits, or failure/return shape, so it falls short of full transparency for a scraping tool.

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

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

Two tightly packed sentences with the core action front-loaded and the cost model compressed into a single clause. The cost parenthetical is dense but earns its place; nothing is padded.

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

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

For a 5-parameter, zero-required tool with no output schema and no annotations, the description covers purpose and cost but omits the return structure (what the question/answer payload looks like) and any auth prerequisites beyond 'logged-in'. It is adequate but not fully self-contained.

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 already explains url/asin duality, the region enum semantics, concurrency bounds, and includeAnswers behavior in detail. The description adds no parameter-level meaning beyond that, 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 uses a specific verb (extract) and resource (Alexa/Rufus preset-question regions) scoped to a logged-in Amazon PDP, plus the optional answer-generation behavior. It is very clear about what it does, but it never names or distinguishes itself from the sibling search_amazon_alexa or get_amazon_reviews, leaving the agent to infer the boundary.

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

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

Usage is implied rather than stated: the tool operates on a logged-in Amazon PDP and the answering step is optional. There is no explicit when-to-use, when-not-to-use, or which sibling to pick for a related question, so the agent gets context but no 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?

With no annotations, the description carries the full burden and does so: it discloses cost (2 points/call), latency (~5s), the address/zipcode dependency of results, the fallback when zipcode is omitted, and that unavailable extra fields come back as empty strings rather than erroring. This is unusually complete behavioral context for a mutation-free lookup.

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?

Labeled sections (Use when / Don't use / Returns / Cost) put the decision-relevant content first and every sentence earns its place. Dense but zero 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?

There is no output schema, yet the description spells out the return path (data.json[0].data.results[0]) and the incremental fields (frequentlyReturnedItem, leadTime, delivery{...}), so an agent knows what to expect. Combined with cost and the zipcode caveat, nothing needed to invoke 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; the description goes beyond it by explaining that delivery estimates are dependent on the address/zipcode and that the backend substitutes a country-matched ZIP when omitted, which is meaningful semantics the schema only hints at.

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 ('Return the full listing detail for one ASIN plus address-dependent delivery estimates') and immediately distinguishes itself from the sibling get_amazon_product by scope and cost. An agent can tell exactly what this returns versus ordinary product detail 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?

Provides explicit 'Use when' triggers (estimated arrival, free vs paid timing, fastest option, lead time, high-return warning) and an explicit 'Don't use' clause with the named alternative and its cheaper cost. Routing is fully determined.

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?

With no annotations, the description carries the full burden and does well: it discloses cost (~1 point/call, ~5s), the fact that the PDP carries only ~5-10 reviews, and the exact return shape. It stops short of stating auth requirements, rate limits, or failure behavior, which keeps it out of 5 territory.

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 with labeled sections (purpose, use/don't use, returns, pairing, cost). The dense "Returns" block is long but justified given there is no output schema; only minor redundancy in restating the title split.

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 5-parameter read tool with no output schema and no annotations, the description supplies everything an agent needs: return-field enumeration, title/itemName/itemHighlights semantics, video section meanings, cost, and a pointer to get_amazon_delivery_time for delivery nuance.

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 five parameters (asin, site, format, zipcode, clientSource) are already documented, including the zipcode cross-country rejection rule. The description adds little about inputs beyond the default format, 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 ("Scrape the full PDP for one ASIN") and immediately distinguishes itself from siblings by naming search_amazon, the list_* series, and get_amazon_reviews. An agent can route correctly 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?

Explicit "Use when" conditions (user supplies a specific ASIN, or as a SOP step after candidate ASINs) and explicit "Don't use" exclusions with named alternatives for both bulk lookups and review-only needs. Pairing notes (upstream/downstream) close the loop.

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?

No annotations exist, so the description carries the full behavioral burden and largely does: it discloses the cost model (10 points per page), the pagination granularity (~10 reviews/page), a scaling strategy (pageCount=1 first, then 3-5), backend zip-country validation with rejection, and an empty totalReviews when unavailable. That is material operational context an agent needs before calling.

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

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

Front-loaded with purpose and organized into labeled sections (Use when / Don't use / Returns / Pair with / Cost / Tips), so it scans fast despite being long. There is some duplication with the schema (cost and mediaType semantics appear in both), which costs it a point.

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

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

For an 8-parameter tool with no output schema and no annotations, it supplies everything needed: required input provenance (ASIN from search_amazon/get_amazon_product/list_bestsellers), a full return-shape sketch, cost control guidance, and a downstream pairing note. Nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so baseline is 3. The description mostly restates schema content (star enum values, sort options, mediaType credibility, per-page cost) rather than adding syntax or defaults beyond it; the one genuinely additive note is the recommendation to prefer filterByStar='critical' for signal density.

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

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

States a concrete verb+resource ("Page-fetch real buyer reviews for an ASIN") plus the filter surface (star/sort/media type). It also names the siblings it is NOT (get_amazon_product, search_amazon), so an agent can route without opening a schema.

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

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

Explicit "Use when:" block with concrete user utterances ("look at X's negative reviews", "do VOC") and an explicit "Don't use:" block that names the alternative tool and the condition that selects it (PDP's built-in 5-10 reviews suffice). This is exactly the when/when-not/alternative structure.

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?

No annotations are supplied, so the description carries the full burden. It discloses cost (~1 point/page, ~3s), pagination semantics, and the hasChild flag, plus the root-vs-child behavior when parent is omitted. It omits auth/permission 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-loaded and sectioned (Use when / Don't use / Returns / Pair with / Cost) for easy scanning. Slightly redundant, with pagination covered in both the Returns and Cost sections, which prevents a perfect score.

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

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

The description fully compensates for the absent output schema by enumerating returned fields, and it explains the pagination model, root-node behavior, and the drill-down workflow. 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% (baseline 3), but the description adds real meaning beyond the schema: omitting parentBrowseNodeIdPath fetches top-level roots, and it explains how each result's browseNodeIdPath feeds back in for the next drill level. page/size defaults restate the schema but the pagination-strategy note is 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+resource (list direct children of an Amazon category node) and immediately scopes it against siblings like search_categories and list_category_products. An agent can differentiate it from every neighboring tool without opening a schema.

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

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

Explicit 'Use when' triggers (drill to level 3, list top-level departments) and 'Don't use' exclusions that name the correct alternatives (search_categories for keyword jumps, list_category_products for products). The Pair with section further clarifies upstream/downstream usage.

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?

No annotations exist, so the description carries the full burden, and it does most of it: return shape, cost (~1 point/call, ~2s), and the efficiency claim vs N single resolutions. It stops short of permission/auth behavior, but for a read-only resolver the disclosed cost, latency, and return contract are substantial.

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 before labeled sections, and every section (Use when / Don't use / Returns / Pair with / Cost) earns its place. Slightly verbose with the arrow notation in 'Pair with', but nothing is wasted.

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

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

No output schema exists, and the description compensates by spelling out the exact returned fields (categoryId, categoryName, browseNodeNamePath, etc.) and noting one row per input ID. An agent has everything needed to call and interpret the result.

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

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

Schema description coverage is 100%, so all three parameters are already documented (including the categoryIds example and site default). The description adds no parameter-level semantics 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+resource: 'Batch-resolve categoryId list to full paths' with a concrete example output ('Electronics > Headphones > Over-Ear Headphones'). It explicitly distinguishes itself from get_category_children, so an agent can tell it apart from the closest sibling 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?

Explicit 'Use when' section names three triggering conditions (readable category context, list of numeric IDs needing names, labeling for comparison) and 'Don't use' rules out single-ID use and tree traversal, naming get_category_children as the alternative. Routing is fully specified.

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?

With no annotations, the description carries the full behavioral burden and does so substantially: it discloses the cost (~1.5 points/call), latency (~5s), the Google Trends data source, a ToS compliance obligation, and the critical 0-100 relative-scale caveat. It omits auth/permission requirements and rate limits, keeping it short of a 5, but the disclosure is well above average for an unannotated tool.

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

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

Strongly front-loaded with purpose, then cleanly sectioned into Use when / Don't use / Returns / Pair with / Cost / Tips. It is longer than typical, and the raw inline dump of the nested return JSON is dense, but each section contributes concrete value 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?

Absent both annotations and an output schema, the description fully compensates: it enumerates the return structure in detail, states cost and latency, and documents every meaningful parameter behavior. Nothing essential for correct invocation or result interpretation 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 already 100%, so baseline is 3, but the description adds practical semantics beyond the schema: recommended timeRange values, 'WORLD' vs ISO country for region, and the note that language drives related-query language. The Tips section reinforces parameter usage in a way the schema fields alone do not.

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 tool function (keyword popularity trends from Google Trends) and its outputs (time series, per-region heatmap, rising related queries) up front. It clearly distinguishes itself from siblings by naming search_amazon and ai_search as the tools for other tasks. An agent can identify this tool's domain 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?

Contains an explicit 'Use when' list of user phrasings and a 'Don't use' list that names concrete alternative tools (search_amazon, ai_search) and the conditions that select them (absolute volume, products/links, single-keyword snapshots). The routing logic is fully spelled out rather than implied.

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?

With no annotations, the description carries the full burden and does well: it discloses cost (~1 point/call), latency (~5s), and the double-parse quirk of recsList being a JSON string. It does not cover error behavior, auth requirements, or rate ceilings, so it falls short of fully self-sufficient.

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?

Labeled sections (Use when / Don't use / Returns / Pair with / Cost / Tips) are front-loaded and scannable. Despite its length, every block carries distinct operational information — 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?

No output schema exists, and the description compensates by unpacking the exact return path (data.json[0].data.{reftag, recsList}) and row fields. For a 5-param, annotation-free tool this is complete enough to call correctly on the first attempt.

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 slug format, site enum, and zipcode constraints are already documented in the schema. The description adds the downstream pairing tip (feed ASIN into get_amazon_product), which is useful but modest added value over structured data.

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+scope: 'Top-50 ranking for a category with 24h rank deltas.' It also names the sibling tools it is not (list_new_releases, list_category_products, search_categories), so an agent can distinguish it 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?

Explicit 'Use when' triggers quote real user phrasings ('who's #1 in X', 'any new entrants climbing') and a 'Don't use' block names three alternatives with the condition that selects each. Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and does so well: it discloses pagination semantics (nextPage=null means last page), cost (~1 point/page, ~5s), and a sensible 'only paginate when explicitly asked' constraint. It omits backend/auth requirements and rate-limit behavior, so it falls just short of fully covering the no-annotation 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?

Organized into labeled sections (Use when / Don't use / Returns / Pair with / Cost), front-loading the core action and scoping constraint. Every sentence carries routing, cost, or pagination information with no filler.

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

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

For a 6-parameter, no-annotation, no-output-schema listing tool, the description supplies return shape (data.json[0].data...results fields), pagination mechanics, cost, and cross-tool relationships. An agent has everything needed to invoke and interpret 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 page, site, format, nodeId, zipcode, and clientSource. The description largely restates the 'page' and 'nodeId' semantics rather than adding new meaning, 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 ('List concrete on-sale products under a Browse Node ID') with scope details (paginated, 24 rows/page). It explicitly distinguishes itself from list_bestsellers, filter_categories, and filter_niches, so an agent can route correctly without opening sibling 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?

Provides explicit 'Use when' triggers with user-phrasing examples, an explicit 'Don't use' block naming three alternatives and the conditions that select them, and 'Pair with' upstream/downstream tool relationships. Nothing is left to inference.

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

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

No annotations, so the description carries the full burden and largely succeeds: it discloses the ~1 point/5s cost, the backend cap, and a non-obvious return quirk (recsList is a JSON-string that must be parsed twice). It does not cover auth requirements or rate-limit semantics, but the operational cost and data-shape disclosures are more than most tools 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?

Dense but organized into labeled sections (Use when / Don't use / Returns / Pair with / Cost) with the core purpose front-loaded. Every sentence carries actionable information; 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?

With no output schema, the description compensates by describing the return path and row structure. Combined with pairing guidance and cost, an agent has everything needed to call and interpret this 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% with enums for site/format/clientSource, so parameters are already well documented. The description adds only light context (categorySlug convention 'as in list_bestsellers', reftag slug format) which is marginal beyond the schema's own examples.

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+scope: 'Top-50 ASINs that hit the market within the last 30 days for a category', plus an honest backend cap caveat. The 'Don't use' section explicitly names sibling tools (list_bestsellers, list_category_products, search_categories), so an agent can differentiate 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?

Provides concrete trigger phrases ('new arrivals in X', 'any breakout new products'), use cases (GTM scouting, competitor radar), and explicit exclusions with the alternative tool to use instead for each. This is textbook 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?

No annotations are provided, so the description carries the full burden and it does so: cost (~1 point/page, ~5s), billing semantics (pageCount billed by pages actually crawled, failed pages refunded), the 2-QPS rate wall and budget implications of fanning out, plus the state-mutating effect that pageIndex/nextPage are blanked when pageCount>1.

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 when-to-use and return shape before the deep chaining guidance, and every section has a job. It is dense and somewhat repetitive — the 'sort by results[].rank, do not fan out PDP fetches' instruction appears three times across the returns, chaining pitfall, and tips blocks.

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?

Although no output schema exists and no annotations exist, the description spells out the exact return path and fields (data.json[0].data.{pageIndex,maxPage,nextPage,results[{asin,title,price,star,rating,rank,img}]}) plus pagination termination via nextPage/maxPage, which is everything an agent needs to call and consume the result.

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

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

Schema coverage is already 100%, so the baseline is 3; the description earns above baseline by explaining the cross-parameter interaction between the two pagination modes (page is ignored when pageCount>1, both accumulate from page 1) and by naming concrete extraction points for categoryId (rh=n:<id>) and sellerId.

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 ('List all listings under a merchant ID') and immediately bounds the scope with 'paginated (24 rows/page)'. It also differentiates from the obvious sibling by warning that a single product should use get_amazon_product instead.

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?

Contains explicit 'Use when' scenarios quoting actual user phrasings and an explicit 'Don't use' clause naming the blocker (no merchant ID) and the alternative tool (get_amazon_product). The 'Pair with' section further states both upstream sources (get_amazon_product seller.id, /sp?seller= URL) and downstream usage.

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?

With no annotations, the description carries the full burden and does so: it discloses no backend call, zero cost/local data, that it does not consume downstream tools, that summary mode only gives one-liners, and cites a contract constraint (CONTRACT §9) preventing account endpoints. That is unusually rich behavioral context for a read-only introspection tool.

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

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

Labeled sections (Use when / Don't use / Returns / Pair with / Cost) make it scannable and front-loaded. Minor redundancy: 'no backend call, free' is repeated later as 'Cost: 0 points (local data, no backend round-trip)', costing a small amount of tightness.

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?

Although no output schema exists, the description enumerates the return shape (version, locale, liveTools[{name, domain, oneLiner, cost}], workflows, tips), and covers cost, side effects, and next-step pairing. 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 description coverage is 100% and both params are enum-documented, so the schema already explains detail modes and clientSource. The description's phrase 'the summary mode here gives one-liners only' adds slight nuance about the detail param but largely restates the schema, 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 ('get the full capability catalog, canonical workflows, and usage tips') and explicitly frames itself as self-introspection, which cleanly separates it from all 20 sibling tools that hit Amazon data. An agent can immediately tell this is the meta/menu tool rather than a data tool.

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

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

Provides explicit 'Use when' triggers (first connection, 'what can you do' questions, SOP planning) and an explicit 'Don't use' clause that routes to tools/list for single-tool detail and forbids using it for account balance. Both the alternative and the exclusion condition are named.

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?

With no annotations, the description carries the full burden and largely delivers: it discloses cost (~1 point/call, ~5s), return shapes per parserName, a failure mode where mismatched content/url yields unparsed data.{status_code, rawHtml, url}, and the mutual-exclusion rule that exactly one of content/url must be passed. These are non-obvious operational traits (cost, error semantics, silent-unparsed fallback) that an agent could not infer from the schema alone.

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 long, but the length is driven by a genuinely complex tool (7 params, 9 parsers, two mutually exclusive input modes) and it is well-structured with bold headers, bullets, and a front-loaded statement of what the tool is. A little redundancy between the mode descriptions and the 'Use when' block keeps it just short of 5.

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 supplies the missing return shape (json path, amzFollowSeller item fields including hasSoldByLink) and the unparsed fallback shape. It also covers cost, error conditions, the url-only filtering constraint, and downstream pairing (feed asin into get_amazon_product/get_amazon_reviews), which is everything an agent needs to call it correctly.

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

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

Schema coverage is 100%, so 3 is the baseline, but the description adds genuine semantics the schema does not: that content mode carries NO filter/sort/pagination, that filtering is only possible via url mode, and concrete filter-syntax fragments (low-price/high-price, s=review-rank, page=2, rh/fs category filters). That mode-selection meaning goes beyond the field-level 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?

It states a concrete verb+resource ('Scrape pages the 5 purpose-built tools don't cover') and immediately names the escape-hatch role relative to siblings. The 'Don't use' clause routes plain keyword search, single ASIN, seller, and category-rank requests to search_amazon, get_amazon_product, list_seller_products, and list_bestsellers/list_new_releases respectively, so an agent can distinguish it 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?

Explicit 'Use when' and 'Don't use' clauses give both positive and negative routing criteria, and the two input modes are gated by their own when-to-use guidance (content for simple pages with only a fragment; url whenever filtering/sorting/pagination is needed, with the rule that filtering requires url mode). Alternatives are named by tool, not 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?

No annotations exist, so the description carries the full burden and does so well: it discloses cost (~1 point/page, ~5s), page size (~22 rows), pagination semantics via nextPage, and the operational discipline 'only paginate when the user explicitly asks'. This is the behavioral context an agent needs that no structured field provides.

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 with labeled sections (Use when / Don't use / Returns / Pair with / Cost) that make scanning easy. Slightly verbose — pagination guidance is repeated in both the body and the schema's 'page' description — but every section earns its place.

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

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

With no output schema, the description fully specifies the return structure (data.json[0].data.{...results[]}), page size, cost, pagination, and downstream pairing. 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 baseline is 3, but the description adds meaning beyond the schema: it explains the format='json' default and its row shape, and reinforces pagination intent with nextPage semantics. It does not contradict the schema's own parameter docs, though there is some overlap.

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

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

States a specific verb and resource ('Run a real Amazon keyword search and return the first-page ASIN list') and explicitly names the sibling tools it is not (get_amazon_product, list_bestsellers, ai_search, keyword_trends). An agent can distinguish it from every related tool without opening a schema.

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

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

Provides explicit 'Use when' triggers (user says 'search Amazon for X', need ASINs as upstream input) and 'Don't use' exclusions that route to the correct alternatives per scenario. When-to-use, when-not, and alternatives are all covered.

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?

There are no annotations, so the description carries the entire burden and does so thoroughly: point cost (6 per prompt, N×6), a 120-second client-side timeout requirement, an explicit warning against concurrent duplicate calls, the distinction between the native HTTP path and the slower browser screenshot path, and the caveat that products and suggestions may be empty. It also discloses that context is shared only within a single call, which materially affects how an agent should batch prompts.

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 before the labeled Use when / Returns / Cost / operational blocks, and each block is a single dense sentence. It runs long, but on a tool with no annotations and no output schema nearly every line carries information an agent needs; only the returns-format block slightly duplicates what the schema's nested field naming implies.

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 no annotations, the description fills both gaps: it sketches the return shape (prompt, content, products with nested items, follow_up_questions), warns results may be empty, and covers cost, latency, concurrency, and market-pool behavior. Nothing an agent needs to invoke this correctly or set expectations 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 every parameter already carries its own documentation, including the pool-isolation failure mode, the 1–5 prompt limit, per-prompt cost, and the screenshot path. The description largely restates the same facts rather than adding new meaning such as prompt phrasing guidance or examples, 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 first sentence names a specific verb and mechanism (ask Amazon Rufus) and enumerates the concrete outputs: answers, grouped product recommendations, follow-up suggestions. It also frames the scope boundary (US vs Japan pools), and the 'Use when' clause explicitly distinguishes it from search_amazon and get_amazon_product, so an agent can separate it from all three siblings without opening a schema.

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

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

Explicit when-to-use is given ('scenario-based discovery, gifts or open-ended shopping advice') paired with named alternatives and the condition that selects each ('search_amazon for explicit keywords', 'get_amazon_product for a single ASIN'). This is the full when/when-not/alternative pattern rather than an implied context.

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?

With no annotations, the description carries the full burden and does well: it discloses the return shape (browseNodeId, path, names, sellable, hasChild, pagination) and cost (~1 point/call, ~3s). It implies a read-only search but never explicitly states non-mutating behavior or pagination limits, so a 4 rather than 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 purpose followed by labeled Use/Don't use/Returns/Pair with/Cost sections that each earn their place. It is dense and slightly long, but structured and scannable rather than padded.

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

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

For a keyword-search tool with no output schema and no annotations, the description covers purpose, routing, return fields, cost, and downstream pairing – everything an agent needs to invoke it correctly and chain it.

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 both the keyword and site parameters are already documented in the schema, including the Chinese/English keyword examples that the description merely echoes. Baseline 3 is correct 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?

States a specific verb (match/search) and resource (Amazon category tree by keyword) and immediately names the sibling tools it is not (get_category_children, get_category_paths). An agent can distinguish it from sibling category tools 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?

Explicit 'Use when' and 'Don't use' sections give conditions including the case of already having a categoryId/nodeId, routing to get_category_paths or get_category_children as alternatives. Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the data source (Google Maps), a Terms-of-Service compliance obligation, cost (~1.5 points/call) and latency (~5s). It stops short of stating quota/rate-limit ceilings or failure modes on empty geocodes, so it is strong but not exhaustive.

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

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

Labeled sections (Use when / Don't use / Returns / Pair with / Cost / Tips) make it scannable and front-loaded with purpose. The opening sentence's partial return list ('name, address, rating, review count') is then restated in the Returns block, a small redundancy in an otherwise dense, purposeful text.

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 enumerates the return shape (data.organicResults with place_id, name, about, rating, borough, city, etc.). With 7 parameters and only 3 required, it documents zoom/query/lat/lng but is silent on limit, language, and clientSource, leaving minor gaps for a search tool of this complexity.

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, but the description adds practical meaning: zoom 13 yields a whole neighborhood while 17+ narrows to one street, and it pairs query with latitude/longitude/zoom as the dial that controls result scope. It adds less for limit, language, and clientSource, which remain schema-only.

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 ('Local-business search') and pins the scope to a lat/lng center returning name, address, rating, review count. It explicitly names what it is not (e-commerce Amazon series, keyword_trends, ai_search), so an agent can route correctly without opening a schema.

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

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

Contains explicit 'Use when' triggers (local business counts, offline channel/competitor research, physical-store density) and a 'Don't use' block that routes to three named sibling tools for the cases this tool does not cover. Both directions are covered with concrete examples.

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?

No annotations are supplied, so the description carries the full burden, and it does: exact cost (~2 points/call, ~5s), conditional +12 point litigation charge, billing re-trigger on pagination, backend rejection rules for CNID+hol/prod, and silent-ignore quirks (USID no STATUS, JPID no HOL/PROD, ed ignored). These are non-obvious operational behaviors an agent could not infer elsewhere.

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 cleanly sectioned into Use when / Don't use / Returns / Pair with / Cost / Perf contract, so the density is navigable. It is on the heavy side and the 'Pair with' line partially restates schema param descriptions, but for a 14-parameter tool most sentences earn their 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 spells out the return shape (data.data.hits[], DETAIL_DATA fields, IMG_DATA, plus the litigationStatus/caseTotal/cases join) and the pagination/partition constraints. Nothing material for correct invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the aliasing map (hol/prod/irn/lcs), the required-source dependency, and the enableLitigation chaining behavior that ties one param to a whole litigation lookup.

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 — 'Query the WIPO design database across 12 sources' — and names concrete sources (USPTO US designs, CNID, HAGUE). It also explicitly distinguishes itself from the surrounding commerce siblings by declaring this is an IP database, not a commerce database.

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 an explicit 'Use when:' block with concrete trigger utterances ('check trademark', 'WIPO search', 'any IP risk for new product') and a 'Don't use:' block excluding keyword ranks, product reviews, and US text-trademark search. The when/when-not/alternative split is fully specified.

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