Server Quality Checklist

Tool Scores

• galaxus_browse_categoryA
  3.9/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true and openWorldHint=true, covering safety and variability. The description adds the helpful metaphor 'equivalent of opening a category page' but doesn't disclose additional behavioral traits such as pagination behavior, result limits (though schema covers limit), or any quirks. Given the annotations already handle the key safety signal, a 3 is appropriate.

  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 core purpose, and every phrase adds value. It avoids redundancy and is appropriately sized for a focused read-only browsing tool. No wasteful fluff or repetition of schema details.

  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 8 parameters and no output schema, so the description could helpfully outline the return shape (products list, next_cursor, filters block). It doesn't, but the schema's filter and cursor parameters imply the response contains those elements. The core action is clear, and the absence of output schema makes the description slightly incomplete but not critically so for a browsing 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?

  The schema has 100% description coverage for all 8 parameters, including details on sort enums, cursor semantics, filter structure, and price shorthand. The description itself doesn't add any parameter-specific meaning beyond saying where category_id comes from, which is external context. Baseline 3 applies because the schema carries the burden effectively.

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

  Purpose5/5

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

  The description clearly states the tool lists products in a category without a search term, contrasting with search tools. It specifies the resource (category/product type) and the action (list), and distinguishes from siblings like galaxus_search and galaxus_browse_brand by its unique purpose.

  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 frames the use case as 'without a search term', implying when to choose category browsing over search. It also tells where category ids come from (search results, pt facet, autocomplete), giving concrete guidance on how to obtain the required parameter. It doesn't explicitly exclude alternatives like browse_brand, but it's clear enough.

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

• galaxus_autocompleteA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint true and openWorldHint true, so the description only adds context about returning suggestions and matching products. It does not describe pagination, limits, or other behavioral traits, but the annotation coverage means it doesn't carry the full burden.

  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, front-loaded with the core function, and every sentence contributes value. 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 simple one-parameter tool with annotations and no output schema, the description covers the core behavior and use case. It could mention how to interpret the response or note limitations, but it is sufficient for an agent to decide when to invoke it.

  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 'Partial search term' describing the query parameter. The description adds 'vague phrase' which reinforces the partial nature but doesn't add new syntax or format details beyond schema, 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 a specific verb ('type-ahead lookup') and resource ('search-term suggestions' with categories and matching products). It distinguishes itself from sibling tools by focusing on resolving vague phrases before a full search.

  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 mentions when to use: 'Useful to resolve a vague phrase into a concrete product or category before searching.' This gives clear context but does not explicitly list when-not-to-use or name alternatives like galaxus_search, so it misses the top score.

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

• galaxus_browse_brandA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the useful behavioral detail about brand IDs coming from a facet, but does not disclose other behavioral traits such as pagination behavior or how results are ordered by default. With annotation coverage, this is acceptable but adds only minimal extra 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 two short sentences, front-loaded with the main purpose ('List products from one brand') and immediately followed by the most critical usage context. There is no wordiness or repetition; 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?

  Despite having 8 parameters and no output schema, the description is reasonably complete. The schema covers all parameters with descriptions, annotations cover the safety profile, and the description fills the one key gap: where to obtain brand_id. The return format is implied for a list-products tool and not a major omission, so this is adequately complete for the tool's simplicity.

  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 every parameter's meaning and constraints. The description adds a small hint about brand_id ('Brand ids come from the `bra` facet...') but does not enrich the semantics of the other parameters. This matches the baseline of 3 when the schema is self-sufficient.

  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: 'List products from one brand.' This uses a specific verb (List) and resource (products) with a clear scope (one brand), distinguishing it from sibling tools like galaxus_browse_category (which lists by category) and galaxus_search (which is broader). It also gives a concrete hint about where to obtain brand IDs.

  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 for when to use this tool by explaining that brand IDs come from the `bra` facet of `galaxus_search` or `galaxus_browse_category`. This implicitly indicates a prerequisite workflow. However, it does not explicitly mention alternatives or when not to use it (e.g., 'use search for keyword queries'), 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.

