Server Quality Checklist

Tool Scores

• filter_categoriesA
  4.5/5.0
  Behavior4/5

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

  Discloses cost (~1 point/page, ~5s), pagination limits, and extraFilters pass-through. No annotations, so description covers behavior adequately, though could explicitly state read-only nature.

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

  Conciseness4/5

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

  Well-structured with purpose upfront, then usage, don't-use, returns, pairing, cost, and tips. Slightly long but every sentence adds value; could be more concise.

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

  Completeness4/5

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

  For a tool with 20 parameters and no output schema, the description covers return structure, pagination, cost, and limitations. Additional info like example field names and pairing with other tools enhances completeness.

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

  Parameters4/5

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

  All parameters have schema descriptions (100% coverage). Description adds context: categoryId dual role, timeRange examples, pagination limits, and extraFilters usage. Adds value beyond schema.

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

  Purpose5/5

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

  Clearly states it filters categories by metrics or acts as a detail endpoint. Distinguishes from siblings like filter_niches and list_category_products.

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

  Usage Guidelines5/5

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

  Explicitly lists when to use (e.g., 'find categories worth entering') and when not to use, with specific alternative tools. Provides pairing and pagination tips.

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

• search_local_mapsA
  4.5/5.0
  Behavior4/5

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

  Discloses data source (Google Maps), cost (~1.5 points), latency (~5s), and zoom behavior tips. No annotations provided, so description carries burden; lacks details on authentication or rate limits.

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

  Conciseness4/5

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

  Well-structured with clear sections, front-loaded purpose. Slightly verbose but every sentence adds value; appropriate for tool complexity.

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

  Completeness4/5

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

  Covers purpose, usage, return structure, cost, tips. No output schema, so return description is helpful but could elaborate on field semantics. Overall adequate for a search tool.

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

  Parameters4/5

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

  Schema coverage is 100%, baseline 3. Description adds value with zoom level usage examples ('13 gives neighborhood, 17+ narrows to street') and pairing hints. Slightly above baseline.

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

  Purpose5/5

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

  Clearly states 'Local-business search' at a lat/lng, lists returned fields, and distinguishes from sibling tools like ai_search and keyword_trends with explicit 'Don't use' instructions.

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

  Usage Guidelines5/5

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

  Provides explicit 'Use when' and 'Don't use' sections with concrete examples and alternatives (e.g., 'use keyword_trends' for global trends), plus pairing advice.

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

• get_category_pathsA
  4.6/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It discloses cost (~1 point/call), speed (~2s), and that it's cheaper than N single resolutions. Also notes downstream rarely depends on it (presentation-only). No contradictions.

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

  Conciseness4/5

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

  Description is well-organized into sections with bullet points for returns and pairing. Slightly verbose but each sentence adds value. Could be slightly more concise but no waste.

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

  Completeness5/5

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

  No output schema, but description explains return structure in detail (data.items with fields). Parameter meanings are clear from schema and description. For a simple 2-param tool, this is fully complete.

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

  Parameters4/5

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

  Schema description coverage is 100% with both parameters having descriptions. The description adds context beyond schema: provides example paths, explains batch behavior, and details return format. Baseline 3, increased due to added value.

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

  Purpose5/5

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

  Description clearly states it batch-resolves category IDs to full paths with an example ('Electronics > Headphones'). Explicitly distinguishes from sibling tool get_category_children (tree structure) and notes other tools already return browseNodeNamePath for single IDs.

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

  Usage Guidelines5/5

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

  Explicitly states when to use (need readable category context, multiple IDs) and when not to use (single ID, tree structure). Also mentions pairing with prior steps like filter_niches/filter_categories output.

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

• keyword_trendsA
  4.7/5.0
  Behavior5/5

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

  Discloses cost (~1.5 points/call, ~5s), data source (Google Trends), limitations (relative scale 0-100, not absolute), and tips for timeRange, region, language. Since no annotations exist, the description fully covers behavioral traits.

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

  Conciseness4/5

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

  Well-structured with bolded sections, bullet points, and clear separation of sections. Slightly verbose but every sentence adds value. Could be tightened, but remains effective.

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

  Completeness4/5

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

  Returns are described in detail (data.json structure with keywordsGeoData, timelineData, etc.) despite no output schema. Cost and tips are included. The description covers all critical aspects for agent invocation.

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

  Parameters4/5

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

  Schema has 100% description coverage. The description adds meaningful context beyond defaults: examples for keywords (synonyms, competing brands, seasonality), highlights common timeRanges, and explains language influences related-query language.

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

  Purpose5/5

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

  The description opens with 'Keyword Trends via Google Trends' and clearly explains it provides popularity time series, per-region heatmap, and rising related queries. It also explicitly distinguishes from siblings by stating it is not for absolute search volume or products/links, and requires at least 2 keywords for meaningful comparison.

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

  Usage Guidelines5/5

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

  Provides explicit 'Use when' and 'Don't use' sections with many concrete scenarios e.g., 'how hot is keyword X', 'A vs B popularity', 'find breakout terms'. Also gives pairing instructions with sibling tools like search_amazon and filter_niches.

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

