Server Quality Checklist

Tool Scores

• add_productB
  3.1/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 mutation ('Create') but does not disclose side effects such as duplicate SKU handling, idempotency, permission requirements, or whether existing data is affected. The agent knows it is a write operation but nothing about its behavioral edge cases.

  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 that front-loads the action and efficiently lists all fields in a compact order. No redundant words, no filler. Every part contributes to conveying the core operation.

  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 5-parameter create tool with no annotations and no sibling differentiation, the description is minimally viable but incomplete. It correctly identifies the operation and fields, and an output schema exists to document return values. However, it lacks critical operational context such as duplicate handling, required permissions, or when to prefer the sibling add_product_smart.

  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 lists all five parameters and marks description as optional, which clarifies the confusing optionality expressed in the schema's convoluted anyOf. However, it adds no deeper semantic meaning beyond the parameter names, and the schema already defines types and constraints.

  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 a specific verb ('Create') and resource ('a new product'), and enumerates the key fields (sku, name, optional description, price, quantity). It is unambiguous about the operation, but it does not differentiate from the sibling tool add_product_smart, both of which appear to create products.

  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?

  The description provides no guidance on when to use this tool versus add_product_smart or how it differs from get_product_by_id or delete_product. There is no mention of conditions, alternatives, or exclusions, leaving the agent to infer usage from the tool name alone.

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

• add_product_smartA
  3.7/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 explaining behavior. It discloses the key non-obvious trait: a missing description will be AI-generated. It does not discuss failure modes or side effects, but the core create 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?

  A single sentence that front-loads the action and then adds the key qualifier. There is no filler or redundant 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?

  The tool is simple and an output schema exists, but the description does not differentiate add_product_smart from add_product or clarify behavior when a description is actually supplied. These are meaningful gaps for a tool with no annotations.

  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 adds meaning for the description parameter by stating it is optional and auto-generated when missing, but the other parameters (sku, name, price, quantity) rely on their self-explanatory names without additional context.

  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 action ('Create a new product') and the distinguishing behavior ('smart ai generated description if missing'). It does not explicitly contrast with the sibling add_product tool, so it stops short of a 5.

  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 phrase 'if missing' implies that this tool is useful when a description is not provided, which is a light usage cue. However, it never mentions alternatives like add_product or explains when the plain version should be preferred.

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

• delete_productA
  3.7/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 states the delete action and the return value, but it does not mention irreversibility, idempotency, behavior for non-existent ids, or permission requirements, which is a significant gap for a destructive 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 two short sentences with no filler. The action is front-loaded and the return type is given directly, making it concise and efficient.

  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?

  This is a simple single-parameter destructive call with an output schema, but the description omits behavior for non-existent ids (e.g., false vs error), permanence, and side effects. For an agent to confidently invoke it on real data, this is only partially 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 description coverage is 0%, so the description must compensate. Saying 'by id' clarifies that the sole parameter 'id' refers to the product identifier, adding meaning beyond the bare schema. This fully covers the parameter's role, though it doesn't discuss id sourcing.

  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 ('Delete') and a resource ('product by id'), making the operation unambiguous. It clearly distinguishes itself from siblings like add_product and get_product_by_id, and the return value is also explicit.

  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 deleting a product, but provides no explicit guidance about when to choose this tool over alternatives or any exclusions. With siblings like get_product_by_id, an agent must infer that delete is intended for removal, which is straightforward but not directly stated.

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

• get_product_by_idA
  3.7/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 behavioral disclosure burden. 'Fetch' clearly conveys a read-only operation, which is helpful, but it does not mention behavior for missing IDs, error responses, or potential side effects. This is adequate but not deeply 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, front-loaded sentence with no filler. 'Fetch a single product by numeric ID' efficiently states the action, target, and key constraint, earning every word.

  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 a single parameter and an existing output schema, the description plus schema provides the essential information for a correct call. Minor gaps like error behavior and explicit usage routing remain, but they do not block an agent from invoking this tool correctly.

  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 documentation coverage is 0%, so the description must compensate for the parameter 'id'. It only adds 'numeric ID', which essentially restates the schema's integer type. It does not explain what the ID represents or provide any meaning beyond the property name and schema 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 uses a specific verb ('Fetch') with a clear resource ('product') and a clear qualifier ('single', 'by numeric ID'), which makes it immediately distinct from sibling tools like add_product and delete_product. An agent can tell this is a read-by-ID operation without needing to inspect schemas.

  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 through the contrast between 'Fetch' and the sibling add/delete tools, but it never explicitly states when this tool should be chosen or when another tool would be more appropriate. The guidance is present only by inference, not direct routing.

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