Server Quality Checklist

Tool Scores

• pack_containersA
  3.6/5.0
  Behavior3/5

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

  Discloses return format (coordinates, volume utilization, weight, unplaced pieces) and solver used, but does not explain behavioral traits like whether it modifies state, handles special shapes (box/cylinder), or applies stacking/rotation defaults. No annotations to supplement, so description bears 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 action and result. Every word serves a purpose; no filler.

  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?

  Adequate for a tool with nested parameters and no output schema, but missing details on container vs. containers options, shape handling, and option defaults. Could be more complete given complexity.

  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 coverage is 50% (some fields have descriptions). Description adds output context but does not explain input parameters like shape, includeInLoading, allowStacking, allowRotation, loadingDirection, or container options. Without compensation, this leaves agents uncertain about key inputs.

  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 verb 'pack', resource 'cargo SKUs into shipping containers', and solver used ('Kubova solver'). Distinct from siblings (estimate_capacity, generate_report, verify_key) which focus on capacity estimation, reporting, and verification.

  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?

  Implies usage for packing cargos into containers but does not explicitly state when to use vs. alternatives (e.g., estimate_capacity for capacity checks). No exclusion criteria or prerequisites provided.

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

• verify_keyA
  3.8/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=true, so the description adds value by specifying the exact return fields (identity, scopes, rate limit). However, it does not disclose any behavioral traits beyond what annotations imply, such as what happens if the key is invalid or if network issues occur.

  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, focused sentence that immediately states the action and return value. There is no extraneous information, making it highly efficient for an agent 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?

  Given the tool's simplicity (no parameters, no output schema, and sibling tools indicating different domains), the description covers the essential purpose and output. It could be more complete by stating the precondition that an API key must be configured, but overall it is sufficient for a verification 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?

  The input schema has zero parameters with 100% coverage, so the description has no parameter details to add. By the baseline rule for 0-parameter tools, a score of 4 is appropriate, as the description correctly implies no input is needed beyond the configured key.

  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 (verify) and the resource (configured API key), and specifies what it returns (identity, scopes, rate limit). This distinct purpose is well differentiated from sibling tools like estimate_capacity, generate_report, and pack_containers.

  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 alternatives, no context about prerequisites (e.g., having a configured API key), and no mention of when not to use it. The agent must infer usage from the tool name and description alone.

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

• estimate_capacityA
  4.3/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, and the description adds behavioral details: real 3D packing, all cartons in same container, reports binding limit. No contradictions. Adds value 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 a single paragraph of four sentences, front-loaded with the main purpose, and every sentence adds value. No unnecessary words.

  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 tool with two parameters (one nested object) and no output schema, the description covers product structure, container behavior, and reports the binding limit. It is complete for effective use.

  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 description explains product structure (cartons with qtyPerSet) and containers omission, supplementing schema with example and constraint that all cartons go together. Some schema properties have descriptions, and description enhances understanding.

  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 estimates how many complete sets of one product fit in a container, using real 3D packing, and reports the binding limit. It distinguishes from siblings by specificity and operational detail.

  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 provides guidance on omitting containers for standard containers, but does not explicitly contrast with siblings or state when not to use. It gives some usage context but lacks comprehensive guidelines.

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

• generate_reportA
  4.4/5.0
  Behavior4/5

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

  Given no annotations, the description properly discloses that omitting result causes repacking (which may differ), and describes the output format. However, it does not mention potential side effects or constraints like rate limits, though none are expected for a report generator.

  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 three well-structured sentences: purpose, critical usage guideline, and output summary. Every sentence provides necessary information without 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 moderately complex tool with nested parameters and no output schema, the description covers purpose, key usage nuance, and return format. It is adequate but could be enhanced by explaining 'CAD-style' or detailing the options parameter.

  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 description adds significant meaning only for the result parameter, explaining its role in ensuring consistency. For other parameters (cargos, containers, options), it adds no value beyond the schema, which has 60% coverage, so the description does not fully compensate.

  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 generates a 'CAD-style PDF + 3D PNG report for a packing job'. It specifies the output format and the resource, effectively distinguishing it from sibling tools like estimate_capacity and pack_containers.

  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 explains when to use the result parameter and why, including the alternative behavior if omitted. This guides the agent to maintain consistency with prior packing plans, which is a critical usage nuance.

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