Server Quality Checklist

Tool Scores

• get_niche_competitorsA
  4.2/5.0
  Behavior4/5

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

  The readOnlyHint annotation already signals a safe read operation, and the description complements this by explaining exactly what data is returned: niche-level statistics and per-competitor fields like ASIN, sales, revenue, and ratings. It does not disclose potential pagination or error behavior, but for a straightforward retrieval tool, the added detail goes beyond the annotation's minimal information.

  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 efficiently structured: a use-case sentence followed by a high-level summary, then bullet-like breakdowns for the niche and competitor data. Every sentence adds distinct value—no filler or redundancy—making it easy for an agent to parse quickly.

  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?

  With only one parameter and no output schema, the description carries the burden of explaining return values. It does so thoroughly, listing the exact metrics for the niche and each competitor. It lacks mention of pagination or result limits, but for a simple single-ID lookup with such detailed return info, it is substantially complete.

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

  Parameters3/5

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

  The schema covers 100% of the single parameter (nicheId) with a clear description referencing list_niches, so the schema already provides full parameter semantics. The description's mention of 'within the specified Niche' merely restates the context without adding new format or constraint details, warranting the baseline score of 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 the tool's function: 'Retrieves the list of Competitors within the specified Niche along with Niche statistics.' It also lists specific use cases ('competitor ASINs, sales/revenue benchmarks, or niche opportunity scoring') and details the returned data for both the niche and each competitor, which makes its purpose distinct from sibling tools like get_niche_keywords or get_niche_roots.

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

  Usage Guidelines4/5

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

  The description opens with 'Use this for competitor ASINs, sales/revenue benchmarks, or niche opportunity scoring,' providing clear context for when to invoke this tool. It does not explicitly name alternatives or state when not to use it, but the use cases imply it is for competitor-centric queries rather than keyword or root analysis, giving adequate guidance.

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

• get_niche_keywordsA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint: true, and the description adds meaningful behavioral context by detailing the return payload: search volume, relevancy (numeric or 'Outlier'), asinRanks mapping, and latestResearchDate. This clarifies the data structure and expected content beyond the annotation.

  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 efficiently structured with a usage trigger, a clear outcome statement, and a compact list of return fields. Every sentence earns its place; no fluff or repetition.

  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?

  With no output schema, the description compensates by describing the returned data fields and a sample structure for asinRanks. It covers the core invocation needs for a one-parameter tool, though it could elaborate on interpreting 'Outlier' or relevancy scores, which is a minor gap.

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

  Parameters3/5

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

  Schema coverage is 100% with a clear description for nicheId (from list_niches). The tool description references 'the specified Niche' but adds no new meaning beyond the schema, which already explains the parameter's origin and purpose. Baseline 3 is appropriate.

  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 usage trigger ('when the user asks about keywords, search terms, or search volume for a niche') and clearly states the tool retrieves the master keyword list. It distinguishes itself from siblings like get_niche_competitors or get_niche_roots by focusing on keywords and search volume.

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

  Usage Guidelines4/5

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

  The description explicitly states when to use the tool ('Use this when the user asks about keywords, search terms, or search volume for a niche'). It does not mention when not to use it or name alternative tools, but the direct trigger provides strong guidance.

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

• list_rank_radarsA
  4.2/5.0
  Behavior4/5

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

  Annotations include readOnlyHint=true, which covers the safety profile. The description adds meaningful behavioral context: pagination behavior, field list, and summary metrics, plus the note that this is a list operation. It does not describe every detail (e.g., default status behavior is in the schema), but it goes beyond the annotation.

  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: a purpose sentence, a filter hint, a definition of the resource, the returned fields, and pagination metadata. Every sentence carries unique information, and the key purpose is front-loaded. No filler or redundancy.

  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 list tool with no output schema, the description documents the response shape sufficiently: item fields and pagination metadata. It also defines what a Rank Radar is. Missing minor details like default status or sorting, but those live in the schema and are easily inferable. Overall complete enough.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameters are fully documented. The description repeats nicheId and mentions pagination but does not add significant semantic value beyond the schema. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description opens with a clear use case ('find a rankRadarId before calling get_rank_radar_data') and explicitly states the resource ('Rank Radars'). It lists what the tool retrieves and the item fields, making it unambiguous and distinct from sibling tools like get_rank_radar_data or create_rank_radar.

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

  Usage Guidelines4/5

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

  Provides concrete guidance on when to use the tool (before get_rank_radar_data) and conditional filtering based on whether a niche is already identified. It does not explicitly mention alternatives or exclusions, but the sequencing and filter hints give clear context for selection.

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