• list_bestsellersA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the cost (~1 point, ~5s), response structure details (including nested JSON), and behavior of the zipcode parameter (optional, random when omitted). It could mention rate limits or authentication, but the provided information is sufficient for safe invocation.

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

  Conciseness5/5

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

  The description is exceptionally well-structured: a bold summary, then clear 'Use when', 'Don't use', 'Returns', 'Pair with', and 'Cost/Tips' sections. Every sentence adds value without redundancy. It is packed with information while remaining easy to scan.

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

  Completeness5/5

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

  Despite having no output schema, the description thoroughly explains the return value structure, including the need to parse recsList twice and the fields within each row. It also covers cost, tips, and parameter behavior. For a tool with 4 parameters, this is complete.

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

  Parameters4/5

  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 adds value by explaining how to find the categorySlug (via URL), the meaning of the zipcode parameter with examples, and the purpose of the format parameter. This extra context elevates the score above the baseline.

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

  Purpose5/5

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

  The description opens with a clear statement: 'Top-50 ranking for a category with 24h rank deltas.' It specifies the resource (Amazon Best Sellers), the verb (list), and key features (rank, deltas). It also distinguishes from siblings like list_new_releases and list_category_products, making the purpose unmistakable.

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

  Usage Guidelines5/5

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

  The description provides explicit 'Use when' scenarios (e.g., 'user says X category bestsellers'), explicit 'Don't use' cases with alternatives (e.g., 'for new arrivals use list_new_releases'), and pairing suggestions with other tools. Tips for obtaining the categorySlug and cost/time estimates further guide appropriate use.

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

