Server Quality Checklist

Tool Scores

• ichiba_product_searchA
  4.2/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, indicating safe, read-only behavior. The description adds that the tool groups products across shops and returns min/max/average prices and shop count, which is useful context beyond 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 concise with two languages, each sentence is meaningful and front-loaded. It efficiently covers purpose, usage, and an example filter with 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?

  The description explains the core function, when to use, and filter options. It does not detail pagination or sort behavior, but these are covered in the schema. No output schema exists, but the description outlines what is returned (min/max/average price, shop count).

  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 baseline is 3. The description does not add significant new meaning to parameters beyond what the schema already provides, though it reinforces keyword vs product_id dependency and the purpose of maker_code.

  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 searches Rakuten's Item Price Navi, a cross-seller product catalogue grouping identical products. It includes the verb 'search' and distinguishes itself from the sibling 'ichiba_item_search' by specifying it is for price comparison.

  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 to use this tool instead of ichiba_item_search when comparing prices or determining if a price is fair. It also mentions filtering by maker_code. Lacks explicit when-not-to-use statements, but the guidance is clear.

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

• ichiba_item_searchA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnly and idempotent. The description adds value by detailing the shipping verification logic and the derived fields (postageLabel, estimatedTotalPrice), but does not mention any behavioral edge cases beyond that.

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

  Conciseness3/5

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

  The description is bilingual with full Japanese translation, making it longer than necessary. While front-loaded with purpose, the repetition reduces conciseness. Could be trimmed to essential English.

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

  Completeness5/5

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

  Despite no output schema, the description fully explains return fields and shipping logic. It covers usage guidelines, alternatives, and parameter summary, making it complete for the tool's 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?

  Schema coverage is 100%, so the description adds little new meaning to parameters. It summarizes available filters but doesn't provide additional context beyond what the schema already describes.

  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 'Search products on Rakuten Ichiba by keyword' with specific verb and resource. Lists supported filters and return fields, distinguishing it from sibling tools like genre_search or ranking.

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

  Usage Guidelines5/5

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

  Explicitly tells when to use an alternative (compare_ichiba_value for value comparisons) and provides step-by-step instructions if used directly, including sorting, shipping verification, and prohibitions on guessing shipping.

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

• ichiba_tag_searchA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, confirming safe, read-only, idempotent behavior. Description adds return structure but no additional behavioral traits beyond annotations. No contradiction.

  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?

  Two sentences (plus Japanese translation) with no fluff. Front-loaded with main purpose and immediately actionable. Every sentence adds value.

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

  Completeness5/5

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

  No output schema, but description covers all necessary details: input source, core action, and return fields (tag group, name, parent). Complete for a simple lookup 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 tag_id already documented. Description adds valuable context about where tag IDs originate (from other search tools), which goes beyond the schema's description.

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

  Purpose5/5

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

  Description clearly states the verb 'Look up details' and the resource 'Rakuten Ichiba tag by tag ID'. It explains what a tag is (facet-style attributes) and specifies return fields (tag group, name, parent). Distinct from sibling search/ranking 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?

  Description tells where to obtain the required tag IDs (from ichiba_item_search item responses and ichiba_genre_search), providing clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives.

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

• ichiba_genre_searchA
  4.6/5.0
  Behavior5/5

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

  The description adds behavioral details beyond the annotations: fetching ancestors, siblings, and direct children for a given genre ID. The annotations already indicate read-only, idempotent, and open-world, and the description does not contradict them.

  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 concise English sentences (plus Japanese translation) with no wasted words. It front-loads the purpose and then explains behavior.

  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?

  The description is complete for a simple read-only browse tool: it explains what the tool does, when to use it, and the parameter behavior. It does not describe the output format, but given the tool's simplicity and lack of output schema, this is acceptable.

  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 single parameter genre_id has 100% schema coverage; the description adds the special behavior for value '0' (top-level) and drilling down, which is not explicitly in the schema description but is implied. This adds value beyond 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 browses the genre hierarchy, specifies the verb (Browse), resource (genre hierarchy), and the effect of passing '0' vs a specific genre ID. It is distinct from sibling tools that search or rank items.

  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 it is useful for narrowing item searches or discovering categories, providing clear context. It does not give explicit when-not-to-use or alternatives, but the sibling tools are sufficiently different.

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

• ichiba_item_rankingA
  4.8/5.0
  Behavior5/5

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

  Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. The description adds significant context: states the tool returns specific fields (rank, price, review stats, etc.), gives detailed shipping analysis steps (shippingVerified handling, web-search for shipping costs, never guess shipping), and notes Rakuten's ranking cap of ~1000 items. 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.

  Conciseness4/5

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

  The description is relatively long but well-structured: main purpose first, then usage guidance, then detailed protocol steps in numbered format. Japanese version follows efficiently. Slightly verbose due to duplication of steps in both languages, but necessary for bilingual audience. Front-loaded key information.

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

  Completeness5/5

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

  Given the tool's complexity (5 optional params, no output schema), the description is highly complete. It covers purpose, filtering options, returned fields, usage protocols, and shipping analysis steps. The absence of an output schema is compensated by listing returned data fields. All essential information for correct agent invocation is present.

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

  Parameters4/5

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

  Schema coverage is 100% and each parameter already has a description. The tool description adds extra value by explaining usage constraints (page max 34 due to Rakuten cap, genre_id default 0 for overall) and contextual hints (age demographic filtering), going beyond the schema. Deduction for not elaborating on all parameters, but adequate given high 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 the tool retrieves Rakuten Ichiba bestseller rankings, supports filtering by genre, period, age, and gender, and lists returned fields. It distinguishes from sibling tools like ichiba_genre_search by mentioning genre ID lookup, and includes both English and Japanese for clarity.

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

  Usage Guidelines5/5

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

  Explicitly tells when to use the tool vs alternatives: directs to ichiba_genre_search for genre IDs, and recommends the compare_ichiba_value prompt for cost comparisons. Provides a numbered step-by-step protocol for direct use, including pre-sorting and shipping handling rules.

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