Server Quality Checklist

Tool Scores

• asin_compareB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the comparison behavior but does not disclose any details such as data sources, side effects, return format, or whether the tool is read-only. This is a significant gap for a tool with no annotation support.

  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 the purpose, and the usage guideline is a separate call-out. Every word contributes, and there is no waste.

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

  Completeness2/5

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

  The tool has 4 parameters and no output schema, but the description does not explain the optional parameters or indicate the shape of the comparison result. The nine dimensions are not enumerated, making the description inadequate for the tool's complexity.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain any parameters. It neither clarifies the meaning of asin_a and asin_b beyond the obvious, nor explains the optional traffic_pages and scoring_version parameters. This provides no value beyond the schema's type/default 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 performs a side-by-side nine-dimension comparison of two ASINs. The verb 'comparison' and resource 'two ASINs' are specific, distinguishing it from sibling tools like asin_score which likely evaluate individual ASINs.

  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 an explicit usage scenario: 'Deciding between two competitor products to benchmark against.' This gives clear context for use, but it does not mention when not to use it or suggest alternatives, stopping short of a top score.

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

• session_statusA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. The phrase 'show' implies read-only, but it does not explicitly state whether this is a safe read-only operation, whether it requires authentication, or what the response structure looks like. This is a significant gap for a tool with no 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 only two concise sentences. The first sentence states the tool's purpose, and the second provides usage guidance. Every word earns its place, with no redundancy or filler.

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

  Completeness3/5

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

  Given the tool's simplicity (0 params, no output schema, no annotations), the description is minimally adequate but leaves gaps. It does not explain what the returned cache status or API configuration will look like, and with no output schema, this information would be valuable for the agent. The usage context helps, but behavioral details are missing.

  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 tool has zero parameters, and the schema coverage is 100% (empty). The baseline for 0 params is 4, and the description correctly says nothing about parameters since there are none. No additional parameter context is needed.

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

  Purpose4/5

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

  The description clearly states the tool shows current session state (cache status and API configuration). The verb 'show' is specific, and the resource is defined. It distinguishes from sibling cache_status by including API configuration, though it does not explicitly name alternatives.

  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 usage context: 'USE THIS TOOL WHEN: Starting a session or checking configuration.' This tells the agent when to invoke it, though it does not mention exclusions or alternatives beyond that context.

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

• asin_reverse_trafficA
  3.7/5.0
  Behavior3/5

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

  The description indicates the tool performs a reverse lookup and cache coverage check, implying a read-only operation. However, with no annotations, it does not fully disclose whether the operation makes external calls, how the cache is checked, or any side effects. It gives some behavior but not complete transparency.

  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 short sentences with no filler. It front-loads the core purpose in the first sentence and then gives a clear usage trigger. Every word earns its place.

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

  Completeness2/5

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

  Given the lack of output schema, annotations, and an unexplained second parameter, the description leaves significant gaps. It does not state what the tool returns (e.g., list of keywords, coverage percentage) or explain max_pages, making it incomplete for an agent to use confidently.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It references the ASIN parameter implicitly by saying 'for an ASIN,' but provides no explanation for 'max_pages.' The description adds minimal meaning beyond the schema and leaves one parameter entirely unexplained.

  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 action: 'Reverse-lookup traffic keywords for an ASIN' and adds the secondary purpose 'check cache coverage.' This distinguishes it from siblings like asin_score or keyword_analyze, which operate in the opposite direction or on different resources.

  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 an explicit usage trigger: 'USE THIS TOOL WHEN: Checking if an existing product's keywords are covered by the ABA cache.' This gives clear context for when to use the tool, though it does not mention when not to use it or name alternative tools.

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