• get_asin_inventory_distributionA
  4.3/5.0
  Behavior4/5

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

  Annotations already include readOnlyHint=true, and the description adds context about the return payload (totalSellableUnits, distribution array with fields) and the `lastUpdatedAt` null condition. This goes beyond the annotation by explaining output semantics and edge cases, though it doesn't discuss pagination or rate limits, which are not relevant for a small read operation.

  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 a single, well-structured paragraph of moderate length. It front-loads the when-to-use trigger, then states requirements and output. Every sentence earns its place, with no redundant or vague phrasing.

  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 there is no output schema, the description explains the return structure (distribution array with fc, state, availableStock, availableStockPercentage) and the nullability of lastUpdatedAt. It also mentions prerequisites for sellerId, making the tool self-sufficient for a user to invoke correctly. This is complete for a simple read-only inventory distribution tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all three required parameters (asin, sellerId, marketplace) including patterns and enums. The description repeats the parameter names but adds no new meaning beyond what the schema already provides, so baseline 3 is appropriate.

  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 function with specific verb+resource: 'get inventory distribution' per ASIN. It explicitly distinguishes from siblings by focusing on inventory levels and fulfillment center stock, which no sibling covers. The trigger phrases ('asks about inventory levels, stock by fulfillment center') make 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 Guidelines4/5

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

  The description provides explicit when-to-use guidance: 'Use this when the user asks about inventory levels...' It also lists required input sources (sellerId from list_seller_profiles or Connections page). However, it doesn't mention when not to use this tool or suggest alternatives, so it misses the 'when-not/alternatives' element for a 5.

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

• get_niche_rootsA
  4.3/5.0
  Behavior4/5

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

  With readOnlyHint=true annotation already covering the safety profile, the description adds valuable behavioral context by detailing the output structure ('roots' and 'normalizedRoots' tables) and the meaning of each field (frequency, broadSearchVolume, broadSearchVolumeRatio). It also explains the extraction logic via an example, going beyond what annotations provide. No contradiction with annotations.

  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: first the usage triggers, then the operation, then the detailed output fields. The example is illustrative and every sentence provides necessary information without redundancy. It is appropriately sized 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?

  Since there is no output schema, the description takes responsibility for explaining return values. It thoroughly describes the tables (roots, normalizedRoots), each field (root, frequency, broadSearchVolume, broadSearchVolumeRatio), and additional metadata (per-keyword breakdowns, latestResearchDate). It also covers usage context, making it self-sufficient for an agent to select and invoke the tool correctly.

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

  Parameters3/5

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

  The schema already fully documents the only parameter nicheId (including the note 'from list_niches'), giving 100% schema coverage. The tool description does not add further semantic detail about the parameter itself, so the baseline score of 3 applies despite the description's broader context.

  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 'Retrieves the keyword lexical roots for the Niche' and provides a specific example ('bluetooth headphones' yields 'bluetooth', 'headphones', 'bluetooth headphones'). It distinguishes itself from sibling tools like get_niche_keywords by focusing on derived roots rather than raw keywords, and ties to user intent ('highest-impact words', 'prioritize terms').

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

  Usage Guidelines4/5

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

  The description opens with explicit 'Use this when...' and lists three concrete triggers: 'find the highest-impact words across a niche's keywords', 'asks about keyword roots', and 'wants to prioritize terms for a listing'. However, it does not specify when not to use the tool or mention alternative tools (e.g., get_niche_keywords), so it lacks the 'when-not' or alternatives detail needed for a 5.

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