• galaxus_get_review_summaryA
  4.1/5.0
  Behavior4/5

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

  The description adds the behavioral caveat that individual review texts are not available from the API, which is beyond the readOnly/openWorld annotations. It also lists exactly what the summary includes, setting expectations for output granularity. 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 two sentences with no fluff. The first sentence front-loads the key output details, and the second adds a valuable limitation. Every word earns its place.

  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 single-parameter read-only summary tool with no output schema, the description is complete: it explains the input (via schema), the output contents, and a key limitation. An agent has sufficient information to invoke the tool and interpret results.

  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 the single parameter 'product', which is well-defined as 'Numeric product id or Galaxus product URL'. The tool description does not add further detail about this parameter, so it remains at the baseline for 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's purpose: summarizing customer reviews with average rating, rating count, and pros/cons. It distinguishes itself from siblings by focusing on review summaries (e.g., galaxus_get_product likely returns product details). The additional note that individual review texts are not exposed further clarifies its scope.

  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 when to use the tool (when a summary of customer sentiment is needed) but does not explicitly state when not to use it or compare with alternatives like galaxus_get_product or galaxus_related_products. The usage guidance is implicit rather than explicit.

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

• galaxus_related_productsA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds behavioral nuance about what each kind means (similar, bought together, accessories), but does not disclose output format, pagination, or potential edge cases. It adds some value but is not rich in behavioral disclosure.

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

  Conciseness5/5

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

  The description is a single compact sentence that uses backticks for clarity and organized enumeration. It conveys essential information without any filler, making it optimally concise and well-structured.

  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 does not specify the return format, but the tool's purpose is simple and intuitive. The description covers the main behavioral distinctions (three relationship kinds) and annotations cover safety. It is fairly complete for a read-only related-products tool, though a note about the output structure would make it fully complete.

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

  Parameters4/5

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

  Schema has 100% parameter coverage, so baseline is 3. The description enriches the `kind` parameter by explaining each enum value in business terms (alternatives to compare against, complements, add-ons), going beyond the schema's 'Which relationship to follow.' This added semantic detail justifies a 4.

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

  Purpose5/5

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

  The description clearly states the tool returns related products for a given product, and enumerates the three relationship types (`similar`, `bought_together`, `accessories`) with their intents. This distinguishes it from sibling tools like search, get_product, and browse_category, which have 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 clear context on when to use each relationship type (alternatives, complements, add-ons), but does not explicitly mention when to choose this tool over sibling tools or state any exclusions. This gives users practical guidance within the tool but not explicit cross-tool when/not guidance.

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

• galaxus_searchA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable context about the return contents (prices, ratings, availability) and the facet feedback loop, which explains how the tool behaves beyond simple read-only. 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 two sentences long, front-loaded with the core purpose, and every sentence adds meaningful information. There is no redundancy or fluff.

  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 search tool with 8 parameters and no output schema, the description covers the main return value (products with metrics and facets) and the iteration pattern. The schema handles remaining details like pagination and limits. It is complete enough for an agent to correctly invoke the 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 descriptions cover 100% of parameters, including detailed explanations for filters, sort, and cursor. The description's mention of facets maps to the filters parameter but adds little 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 it performs 'full-text product search across the shop' and specifies that it returns products with prices, ratings, availability, and facets. This distinguishes it from sibling tools like browse_category or browse_brand, which have 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 clear context for when to use full-text search ('across the shop') and implies the iterative workflow of feeding facets back as filters. However, it does not explicitly exclude alternatives or mention when not to use it, 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.

• galaxus_get_productA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate read-only and open-world behavior. The description adds transparency by enumerating exactly what data fields will be returned, which goes beyond the annotation hints. There is 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, front-loaded with the primary purpose and then a compact list of included data. No redundant or vague wording.

  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 one-parameter read-only tool, the description adequately covers accepted input, the full scope of returned data, and is complete even without an output schema. The annotations further cover safety and open-world aspects.

  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 single 'product' parameter with examples of numeric ID and URL formats. The description restates this information without adding new semantic detail, so the baseline score of 3 for high schema coverage 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 states a clear, specific action: retrieving full detail for a single product, and enumerates the data included (price, availability, rating, specifications, variants, price history, warranty, returns). It is clearly distinct from sibling search/browse/review 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?

  The description makes the intended use obvious—looking up one product by ID or URL—which differentiates it from search/browse siblings, but it does not explicitly state 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.