• keyword_analyzeA
  3.7/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden. It mentions what the analysis returns but does not disclose side effects, auth requirements, rate limits, or whether it operates on cached data. This is insufficient for a tool with no structured safety metadata.

  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, each earning its place: the first explains functionality, the second gives the trigger scenario.

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

  Completeness3/5

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

  Given the tool's simplicity (one parameter, no output schema), the description covers purpose and use case. However, it omits details about the output structure, any dependencies on cached data, and whether it's a synchronous call, which matters in this tool family.

  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 only names the 'keyword' parameter with no description. The tool description adds 'single-keyword' to clarify the expected input type, but does not provide examples, formatting rules, or constraints.

  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 'Deep single-keyword analysis' and lists the outputs (market metrics, top competitors, seasonality). This distinguishes it from siblings like market_screen or asin_score by focusing on a single keyword.

  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 an explicit use case: 'Evaluating a specific keyword before committing to a product line.' This gives clear context, though it doesn't 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.

• asin_score_batchA
  3.8/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the transparency burden. It discloses that the tool 'Uses concurrent API calls' and specifies concurrency limits, but lacks details on side effects, error handling, or output structure, leaving gaps.

  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 compact, front-loaded with purpose, and every sentence contributes. The Args section is clearly formatted, and the usage note is direct.

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

  Completeness2/5

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

  With no output schema and no annotations, the description should explain return values and remaining parameters. It only partially covers this, omitting traffic_pages and scoring_version, and doesn't describe what the response looks like beyond ranking.

  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 description adds meaning for asins_json (format and source), limit (max count), and concurrency (range 1-10), but omits traffic_pages and scoring_version entirely, which is a notable gap given 0% 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 states 'Score multiple ASINs and rank by total score' with a specific verb and resource. It distinguishes from the sibling 'asin_score' by highlighting batch processing and referencing 'asin_discover'.

  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 explicit usage guidance in the 'USE THIS TOOL WHEN' section, specifically 'Scoring all ASINs discovered by asin_discover.' This gives clear context, though it doesn't mention alternatives or exclusions, so it earns a 4.

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

• cache_term_distributionA
  3.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. It implies a read-only operation via 'Show' and mentions 'cached ABA pages', but does not explicitly state that it is read-only, what the output looks like, or whether a cache must exist beforehand. This is insufficient for a tool with no annotation support.

  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 extremely concise and well-structured: a one-sentence purpose, a clear parameter explanation, and a usage callout. Every sentence earns its place, and there is no redundnone.

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

  Completeness3/5

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

  The tool has no output schema and no annotations, so the description should explain what 'distribution' means and what the expected return value is. It states the purpose and when to use it, but omits details about output format or prerequisites, leaving a noticeable gap for a simple but still underspecified 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?

  The schema has only a bare 'term' string parameter with no description, so the tool description's 'A category word like 'christmas', 'bulk', 'wedding'' adds meaningful examples and clarifies the expected input. It compensates well for the 0% schema description 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 states the tool's function with a specific verb ('Show') and resource ('cached ABA pages'), and explains the scope ('how a product term distributes'). This distinguishes it from sibling tools like cache_aba_pull or cache_status.

  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 an explicit 'USE THIS TOOL WHEN' condition: 'Deciding which ABA page ranges to pull for a specific category.' It gives clear context for when to use it but does not name alternatives or explicitly say when not to use it.

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

• pipeline_validateA
  3.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full responsibility for behavioral transparency. It does not disclose whether the tool is read-only, what it returns (e.g., a score, pass/fail, or report), any side effects, or prerequisites. 'Validate' implies analysis but provides no detail on the operation's behavior.

  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 and well-structured: a clear one-line purpose, a parameter example, and a usage directive. No unnecessary words or repetition.

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

  Completeness3/5

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

  The tool is simple (one parameter, no output schema), but the description omits the return value or output format, which is essential for a validation tool. It covers input and usage context adequately but leaves the outcome ambiguous, making it minimally 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?

  The description adds meaningful format guidance for the single parameter with a concrete JSON array example ('["B0XXX","B0YYY",...]'). This goes beyond the schema's bare string type, helping the agent construct valid input.

  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 a specific verb ('Validate') and object ('pipeline recall') against a list of known-good ASINs. This distinguishes it from sibling tools like cache_query or asin_score, which serve different purposes.

  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 an explicit 'USE THIS TOOL WHEN' clause indicating the intended use case: measuring how well the cache and pipeline cover existing products. It gives clear context for when to use it, though it does not explicitly 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.