• get_rank_radar_dataA
  4.3/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description discloses the return format ('Returns an array of tracked keywords; each has id, keyword, searchVolume, ranks (per-day { date, organicRank, impressionRank }), and any highlight annotations') and date format requirements. This adds meaningful context about what the operation does and what the user should expect, without exceeding annotation coverage.

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

  Conciseness5/5

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

  The description is well-structured and concise. Each sentence earns its place: purpose, parameter requirements, operational behavior, return structure, and usage sequencing. There is no redundancy or fluff, making it easy for an agent to parse.

  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?

  The description is complete given the tool's complexity. It covers what the tool does, the required parameters and their format, the return structure, and how to obtain the necessary ID. With readOnlyHint annotation and no output schema, this description provides enough context for an agent to invoke the tool correctly without ambiguity.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds marginal value by restating the date format and the need to obtain rankRadarId from list_rank_radars, but this information is already present in the schema. Therefore, baseline 3 is appropriate.

  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 function: 'Retrieves historical keyword ranking data for the specified Rank Radar within the date range.' The verb 'retrieves' is specific, and the resource ('keyword ranking data' for a Rank Radar) is well-defined. It also distinguishes from siblings like list_rank_radars and create_rank_radar by focusing on data retrieval rather than management.

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

  Usage Guidelines4/5

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

  The description provides clear usage context by stating 'Use after list_rank_radars to discover a rankRadarId,' which establishes a prerequisite and workflow. However, it does not explicitly mention when not to use this tool or alternative approaches, so it falls short of a 5.

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

• list_indexing_issue_alertsA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint: true, and the description adds meaningful behavioral context: default active status, 30-day window, filter semantics (e.g., updatedSince for incremental polling), and the fact that dismissed alerts are excluded. It doesn't cover rate limits or auth, but the read-only safety is already disclosed by annotations and the description reinforces safe usage.

  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 front-loaded with the primary use case and efficiently packs in scope, defaults, filters, return fields, and pagination metadata without fluff. Each sentence serves a purpose and adds concrete detail, making it well-structured for an agent.

  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 no output schema, the description compensates by explicitly listing the fields in each response and pagination metadata. It fully covers purpose, behavior, filter options, and result structure, making it self-sufficient for an agent to select and invoke correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, with detailed descriptions for every parameter. The description adds value by explaining defaults (active, 30 days) and the incremental polling use case for updatedSince, but the schema already carries most parameter meaning. This matches the baseline for full schema coverage.

  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 identifies the resource ('indexing-issue alerts') and the action ('Retrieves a paginated list'), and explains what an alert represents (ASIN no longer indexed for tracked keywords). It distinguishes this tool from siblings like list_blind_spend_alerts by specifying the issue type.

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

  Usage Guidelines4/5

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

  The opening 'Use this to find products that may have lost search visibility' gives clear when-to-use guidance. It also explains default behavior (active alerts, last 30 days) and how to filter or paginate, but does not explicitly state when not to use it or name alternative tools for other alert types.

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

