Server Quality Checklist

Tool Scores

• amazon_batch_statusB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description must disclose behavioral traits. It indicates a read-only polling operation, but does not mention safety, rate limits, or whether it blocks or returns immediately. Adequate but minimal.

  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?

  A single sentence with no fluff, front-loaded with the action verb 'Poll'. Every word is necessary.

  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 is adequate for a simple polling tool, but lacks context on return values (no output schema) and lifecycle (e.g., relationship to batch creation). More detail would improve completeness.

  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?

  The only parameter 'id' has no description in the schema (0% coverage) and the description does not explain what it represents (e.g., the job ID from amazon_batch_create). The description fails to add meaning 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 uses a specific verb 'Poll' and resource 'async batch job', and specifies that it returns 'progress + results'. This clearly distinguishes it from sibling tools like amazon_batch_create (creation) and unrelated searches.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives, such as indicating that it should be called after creating a batch job with amazon_batch_create, or any prerequisites or polling behavior.

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

• amazon_productB
  3.4/5.0
  Behavior2/5

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

  No annotations provided; description leaves burden on text. States return fields but omits idempotency, rate limits, authentication needs, or any side effects. For a fetch tool, read-only behavior is implied but not explicit.

  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?

  Single sentence is efficient and front-loaded with action 'Fetch structured data'. No wasted words.

  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?

  With 3 parameters and no output schema, description mentions ~55 fields and examples. Lacks error handling, response format, or data shape beyond field list.

  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 covers all parameters, description adds no extra meaning beyond 'by ASIN'. Baseline 3 applies due to 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?

  Description clearly states verb 'Fetch', resource 'structured data for a single Amazon product', and identifier 'by ASIN'. Lists sample fields, distinguishing from sibling batch and search tools.

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

  Usage Guidelines3/5

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

  Implicitly for single product lookup by ASIN, but no explicit comparison with sibling tools (amazon_search, amazon_batch_*). Lacks when-not-to-use or alternative guidance.

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

• amazon_batch_createA
  3.5/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 burden. It mentions async processing and result retrieval methods, but lacks details on side effects, auth, rate limits, or error handling. The description is insufficient for a tool with no structured behavioral hints.

  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 that front-loads the purpose and includes key details (limit, result method). No extraneous words.

  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 missing annotations and output schema, the description covers main function and result retrieval. However, it lacks details on error handling, item validation, and batch id format. Adequate but with gaps.

  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 33%, only webhook_url has a description. The description adds context for items ('ASINs or search queries') but does not explain endpoint values or items structure beyond the schema. It partially compensates but not fully.

  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 queues up to 1000 ASINs or search queries for async processing and returns a batch id. It distinguishes from siblings like amazon_batch_status (poll), amazon_product, and amazon_search (single lookups).

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

  Usage Guidelines3/5

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

  The description implies use for multiple items ('up to 1000 ASINs or search queries') and mentions polling or webhook, but does not explicitly state when to avoid this tool (e.g., for single queries) or contrast with siblings.

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

• amazon_searchA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose all behavioral traits. It mentions output includes organic/sponsored positions, prices, ratings, and image URLs, but does not address pagination behavior, result count per page, rate limits, or authentication needs. Adequate but not fully 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 a single sentence with a clear verb and a returns clause. No wasted words; front-loaded with purpose.

  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?

  For a search tool with multiple parameters (sorting, pagination, domain) and no output schema, the description lacks details on result structure, items per page, and sorting behavior. It does not connect to sibling tools or mention prerequisites.

  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 description coverage is only 20% (only query has a description). The description does not explain parameters like domain, sort_by, start_page, or pages, leaving their semantics unclear. It adds minimal value beyond the schema defaults and enums.

  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 runs an Amazon keyword search and lists the returned data: ranked product listings with organic/sponsored positions, prices, ratings, and image URLs. It distinguishes from siblings like amazon_product (single product) and batch tools.

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

  Usage Guidelines3/5

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

  The description implies usage for searching Amazon, but does not explicitly state when to use this tool versus siblings like amazon_product for detail retrieval or batch tools for bulk operations. No guidance on 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.