• asin_discoverA
  4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden for behavioral disclosure, but it does not state whether the operation is read-only, whether it has side effects (e.g., caching, rate limits), or what happens on failure. Mentions of 'override sweetspot' hint at internal logic but do not provide meaningful transparency.

  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 paragraphs plus a brief arg list. Every sentence is purposeful: it states the core action, parameter semantics, and a clear usage cue. No fluff or repetition.

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

  Completeness3/5

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

  The description gives solid parameter details and usage guidance, but it does not explain the return value or output format, which matters given there is no output schema. It also omits edge cases (e.g., empty markets list, invalid JSON). Adequate but with clear gaps.

  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 description explains every parameter beyond the schema: markets_json source and tier shortcuts, price overrides, reviews_max default (150), and fba_only behavior. Since schema coverage is 0%, this fully compensates and adds genuine meaning.

  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 states a specific verb ('discover') and resource ('ASINs') within candidate markets, clearly distinguishing it from siblings like asin_score or market_screen. The 'USE THIS TOOL WHEN' line reinforces its role in finding specific ASINs in validated markets.

  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 an explicit 'when to use' statement: 'Finding specific ASINs in validated markets.' It also implies a prerequisite (market_screen) but does not mention when not to use it or name alternative tools. This is clear context without exclusions.

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