• list_nichesA
  4.3/5.0
  Behavior4/5

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

  Annotations already include readOnlyHint=true, and the description adds valuable context beyond that: what a Niche represents, the return fields (nicheId, heroKeyword, etc.), and pagination metadata. This helps the agent understand the tool's output and behavior without contradicting the read-only hint.

  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?

  Three sentences, front-loaded with usage guidance, then a clear statement of purpose, followed by return details. Every sentence contributes value with no fluff or repetition.

  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 simple read-only list tool, the description covers purpose, usage, return values, and pagination semantics. The schema covers parameters, and annotations cover safety. No significant gaps remain, especially given no output schema is present.

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

  Parameters3/5

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

  Schema description coverage is 100% for both parameters (pageSize and currentPage), so the schema fully documents them. The description mentions pagination generically but does not add syntax or format details beyond what the schema already provides. Baseline 3 is appropriate.

  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 retrieves a paginated list of Niches, which is a specific verb+resource, and distinguishes from sibling tools by explaining it's the entry point for finding nicheId used by get_niche_keywords, get_niche_competitors, and get_ranking_juice.

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

  Usage Guidelines4/5

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

  Explicitly says 'Use this first when the user asks about their niches, or to find a nicheId for use with...' which provides clear when-to-use context. It names related tools that consume the nicheId, but does not explicitly state when-not-to-use or provide an alternative for listing niches (e.g., get_niche_roots).

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

• get_quotaA
  4.5/5.0
  Behavior4/5

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

  Annotations already mark the tool as readOnlyHint=true, and the description adds meaningful context beyond that: it details the return structure (used/capacity per feature, null for unlimited, nextRefreshDate) and confirms the tool returns data without side effects. This is useful behavioral disclosure for an agent.

  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 a single, well-structured sentence. It front-loads the usage trigger before explaining the response format. Every clause adds value—feature names, null semantics, and the ISO timestamp—without redundancy. No filler or unnecessary words.

  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 simple read-only tool with no parameters and no output schema, the description is complete: it explains exactly what the tool returns, including the specific fields and their possible null values. It gives the agent everything needed to invoke and interpret the result.

  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?

  There are zero parameters and the schema is empty. The description explicitly states 'Takes no arguments,' which confirms the parameterless nature and matches the schema exactly. For a no-parameter tool, the baseline is 4, and the description fulfills this.

  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 uses the specific verb 'get' with resource 'quota usage and capacity' and enumerates the exact billable features (DIVED_ASINS, RANK_RADAR_KEYWORDS, etc.). This clearly distinguishes it from all sibling tools, none of which mention quota.

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

  Usage Guidelines4/5

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

  It provides explicit usage triggers: 'when the user asks how much quota or how many tokens they have left' and 'before creating a Niche Dive or Rank Radar to check remaining headroom.' This is clear context for when to use, though it does not mention alternatives or exclusions.

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

