Server Quality Checklist

Tool Scores

• remove_from_cartA
  4.1/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 reveals a critical behavioral trait: the tool is server-side only and requires a browser synchronization step. This goes beyond the schema, adding essential operational knowledge. It doesn't cover other side effects, but for a simple removal tool, this is significant 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?

  Two sentences, front-loaded with the purpose, followed by a crucial caveat. No redundant words or filler. Every sentence earns its place, and the structure is ideal for quick comprehension.

  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 parameter, no output schema, no annotations), the description is largely complete. It covers the main action, the server-side scope, and a critical synchronization edge case. It doesn't explain return values, but no output schema exists and the focus is on action, not results. Minor gaps remain but nothing critical.

  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 description does not elaborate on the 'items' parameter or its structure. With schema description coverage at 0% per context signals, the description should compensate, but it doesn't mention where to find SKU or how the array should be formed. The schema does provide a description for 'sku', but the tool description adds no value beyond that.

  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 action ('Remove products'), the target ('Selver.ee cart'), and the method ('by SKU'). This is a specific verb+resource+method, and it distinguishes from sibling tools like add_to_cart, view_cart, and search_products.

  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 context: 'Server-side only' and a clear conditional instruction for when a browser is open (must also dispatch cart/removeItem via chrome-devtools-mcp). This tells the agent when and how to use the tool, though it doesn't explicitly contrast with alternatives. The instruction is practical and actionable.

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

• view_cartA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly implies a read-only operation via 'view', but adds no detail about session requirements, potential errors, or side effects (which are minimal for a view operation).

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

  Conciseness5/5

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

  The description is a single, concise sentence that efficiently communicates all necessary information without redundancy. It is front-loaded with the action and resource.

  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, parameterless read-only tool, the description adequately defines what the tool does and what it returns (cart contents and total price). It is complete enough given the absence of output schema or annotations, though it leaves some nuance about the exact format of 'contents' unspecified.

  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 zero parameters, so there is no parameter information to clarify. As per guidelines, the baseline for 0 params is 4, and the description doesn't need to add parameter semantics.

  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 with a specific verb ('view') and resource ('current Selver.ee cart contents and total price'). It distinguishes itself from siblings by focusing on viewing rather than searching or modifying the cart.

  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: use this tool to inspect the current cart and its total price. It implicitly excludes modification or search operations, though it doesn't explicitly name alternative tools.

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

• add_to_cartA
  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 full burden of disclosing behavior. It mentions that a new cart is created if none exists ('Creates a new cart if none exists') and highlights the server-side nature and browser sync requirement. This goes beyond the bare function name and adds meaningful side-effect information. However, it doesn't mention error handling or how duplicates are treated.

  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: two sentences with the key action front-loaded. The second sentence provides essential operational context (server-side only, browser sync) without unnecessary fluff. It earns its place and remains easy to parse.

  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 mutation tool with no output schema and no annotations, the description covers the essential aspects: what it does, side effect of cart creation, and the critical sync requirement. It doesn't detail error cases or return values, but those are less critical given the simplicity. The sibling tool list adds context that this is one of several cart operations.

  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 tool description says 'by SKU' but does not explain the structure of the items array or the qty parameter. However, the input schema provides descriptions for both sku ('Product SKU (e.g. "T000089179")') and qty ('Quantity to add'), so the schema already carries the parameter explanation. The description adds only minimal emphasis on SKU, so it meets the baseline without substantial additional value.

  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: 'Add products to Selver.ee guest cart by SKU.' It uses a specific verb (add), identifies the resource (Selver.ee guest cart), and specifies the method (by SKU). This distinguishes it from sibling tools like search_products, view_cart, and remove_from_cart.

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

  Usage Guidelines5/5

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

  The description provides explicit usage context: it is server-side only, and if a browser is open on selver.ee/cart, the agent must also dispatch cart/addItem via chrome-devtools-mcp to keep the browser in sync. This is an explicit alternative/requirement that guides when to use this tool in conjunction with other actions.

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

• search_productsA
  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 burden. It discloses the key behavioral detail of return fields (prices, nutrition, stock status). The read-only nature is implied by 'Search', and the description adds useful context without contradicting any annotations. It doesn't mention pagination or error behavior, but for a simple search this is acceptable.

  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, front-loaded with the action and resource, and every sentence contributes value. The language tip is useful and directly actionable for the agent.

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

  Completeness5/5

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

  For a simple search tool with two well-schemaed parameters and no output schema, the description provides sufficient context: purpose, return contents, and query language guidance. It is complete enough for an agent to decide when and how to use it.

  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 100% coverage for parameters, so baseline is 3. The description adds value beyond the schema by providing concrete Estonian query examples (e.g., 'kana' for chicken), which clarifies the language hint already present in the schema. This enrichment earns 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 uses a specific verb ('Search') and resource ('Selver.ee product catalog'), and states exactly what is returned (prices, nutrition per 100g, stock status). This clearly distinguishes it from sibling cart tools (add_to_cart, view_cart, remove_from_cart).

  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 implies when to use it (searching the product catalog) and the sibling names make it obvious this is not for cart operations. However, it does not explicitly state when to prefer this over alternatives or exclude any use cases, 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.