• market_screenA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It discloses 'Uses caching + concurrent API calls + smart skip for speed', which is useful behavioral detail, but it does not state whether the tool is read-only, describe failure handling, or mention side effects like cache writes. Incomplete but non-trivial transparency.

  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 compact and well-structured: a one-sentence action, an Args list with clear explanations, and a usage statement. Every line earns its place; no redundant or filler content.

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

  Completeness3/5

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

  Covers purpose, when-to-use, all parameters, and some behavioral details. However, with no output schema, it omits return format and expected output shape. It also does not describe prerequisites (e.g., pool_build must be run first) or error handling, leaving moderate gaps for a tool of this 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?

  Schema description coverage is 0%, but the Args section explains all four parameters with meaningful semantics: pool_keywords accepts 'cached_top', limit and min_search_volume define limits, and concurrency has an explicit 1-10 range. This fully compensates for the schema gap, though it could mention defaults (already in 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 'Run keyword_detail on top pool keywords for market screening', identifying a specific action and resource. It distinguishes from siblings like keyword_analyze and pool_build, and the 'USE THIS TOOL WHEN' line clarifies the purpose of evaluating new-seller opportunity.

  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 explicit 'USE THIS TOOL WHEN: Evaluating which markets have best new-seller opportunity', which is clear context. However, it does not mention when not to use it or explicitly name alternative tools, so it lacks exclusions.

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

• asin_scoreA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It reveals return fields (total score, tier, dimension breakdown, data completeness, score confidence), supported scoring versions with defaults, and the effect of include_detail. This goes beyond the schema and gives useful context.

  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 concise and front-loaded. The first sentence states purpose, subsequent sentences add return values, version options, and a clear usage directive. No word is wasted.

  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?

  Given no output schema, the description does a thorough job of explaining return values, version options, and detail flag behavior. It does not mention batch alternatives or error handling, but for a single-ASIN scoring operation it is largely 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?

  Schema description coverage is 0%, so the description must compensate. It explains include_detail and scoring_version meaningfully, but traffic_pages is left completely unexplained and ASIN format is not clarified. This is only partial compensation for 4 parameters.

  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 'Score a single ASIN on nine dimensions' and 'Evaluating a specific ASIN's viability', giving a specific verb and resource. The word 'single' distinguishes it from the sibling asin_score_batch, 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 Guidelines4/5

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

  It explicitly says 'USE THIS TOOL WHEN: Evaluating a specific ASIN's viability', which is clear context for when to use. However, it does not provide explicit exclusions or alternative tool recommendations, though the sibling list implies batch vs single.

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

• cache_clearA
  4.2/5.0
  Behavior3/5

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

  No annotations exist, so the description must convey behavioral traits. It clarifies that the action is to clear keywords and that page ranges are optional, but it doesn't mention side effects like whether the operation is reversible or affects only the keyword cache. 'Clear' implies deletion, but further details on impact or return value would improve transparency.

  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 and a usage note, with no filler. Each sentence adds distinct value: purpose, parameter behavior, and use case. It is front-loaded with the core action and remains succinct.

  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?

  Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description covers purpose, usage, and parameter semantics well. It lacks explicit return value information, but for a cache-clear operation this is not critical. It adequately distinguishes from sibling cache tools and provides sufficient context for most use cases.

  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 provides only the parameter name 'pages' with a type and default, but no description. The description compensates by explaining the format ('1-500') and the conditional behavior (clears only those pages when specified). It does not explicitly state what happens when pages is empty, but the conditional phrasing implies clearing all, which is a minor gap.

  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 'Clear cached keywords' with a specific verb and resource, distinguishing it from sibling tools like cache_status and cache_query. It also adds nuance by explaining the optional page range behavior.

  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 includes an explicit 'USE THIS TOOL WHEN' section stating to use it when refreshing stale cache or freeing space. It doesn't mention when not to use it or alternative tools, but the context is clear enough for straightforward selection.

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

• cache_queryA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. The verb 'Query' and phrase 'Exploring what's in the cache' imply a read-only operation, but the description does not explicitly state that it is non-destructive, does not modify data, or has any side effects. It adds some context about cached data but lacks explicit safety or behavioral details.

  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 and well-structured: a one-sentence summary, a compact args list, and a clear usage note. Every sentence earns its place with no fluff, and important information is front-loaded.

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

  Completeness3/5

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

  The description covers purpose, parameters, and usage, but it omits any description of the return value or output format. Since there is no output schema, the description should clarify what the query returns (e.g., a list of matching keywords and volumes). It also lacks any mention of edge cases like empty cache or behavior when no filters are provided.

  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 'Args' section provides meaningful explanations for all three parameters, going well beyond the schema's bare titles and defaults. It clarifies 'categories' with an example ('bulk,gift,wedding'), 'min_search_volume' as a 30-day metric, and 'limit' as max results, fully compensating for the 0% schema description 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 states the tool's function with a specific verb and resource: 'Query cached keywords by category and min search volume.' This distinguishes it from sibling tools like cache_status (status checks) and cache_clear (clearing cache), 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 Guidelines4/5

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

  The description provides a clear usage scenario: 'USE THIS TOOL WHEN: Exploring what's in the cache for specific product lines.' While it gives good context, it does not explicitly exclude alternatives or mention when not to use it, so it earns a 4 rather than a 5.

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

• cache_statusA
  4.2/5.0
  Behavior3/5

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

  No annotations are supplied, so the description carries the full burden of behavioral disclosure. The verb 'Show' implies a read-only status check with no side effects, but this is not explicitly stated. For a simple status tool this is adequate, but it could be improved by noting that it performs no mutations.

  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 only two sentences. The first defines the tool, the second gives usage guidance. There is no redundant information or fluff, and the key details are front-loaded in the first sentence.

  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?

  Given the tool's simplicity (zero parameters, no output schema), the description covers the essential information about what the cache status shows and when to use it. It lists the specific data points (page coverage, total keywords, category breakdown), which is sufficient for a status-check tool. It could benefit from specifying the output format, but that is not critical here.

  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 tool takes zero parameters, so the description cannot add parameter meaning. Per the baseline for parameterless tools, a score of 4 is appropriate; there is no schema or parameter info to clarify beyond what the description already conveys.

  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: 'Show current ABA cache state' and specifies the exact content (page coverage, total keywords, category breakdown). This is a specific verb+resource construction that distinguishes it from sibling cache operation tools like cache_aba_pull and cache_clear, which perform actions rather than report status.

  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 'USE THIS TOOL WHEN' directive provides a clear context: checking if cache covers the page ranges needed for research. This offers actionable guidance, though it does not mention when not to use it or suggest alternative tools. The usage context is clear but not exhaustive.

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

• supplier_compare_prepareA
  4.2/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 and does well: it discloses deterministic behavior, applies hard mismatch gates, records structured evidence, and limits output to 5 best non-rejected candidates. It stops short of explaining side effects like whether 'records structured evidence' implies persistent storage or whether any state is modified.

  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: overall purpose, behavior details, argument explanation, and a usage directive. Every sentence adds value and there is no redundant or filler content.

  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 single-parameter tool with no output schema, the description covers the essential context: what it does, its deterministic nature, its output (VisualReviewBundle), and when to use it. It does not explain what 'hard mismatch gates' entail, but this is not required for basic invocation.

  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 0%, so the description must compensate. The only parameter 'asin' is described as 'Amazon ASIN to compare against supplier candidates', which adds minimal context beyond the schema's field title. For an obvious single-string ASIN, this is adequate but not detailed; no format or examples are given.

  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 action: run deterministic comparison between an Amazon product and 1688 candidates. It also mentions the output (VisualReviewBundle) and distinguishes itself from other tools by explicitly noting no LLM/vision APIs are called, which differentiates it from sibling tools like asin_compare.

  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 usage context: 'USE THIS TOOL WHEN: After supplier_search returns candidates to evaluate.' This gives a clear workflow position but does not mention when NOT to use it or alternative tools, which would have made it a 5.

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

• cache_aba_pullA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It usefully mentions that subsequent calls skip duplicates, implying idempotency, but it does not disclose side effects, authorization needs, or whether existing cache is overwritten. This leaves some gaps.

  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 and front-loaded: purpose, parameter syntax, usage context, and a key behavioral guarantee are covered in just a few sentences. Every sentence adds value with no 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 simple one-parameter tool with no output schema and no annotations, the description covers purpose, parameter format, when to use, and a key behavioral note. It does not describe return values or error cases, but those are not critical for this level of complexity.

  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 has zero description for 'pages', but the tool description fully compensates by specifying the range format with examples ('1-500', '750-2500') and a default. This provides complete, actionable semantics for the single parameter.

  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 verb 'Pull and cache' and the resource 'ABA keyword_list pages', with a specific scope ('pages' range). This distinguishes it from sibling cache_* tools by indicating it is the ingestion/population tool, not querying, status, or clearing.

  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 gives an explicit 'USE THIS TOOL WHEN' condition (building local keyword cache for offline analysis) and advises to run once per page range. It lacks explicit when-not or alternative naming, but the context among siblings is clear enough.

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

• asin_fingerprintA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It discloses the extraction scope, provenance tracking, and the reporting of critical unknowns that block downstream matching. However, it leaves side effects (e.g., caching, writes) unspecified.

  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?

  Purpose is front-loaded in the first sentence, followed by a compact extraction list and a clear usage trigger. No redundant text; every sentence earns its place.

  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 what it does, what it consumes, when to invoke it, and what blockers it reports. Lacks an explicit return structure, but the extracted-field list and 'reports critical unknowns' provide sufficient expectations for an agent.

  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 has no parameter descriptions (0% coverage), but the Args section adds meaningful constraints: ASIN's 10-character alphanumeric format and marketplace default value. This compensates for the schema gap, though marketplace allowed values are not detailed.

  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 builds a normalized product fingerprint from an ASIN's product_detail, enumerating the specific extracted fields and tying it to the 1688 supplier matching workflow. The verb 'Build' and the output concept 'fingerprint' distinguish it from scoring or analysis sibling tools.

  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 an explicit trigger condition: 'Starting the 1688 supplier matching workflow for an ASIN.' It gives clear context for when to use the tool but does not mention when not to use it or name alternative tools for other workflow stages.

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

• pool_buildA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the key trait of making no API calls and operating purely on cached ABA data. It also implies the dependency on cache_aba_pull. It doesn't mention side effects like overwriting existing pools or error handling, but the core behavior is 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?

  The description is extremely concise and well-structured. The core action is stated in one sentence, followed by a clear parameter list and a usage note. Every line adds value, with no redundant or vague filler.

  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?

  Given the tool's simplicity (3 optional params, no output schema), the description covers the essential aspects: purpose, parameters, and usage prerequisite. It lacks explicit mention of the return value or how the pool is stored, but this is a minor gap. Overall, it is sufficiently complete for an experienced agent.

  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 schema has zero descriptions, so the description fully compensates by explaining each parameter: 'categories' as comma-separated filter terms with default examples, 'min_search_volume' as minimum 30d search volume, and 'limit' as max pool size. This adds precisely the meaning missing from 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 'Build a keyword pool from cached ABA data', which is a specific verb+resource statement that clearly distinguishes it from sibling tools like cache_aba_pull (which pulls data) and cache_query (which queries cache). Additionally, 'No API calls' further differentiates its behavior.

  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 'USE THIS TOOL WHEN: Starting a new research session. Must have cache_aba_pull run first.' This provides a clear use case and a prerequisite. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of the highest bar.

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

• supplier_searchA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It clearly discloses the behavioral approach: running both image and Chinese keyword searches, deduplicating, and normalizing into SupplierCandidate objects. It omits potential rate limits or network dependency details, but 'Search 1688.com' plus the read-only nature of the task make the behavior reasonably 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?

  The description is well-structured with a front-loaded purpose sentence, two concise behavioral sentences, an Args section, and a clear usage note. Every sentence contributes meaningful information without repetition or padding.

  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?

  Given the simple two-parameter schema and no output schema, the description covers the process, parameters, and usage context well. It names the return type (SupplierCandidate objects) but does not detail those object fields, which would be useful given the missing output schema. Still, it is sufficiently complete for an agent to select and invoke the 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?

  The schema has no descriptions (0% coverage), but the description fully compensates: 'asin: Amazon ASIN used for image search and fingerprint extraction' and 'search_keyword: Optional Chinese keyword override for text search.' This adds clear semantic meaning that the structured schema lacks.

  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: 'Search 1688.com for supplier candidates matching an ASIN.' It further clarifies the dual-mode search (image and Chinese keyword) and normalization into SupplierCandidate objects, distinguishing it from siblings like asin_fingerprint or supplier_compare_prepare.

  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 'USE THIS TOOL WHEN: After building a fingerprint with asin_fingerprint.' This gives clear when-to-use guidance. It does not mention when not to use or name alternatives, but the context is unambiguous.

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

• fba_profitA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses the inclusion of 2026 hidden fees, parameter defaults (including conservative organic traffic), and the full set of return metrics. For a calculator, this is transparent; it doesn't discuss side effects or external calls, which are not applicable.

  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 headline purpose, a list of args that is necessary given no schema descriptions, a returns line, and a clear usage directive. Every sentence earns its place; 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 12 parameters, no output schema, and no annotations, the description provides a complete picture: it defines all inputs, output metrics, and when to use the tool. No critical information is missing for an agent to invoke it correctly.

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

  Parameters5/5

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

  Schema has 0% description coverage, but the description compensates excellently by listing every parameter with units, examples, and defaults (e.g., 'purchase_cost_cny: 1688/supplier unit cost in CNY (e.g. 27)'). This adds significant meaning beyond the schema's bare property names.

  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 tool as an FBA profit calculator for Amazon unit economics, with a specific verb ('calculates') and resource ('FBA products'). It lists outputs (breakeven price, profit, ACOS, etc.), distinguishing it from sibling tools like keyword_analyze or asin_score.

  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 'USE THIS TOOL WHEN: Evaluating profit viability of a product before sourcing' provides explicit use context, but does not mention when-not-to-use or name alternatives. Since the tool's function is unique among siblings, this is sufficient but not fully exhaustive.

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