• get_ranking_juiceA
  4.5/5.0
  Behavior4/5

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

  The readOnlyHint annotation already establishes safety, and the description adds substantial context by detailing the return structure: currentListing/optimizedListing breakdowns, per-property contributions, per-competitor scores, and latestResearchDate. It explains the proprietary 'Ranking Juice' concept, which is valuable beyond the annotation.

  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 composed of two efficiently structured sentences, with the usage guidance front-loaded. Every sentence contributes unique information—trigger conditions, resource, return details, and metric definition—without redundancy or fluff.

  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 fully explains what the tool returns, including the nested breakdowns and research date. It also provides sufficient context for an agent to understand when to invoke it, making the description complete for a single-parameter read-only tool.

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

  Parameters3/5

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

  Schema coverage is 100% for the single parameter nicheId, and the schema already describes it as a unique identifier from list_niches. The description adds no further parameter-specific meaning, so the baseline 3 applies.

  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 a specific verb ('Retrieves') plus resource ('Ranking Juices for each Competitor within the specified Niche') and defines the proprietary metric. It also provides user-intent triggers ('how do I rank higher', 'what's my ranking juice') that distinguish this from sibling tools like get_niche_keywords or get_niche_competitors.

  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 first sentence explicitly directs when to use the tool: 'Use this when the user asks... or wants listing-optimization guidance.' This gives clear context for selection without ambiguity, even though it doesn't name alternative tools directly.

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

• get_seller_catalogA
  4.5/5.0
  Behavior4/5

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

  The readOnlyHint annotation already indicates a safe read operation. The description adds valuable context: it describes the return fields (asin, title, parentAsin, brand, status, imageUrl, hasVariations), pagination metadata, and default behaviors for status, pageSize, and currentPage. This goes beyond the annotation and helps set expectations.

  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 concise yet information-dense. It front-loads the primary use case, then lists required and optional parameters in a structured way, and ends with the return format. 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?

  Despite having no output schema, the description compensates by listing the exact fields returned and pagination metadata. It covers prerequisites, filters, defaults, and return structure. For a read-only list tool with 7 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?

  All 7 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds extra semantic value by clarifying defaults (status defaults to Active, pageSize defaults to 20, currentPage defaults to 1), which are not fully captured by the schema. It also reiterates the case-insensitive behavior, but that is already in the 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 clearly states the tool's purpose: to browse or search a seller's own Amazon catalog on a given marketplace. It uses specific verbs ('browse', 'search'), names the resource ('seller's own Amazon catalog'), and lists key filters, distinguishing it from related tools like get_seller_listing_changes.

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

  Usage Guidelines4/5

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

  The description explicitly says when to use this tool ('when the user wants to browse or search a seller's own Amazon catalog') and provides prerequisites (sellerId + marketplace, discovered via list_seller_profiles). It does not explicitly state when not to use alternatives, but the context is clear enough for a 4.

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

• get_seller_listing_changesA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds useful behavioral context beyond the annotation by explaining the paginated response shape, the per-item fields, and how includeCorrelations: true attaches ranking/conversion impact.

  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 a single dense paragraph that front-loads the use case, then systematically covers prerequisites, filtering/sorting options, the optional correlation flag, and the exact return fields. Every sentence adds operational value without restating the schema verbatim.

  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 13 parameters, no output schema, and only a readOnlyHint annotation, this description carries the full burden of explaining invocation. It covers required args, filter/sort semantics, output fields, pagination metadata, and the conditional correlation object, making it sufficiently complete for an agent to select and call 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?

  Schema coverage is 100% with descriptions on every parameter, so the baseline is 3. The description adds value by grouping parameters into filters, sorting, and correlation, and by linking sellerId to the discovery tool list_seller_profiles. It also explains the output structure, which helps when selecting includeCorrelations.

  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 'Use this when the user asks what changed on their Amazon listings — price, content, or image edits', which clearly identifies the action (list changes) and the resource (seller listing changes). It also distinguishes the tool from sibling tools like get_seller_catalog and list_seller_profiles by focusing on changes over time.

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

  Usage Guidelines4/5

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

  It explicitly states when to use the tool ('when the user asks what changed on their Amazon listings') and gives concrete prerequisites: requires sellerId + marketplace and points to list_seller_profiles for discovery. It does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5.

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

• list_blind_spend_alertsA
  4.5/5.0
  Behavior5/5

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

  The readOnlyHint annotation already indicates safety. The description adds substantial behavioral detail: pagination, default filters, list of returned fields including nested searchTerms, and the fact that dismissed alerts are excluded. No contradiction with annotations.

  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 a single, information-dense paragraph that front-loads the main purpose and then systematically covers output fields and pagination. No redundant sentences.

  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 (six optional filters, pagination, deeply nested item structure) and the absence of an output schema, the description provides a complete inventory of the response shape and behavior. Everything an agent needs to know is included.

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

  Parameters3/5

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

  Schema descriptions cover all six parameters, and the description merely restates filter names and updatedSince's purpose already in the schema. It adds marginal context beyond the schema, so a baseline 3 is appropriate.

  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 direct use case ('find wasted PPC ad spend') and clearly identifies the resource (blind-spend alerts) and scope (across connected Amazon seller accounts). It distinguishes itself from sibling tools like list_rank_radars or get_niche_* by focusing on wasted-spend alerts.

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

  Usage Guidelines4/5

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

  States when to use ('find wasted PPC ad spend'), explains default behavior (active alerts, last 30 days), and specifically calls out updatedSince for incremental polling. It doesn't explicitly compare to alternative tools, but the use case is clear enough.

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

• list_seller_profilesA
  4.5/5.0
  Behavior4/5

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

  The readOnlyHint annotation already indicates a safe read operation. The description adds valuable behavioral context by detailing the response structure: each profile's fields (sellerId, sellerName, marketplace, hasAdApi, createdAt) and pagination metadata (currentPage, pageSize, total, lastPage, hasNext, hasPrev). No contradictions with annotations.

  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 two sentences, front-loaded with usage guidance, and the second sentence enumerates the response structure without excessive detail. Every sentence earns its place, and the formatting makes it 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 fully explains both the list contents and pagination metadata. It also covers the tool's purpose, usage timing, and relationship to sibling tools, making it self-sufficient for an agent to select and invoke correctly.

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

  Parameters3/5

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

  Input schema covers 100% of parameters with clear descriptions, so the baseline is 3. The description mentions pagination metadata but does not add new meaning to the parameters themselves. It reinforces that pageSize and currentPage control paging, which the schema already explains.

  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 uses a specific verb ('list') and explicitly identifies the resource ('connected seller profiles') with scope ('the organization's'). It also distinguishes itself from sibling tools by positioning it as the discovery step for sellerId/marketplace needed by other tools, making its unique purpose clear.

  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?

  Description states exactly when to use it: when the user asks which Amazon seller accounts are connected, or as a discovery step. It also names specific dependent tools that require its output, giving strong contextual guidance on when this tool is the right choice.

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

• create_niche_diveA
  4.6/5.0
  Behavior5/5

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

  The description discloses multiple non-obvious behaviors: token spending with cost scaling, irreversibility, asynchronous execution with immediate return of diveId and estimatedCompletionDate, and the need to poll get_dive_status for the final nicheId. This significantly exceeds the annotations (readOnlyHint=false, destructiveHint=true) by adding depth and actionable details.

  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 but purposeful, with each sentence carrying critical information: usage, cost/reversibility warning, async behavior, polling flow, and required fields. The warning emoji and sentence structure make it scannable. Some redundancy exists (min 2 appears in the schema and description), but overall it is efficient and well-organized.

  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?

  The tool is complex: asynchronous, destructive, costly, and without an output schema. The description covers the immediate response (diveId, estimatedCompletionDate), the polling requirement, the content of the success response (nicheId), and downstream use. It also explicitly states required parameters and the minimum for numberOfCompetitors. This is comprehensive for the tool's complexity.

  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 input schema already provides 100% coverage of all four parameters, so the baseline is 3. The description adds meaningful cross-parameter context: it links numberOfCompetitors to token cost, explains that confirm must be true after user approval, and clarifies that marketplace, asin, and numberOfCompetitors are required. This goes beyond individual property 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 opens with 'Use this to start new niche research from a seed ASIN,' which clearly identifies the action (start), the resource (niche research), and the input (seed ASIN). This distinguishes it from sibling tools like list_niches or get_niche_keywords, which are retrieval operations, and create_rank_radar, which is a different creation action.

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

  Usage Guidelines4/5

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

  The description provides strong contextual guidance: it explains when to use the tool (starting niche research), the confirmation requirement before spending tokens, and the follow-up workflow (poll get_dive_status, then use nicheId with other tools). However, it does not explicitly state when not to use it or name alternatives as exclusions, so it falls just short of a 5.

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

• create_rank_radarA
  4.6/5.0
  Behavior5/5

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

  Beyond the annotations (destructiveHint=true), the description adds critical behavioral details: it 'Spends Search Term tokens' with cost scaling by `numberOfKeywords`, 'cannot be undone', requires `confirm: true` after user approval, and returns a `rankRadarId`. This goes well beyond the annotations and fully discloses the side effects and prerequisites.

  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 three sentences, each earning its place: purpose, cost/warning, and return/requirements. The use of ⚠️ draws attention to the destructive aspect, and the structure is front-loaded with purpose before details. No wasted words.

  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?

  With 4 parameters, 100% schema coverage, and annotations present, the description adequately covers the return value (`rankRadarId`), prerequisites, cost, and confirmation flow. It could mention potential errors or how tracking progresses over time, but for a create action with this complexity, it is sufficiently 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 baseline is 3. The description adds meaning by linking `numberOfKeywords` to token cost scaling, noting `nicheId` comes from `list_niches`, and emphasizing `confirm: true` after cost approval. These enrich the schema's basic descriptions, providing extra context for decision-making.

  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 function: 'start tracking organic and sponsored keyword rankings for an ASIN within a niche.' It uses a specific verb ('start tracking') and identifies the resource (keyword rankings for an ASIN/niche), effectively distinguishing it from sibling tools like `get_rank_radar_data` (read later) and `create_niche_dive` (different kind of creation).

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use: when you need to begin keyword tracking for an ASIN in a niche. It also warns about token costs, requires user approval via `confirm`, and points to `get_rank_radar_data` for reading data later, which serves as a related alternative. However, it does not explicitly mention when not to use or compare with sibling creation tools like `create_niche_dive`, so it falls slightly short of full guidance.

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

• list_usageA
  4.6/5.0
  Behavior5/5

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

  With readOnlyHint=true already set, the description still adds substantial behavioral context: pagination behavior, the nature of each entry (token-consumption event), and the exact fields included. It goes beyond annotations by describing response structure and metadata, giving agents full transparency on what to expect.

  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 a single dense paragraph but every sentence contributes value: usage triggers, what is returned, filtering options, and response fields. It is longer than minimal but appropriately so for a complex list tool; no filler or repetition.

  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, the description fully explains what the caller will receive, including pagination metadata and per-item fields. It also clarifies that it's organization-wide, filters by type/search/date, and returns token-consumption events—complete coverage for a 6-parameter read-only list 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% with detailed per-parameter descriptions. The tool description reinforces how filters map to user needs (e.g., filtering by type, search, and date range) and adds meaningful context about pagination defaults and page size caps, complementing rather than repeating the 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 opens with explicit user intents ('who consumed tokens, how their quota was spent, or wants an audit') and names the exact resource ('billable feature usage logs'). It clearly distinguishes from sibling tools like list_niches or get_quota by focusing on token-consumption events.

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

  Usage Guidelines4/5

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

  Provides strong when-to-use guidance ('Use this when...') and lists supported filters. It does not explicitly mention when not to use it or name alternatives, but the context makes it clear this is for audit/quota questions, distinguishing it from read-only tools like get_quota.

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

• get_dive_statusA
  4.7/5.0
  Behavior5/5

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

  The description discloses the three possible return shapes (`in_progress`, `success`, `error`) and their fields, which is essential since there is no output schema. It also mentions that dives can take minutes, adding temporal behavior beyond the `readOnlyHint` annotation, which it does not contradict.

  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, front-loaded with the primary use, and every sentence adds value. It efficiently explains the statuses, fields, and follow-up actions without unnecessary verbiage.

  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, the description fully explains the return shapes and their fields, and also covers the polling behavior and follow-up usage of `nicheId`. It is complete for a polling tool of this complexity.

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

  Parameters3/5

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

  The schema already provides full description for `diveId` with 100% coverage. The tool description does not add further semantic detail about the parameter itself, so the baseline of 3 applies. The reference to `create_niche_dive` matches the schema but adds no new information.

  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: to poll a niche dive until it finishes. The verb 'poll' plus the resource 'niche dive' are specific, and it distinguishes from sibling tools by explaining that the result is a status update with a `nicheId` to be used with other listing/niche 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?

  It explicitly says 'Use this to poll a niche dive started with `create_niche_dive` until it finishes', setting clear context and the relationship to the creating tool. It also advises periodic re-polling and mentions that `estimatedCompletionDate` hints when to check, providing actionable usage guidance.

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