• get_amazon_reviewsA
  4.8/5.0
  Behavior5/5

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

  No annotations provided, but description fully discloses expensive cost (10 points per page), recommends starting with pageCount=1, and provides strategic tips on filters. Also explains return structure and pairing with other tools for downstream tasks.

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

  Conciseness4/5

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

  Well-structured with sections (use when, don't use, returns, cost, tips) and front-loaded with purpose. Though lengthy, each sentence adds value; slight reduction possible without losing clarity.

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

  Completeness5/5

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

  No output schema, but description provides detailed return structure (fields like reviewId, date, star, content) and explains pairing with other tools. Covers all aspects for a complex 7-param tool with enums and strategic advice.

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

  Parameters4/5

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

  Schema coverage is 100%, baseline 3. Description adds significant value by explaining the purpose of each filter (e.g., 'critical' for pain-point mining), giving usage examples, and providing cost/strategy tips beyond schema details.

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

  Purpose5/5

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

  Clearly states batch scraping of real buyer reviews for an ASIN with filtering options. Uses specific verb 'page-fetch' and resource 'reviews', distinguishing from get_amazon_product which carries only 5-10 reviews.

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

  Usage Guidelines5/5

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

  Explicitly lists use cases (e.g., 'look at X's negative reviews', 'mine pain points') and when not to use (when PDP reviews suffice or for keyword search), with alternative tools named (get_amazon_product, search_amazon).

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

• get_category_childrenA
  4.8/5.0
  Behavior5/5

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

  No annotations provided, so description carries full burden. It discloses response structure (fields like browseNodeId, hasChild), pagination details (page, size, hasNext), cost (~1 point/page, ~3s), and a usage caveat (only paginate when necessary).

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

  Conciseness4/5

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

  Description is detailed but well-structured: purpose first, then usage guidelines, return details, pairing, cost. Every sentence adds value. Could be slightly more concise, but front-loading ensures agent gets key info quickly.

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

  Completeness5/5

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

  Given no annotations and no output schema, description covers all essential aspects: purpose, when to use vs avoid, parameter details, return structure, pagination, cost, and pairing with siblings. No gaps for an agent to invoke correctly.

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

  Parameters4/5

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

  Schema has 100% coverage, but description adds value by explaining parameter usage beyond schema: examples of parentBrowseNodeIdPath values (e.g., '2619526011'), how omitting it fetches roots, and pagination parameter behavior (defaults, max size). Adds context without redundancy.

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

  Purpose5/5

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

  The description clearly states the tool lists direct children of a category node in Amazon's category tree, using specific verbs ('List direct children') and resources ('from any node or start at roots'). It distinguishes from siblings like search_categories (keyword jump) and list_category_products (products vs subcategories).

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

  Usage Guidelines5/5

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

  Explicitly provides when to use (e.g., 'show me Amazon's category tree', 'subcategories under X', 'list top-level departments') and when not to use (keyword jumps, product listing). Also mentions pairing with sibling tools like search_categories and list_category_products.

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

• search_amazon_alexaA
  4.8/5.0
  Behavior5/5

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

  No annotations provided, so description carries full burden. Details: 6 points per prompt (not per call), slow (60-90s per prompt), linear scaling, do not retry, output structure including snake_case follow_up_questions.

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

  Conciseness4/5

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

  Description is well-structured with clear sections but somewhat verbose. Front-loaded purpose and usage, but could be trimmed without losing essential info.

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

  Completeness5/5

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

  Given complexity (cost, slowness, output structure) and no output schema, description is thorough: explains return format, cost billing, pairing, and warnings.

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

  Parameters4/5

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

  Schema coverage is 100% with detailed descriptions. Description adds value by emphasizing cost, slowness, and usage recommendations beyond schema.

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

  Purpose5/5

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

  Description clearly states it uses Amazon Rufus AI for conversational product recommendations. Explicitly distinguishes from siblings: lists when not to use and alternatives (search_amazon, list_bestsellers, get_amazon_product, ai_search).

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

  Usage Guidelines5/5

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

  Provides explicit 'Use when' and 'Don't use' sections. Also gives strong guidance on preferring 1 prompt per call due to cost and slowness.

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

• ai_searchA
  4.9/5.0
  Behavior5/5

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

  Discloses cost (~2 points), slowness (~30s), return format structure, behavioral differences between modes, followups limit, and legal compliance. No annotations exist, so description carries full burden and meets it comprehensively.

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

  Conciseness4/5

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

  Description is moderately long but well-structured with sections. Every sentence adds value, though a minor reduction could improve conciseness without losing information.

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

  Completeness5/5

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

  Given 4 parameters and no output schema, the description covers input semantics, behavioral traits, return format, cost, usage guidance, and integration hints. No gaps identified.

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

  Parameters5/5

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

  Schema coverage is 100%, but description adds significant value: query examples, mode behavior explanation, followups degradation warning, screenshot purpose. This goes beyond the schema's basic descriptions.

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

  Purpose5/5

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

  Description clearly states the tool scrapes Google search results with two modes. It distinguishes from siblings by mentioning on-Amazon vs external search and trend-curve tools.

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

  Usage Guidelines5/5

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

  Explicit use cases are listed (e.g., 'Google for me', 'consumer voice' step) and explicit non-use cases (on-Amazon, trend curve) with alternative tools named. Also provides pairing guidance.

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

• list_category_productsA
  4.9/5.0
  Behavior5/5

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

  Discloses pagination logic (page param, nextPage, maxPage), cost (~1 point/page, ~5s), and explicit instruction to only paginate when user asks. No annotations exist, but description fully covers behavioral traits.

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

  Conciseness4/5

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

  Long but well-structured: core purpose first, then guidelines, return format, pagination, pairing, cost. Every sentence earns its place, but slightly verbose with repetition of pagination info in both description and param section.

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

  Completeness5/5

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

  With no output schema, description details return structure and pagination behavior. Covers pairing, cost, and when to paginate. Complete for a complex tool with five parameters.

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

  Parameters5/5

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

  Schema coverage is 100%, but description adds context: nodeId sources, zipcode cross-country rejection, format 'markdown' usage, and pagination details for page param. Each parameter is enriched with usage examples.

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

  Purpose5/5

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

  The description clearly states it lists on-sale products under a Browse Node ID, paginated with 24 rows per page. It distinguishes from siblings like list_bestsellers and filter_categories, making the purpose unambiguous.

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

  Usage Guidelines5/5

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

  Explicitly states when to use (category listing after picking nodeId) and when not to use (top 50 winners, aggregate metrics, niche). Also specifies pairing with other tools, providing comprehensive guidance.

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

• list_new_releasesA
  4.9/5.0
  Behavior5/5

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

  In the absence of annotations, the description fully discloses behavior: backend cap, cost (~1 point/call, ~5s), and detailed return structure including parsing instructions for recsList. No contradictions.

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

  Conciseness5/5

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

  Despite length, description is well-structured with clear sections (what, use when, don't use, returns, pair with, cost). Each sentence adds value; no redundancy.

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

  Completeness5/5

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

  Given 4 parameters and no output schema, the description provides complete guidance: param details, return format with parsing, pairing suggestions, and cost. All necessary information for correct invocation is present.

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

  Parameters4/5

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

  Schema coverage is 100%, but the description adds extra context (e.g., where to find categorySlug, cross-country zip rejection, format usage). This goes beyond the schema descriptions, justifying a score above baseline 3.

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

  Purpose5/5

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

  The description clearly states it returns the top-50 best-selling new releases (within 30 days) for a category, with explicit mention of 'Amazon New Releases' and backend cap. It distinguishes from siblings by specificity to new releases.

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

  Usage Guidelines5/5

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

  Explicitly lists when to use (e.g., 'new arrivals', 'breakout new products') and when not to use (e.g., 'for evergreen winners use list_bestsellers'). Provides clear alternatives and context.

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

• list_seller_productsA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description fully bears the burden of behavioral disclosure. It details two pagination modes (page vs pageCount), how pageCount merges pages, what happens to response fields when multi-page accumulate is used (pageIndex/nextPage blanked), billing (1 point/page), timing (~5s), and error handling (failed pages refunded).

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

  Conciseness4/5

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

  The description is well-structured with paragraphs, bullet points, and clear headings. It front-loads the core purpose and usage guidance. While it is lengthy, every sentence adds value – the tool is complex and requires this level of detail. A slight improvement could be further condensing the 'Tips' section into the parameter descriptions.

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

  Completeness5/5

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

  Despite having no output schema, the description explicitly documents the response structure (data.json[0].data.{ pageIndex, maxPage, nextPage, results[...] }) and explains how to iterate with nextPage. It covers all parameters, two pagination modes, category filtering, marketplace defaults, and integration with sibling tools. For a 7-parameter tool with multiple modes, this is very complete.

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

  Parameters5/5

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

  The input schema already has 100% coverage, but the description adds substantial context: how to find sellerId (from product page 'sold by' link or amazon.com/sp URL), zipcode cross-country rejection, the difference between page and pageCount (one locates a specific page, the other accumulates), and how to extract categoryId from storefront URL. This goes far beyond what the schema alone provides.

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

  Purpose5/5

  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: 'List all listings under a merchant ID, paginated (24 rows/page).' It immediately communicates the tool's scope (entire catalog of a seller) and distinguishes it from single-product tools like get_amazon_product.

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

  Usage Guidelines5/5

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

  The description provides extensive usage guidance: explicit use cases ('show me this seller's products', 'competitor storefront category breadth'), a clear 'Don't use' section (requires merchant ID, not for single product), and pairs with sibling tools (get_amazon_product for deep-dives). It even explains how to extract the required sellerId.

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

• pangolinfo_capabilitiesA
  4.9/5.0
  Behavior5/5

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

  No annotations provided, so description fully bears the burden. Discloses that it's local with no backend call, cost 0 points, and returns a specific structure. No contradictions; all behavioral traits are clearly stated.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (purpose, use cases, don't use, returns, pairing, cost). However, it is slightly verbose; could streamline some phrasing without losing meaning. Still very effective.

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

  Completeness5/5

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

  Given no output schema, the description provides a detailed return structure (version, locale, tools, workflows, tips). Parameter semantics fully covered. Context about cost and usage pairs is complete. Siblings are many but tool's unique role is clear.

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

  Parameters5/5

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

  Schema coverage is 100% with one parameter 'detail'. Description adds value by explaining the enum values ('summary' vs 'full') and their effects, including token size estimates. This goes beyond the schema's description.

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

  Purpose5/5

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

  The description clearly defines the tool as a self-introspection call that returns the full capability catalog, canonical workflows, and usage tips. It uses specific verbs ('get') and resources ('capability catalog') and distinguishes from siblings by being local and free, contrasting with tools/list for detailed descriptions.

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

  Usage Guidelines5/5

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

  Explicitly states when to use (first connection, user asks 'what can you do', capability audit before SOP planning) and when not to use (for full tool descriptions, for account balance). Also mentions pairing with deciding which tool to call next, providing clear guidance.

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

• search_amazonA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description fully covers behavioral traits: pagination details (nextPage, page param), response structure, cost (~1 point/page, ~5s), and when to paginate (only on explicit user request). No contradictions.

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

  Conciseness4/5

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

  The description is dense and well-structured, front-loading purpose and usage. While every sentence is informative, it is slightly verbose due to extensive usage guidelines and pairing info. Could be more concise but still effective.

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

  Completeness5/5

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

  Given no output schema, the description covers return structure, pagination, cost, and pairing with siblings. All parameter details are thorough, and the context of sibling tools is addressed. Complete for a search tool.

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

  Parameters5/5

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

  All 5 parameters have schema descriptions (100% coverage). The description adds value by explaining format choices, zipcode cross-country rejection, and pagination guidance beyond schema.

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

  Purpose5/5

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

  The description begins with a clear verb and resource: 'Run a real Amazon keyword search and return the first-page ASIN list.' It also distinguishes from siblings by explicitly listing tools for single ASIN detail, bestseller ranks, and external demand.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use triggers (e.g., 'user says "search Amazon for X"') and when-not-to-use alternatives (e.g., 'Don't use: for a single ASIN detail (use get_amazon_product)'). Also includes pairing instructions for deeper analysis.

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

• search_categoriesA
  4.9/5.0
  Behavior5/5

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

  Although no annotations are provided, the description fully discloses behavioral traits: it is a search (read-only implied), returns a detailed structure with fields, costs ~1 point and ~3 seconds, and pairs with downstream tools. No contradictions exist.

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

  Conciseness5/5

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

  The description is well-structured with clear sections: summary, use when, don't use, returns, pair with, and cost. Every sentence adds value, and the key information is front-loaded. It is concise yet comprehensive for the tool's complexity.

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

  Completeness5/5

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

  Given the tool has only 2 parameters and no output schema, the description provides a complete picture: it explains the output format in detail, lists return fields, gives usage guidance, and mentions cost. It covers all necessary context for an AI agent to use the tool correctly.

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

  Parameters4/5

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

  The schema covers both parameters (keyword and site) with descriptions and examples. The description adds value by explaining the purpose of keyword (Chinese or English) and providing concrete examples, which goes beyond the schema's basic description. Baseline is 3, extra context raises to 4.

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

  Purpose5/5

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

  The description clearly states the tool matches Amazon's category tree by keyword and returns candidate nodes. It uses specific verbs ('Match') and resources ('Amazon's category tree'), and distinguishes from siblings by listing use cases and alternatives like get_category_paths and get_category_children.

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

  Usage Guidelines5/5

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

  The description explicitly provides 'Use when' and 'Don't use' conditions, including specific alternative tools (e.g., get_category_paths, get_category_children). It gives clear context for when to use—when user provides a keyword instead of a category ID—and when not to, making it highly actionable for an AI agent.

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

• wipo_searchA
  4.9/5.0
  Behavior5/5

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

  No annotations exist, so the description carries full burden. It discloses critical behavioral details: CNID+hol/prod pairing requirements, source-specific limitations (JPID no HOL/PROD, USID no STATUS, ed ignored), enableLitigation auto-chaining behavior, cost/performance (~2 points, 5s, +12 points only when patents found), and return structure. This is exceptionally transparent.

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

  Conciseness4/5

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

  The description is comprehensive but somewhat lengthy. However, it is well-organized with sections (description, use/don't use, returns, pair with, cost, perf contract) and front-loaded with a clear summary. Every sentence adds value, though conciseness could be slightly improved by condensing repeated 'CNID' warnings.

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

  Completeness5/5

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

  Given the tool's complexity (13 parameters, no output schema, no annotations), the description is remarkably complete. It explains return data structure, pagination, litigation chaining, cost implications, and source-specific constraints. It also mentions pairing with other tools (e.g., DETAIL_URL for verification). This exceeds expectations for completeness.

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

  Parameters5/5

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

  Schema coverage is 100% with parameter descriptions, but the description adds significant meaning beyond schema: pairing constraints (CNID + hol MUST be paired with id/idSearch/rd/status/lcs), source-specific behaviors (JPID no HOL/PROD, USID no STATUS), and usage notes for each parameter (e.g., 'Examples: 'Apple'' for hol). This enriches the agent's understanding.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: querying WIPO design database across 12 sources with TRO risk control. It is specific ('Design Patent TRO risk control · WIPO global design / IP search') and distinguishes from sibling tools like search_amazon by explicitly stating it 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.

  Usage Guidelines5/5

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

  The description provides explicit 'Use when' and 'Don't use' sections, listing example user queries (e.g., 'check trademark', 'design patent search') and explicitly excluding commerce-related searches. It also mentions pairing with source and other parameters, giving clear guidance on when to use this tool versus alternatives.

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

• filter_nichesA
  5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses pagination behavior (page 1-based, size capped at 10, default 3, hasNext flag), cost (~1 point, ~5s), and filter range semantics (e.g., return rate as decimal 0-1).

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

  Conciseness5/5

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

  Well-structured with clear sections (use, don't use, returns, pair with, cost, tips), front-loaded with purpose, and every sentence adds value without redundancy.

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

  Completeness5/5

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

  For a tool with 23 parameters, no output schema, and no annotations, the description is comprehensive: covers pagination, cost, return fields, filter examples, and pairings, making it fully actionable.

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

  Parameters5/5

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

  Schema coverage is 100%, but the description adds critical context: size default rationale (AI context limits), extraFilters pass-through, sortField accepting any response field, and a classic blue-ocean filter combo.

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

  Purpose5/5

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

  The description clearly states it filters Amazon niches by 50+ commercial metrics, serves as a niche detail endpoint, and explicitly distinguishes from sibling tools like filter_categories and search_amazon.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use examples (blue ocean, high search/low competition, niche detail) and when-not-to (full categories, products, plain keyword search) with alternative tool names.

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

• get_amazon_productA
  5/5.0
  Behavior5/5

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

  No annotations exist, so the description carries full burden. It discloses cost (~1 point/call, ~5s), that PDP carries only ~5-10 reviews, and details the return structure. This is highly transparent.

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

  Conciseness5/5

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

  Every sentence is purposeful, structured with clear sections (use/don't use/returns/pair/cost). There is zero waste, and it is front-loaded with the core purpose.

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

  Completeness5/5

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

  Despite no output schema, the description fully enumerates the return fields. It covers cost, timing, pairing, and limitations. The description is complete for an agent to invoke correctly.

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

  Parameters5/5

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

  Schema coverage is 100%, but the description adds value with examples (ASIN examples), usage context for zipcode (cross-country rejection), and format explanations (json vs markdown). It also outlines the entire return object.

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

  Purpose5/5

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

  The description starts with 'Scrape the full PDP for one ASIN', which is a specific verb+resource. It clearly distinguishes from siblings like search_amazon and get_amazon_reviews.

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

  Usage Guidelines5/5

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

  Explicit when-to-use (specific ASIN, SOP step), when-not-to-use (many products, reviews only), and alternatives (search_amazon, list_*, get_amazon_reviews) are all provided.

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

• scrape_urlA
  5/5.0
  Behavior5/5

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

  Despite no annotations, the description discloses behavioral traits: input modes, that content mode carries no filter/sort/pagination, that exactly one of content/url must be provided, that parserName must match the page type, the return shape, error behavior when mismatch, cost (~1 point, ~5s), and pairing advice. This is thorough disclosure.

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

  Conciseness5/5

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

  The description is well-structured with sections (①②), bullet points, and clear warnings. Every sentence adds value; it is efficient and not verbose. The structure makes it easy to parse quickly.

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

  Completeness5/5

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

  Given the tool's complexity (6 parameters, 9 parserName options, two modes), the description covers all necessary aspects: input modes, limitations, prerequisites (parserName match), return shape, cost, pairing with other tools, and error behavior. No gaps are apparent.

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

  Parameters5/5

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

  Schema coverage is 100%, but the description adds significant meaning beyond the schema: it explains the two input modes with examples, when to use each, filter syntax examples for url, parserName mappings, optionality of site and zipcode, and default values. This far exceeds the schema's descriptions.

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

  Purpose5/5

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

  The description clearly states that this is a generic Amazon scrape for pages not covered by 5 purpose-built tools, and explicitly names those sibling tools. It distinguishes itself as a 'power-user escape hatch' with two input modes, making the purpose very specific and unambiguous.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use each mode (content vs url), including filter/sort/pagination requirements, and explicitly states when not to use it (when a purpose-built tool fits), listing exact alternatives like search_amazon, get_amazon_product, etc. This is comprehensive.

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