Server Quality Checklist

Tool Scores

• tracepass_passport_partiesA
  4.4/5.0
  Behavior4/5

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

  Beyond the idempotentHint annotation, the description adds behavioral context: 'set' adds/replaces one role, 'remove' clears one role, and parties ideally carry a validated GLN. It does not contradict annotations and provides useful detail about how each action behaves.

  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 compact, front-loaded with purpose, and uses a clean bullet structure for actions. Every sentence adds meaningful information with no redundancy or filler.

  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?

  The description covers both actions, their required arguments, and the domain concept of economic-operator parties. Given the output schema exists and annotations declare idempotency, the description is sufficiently complete, though it does not discuss validation failure or edge-case behavior.

  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 coverage is 100%, so the baseline is 3, but the description adds value by grouping parameters per action (set includes legalName, gln, country, legacyOperatorId; remove only id and role) and by highlighting the validated 13-digit GLN requirement that is not in the schema description.

  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 manages economic-operator parties on a passport, lists the specific roles, and distinguishes it from sibling tools like passport_fields or passports. The verb 'manage' paired with the resource and action definitions leaves no ambiguity.

  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 shows when to use set vs remove actions and their required args, providing clear operational context. It does not mention alternatives or exclusions relative to sibling tools, but the action-based instructions are sufficient for most use cases.

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

• tracepass_passport_fieldsA
  4.6/5.0
  Behavior4/5

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

  Beyond the idempotentHint annotation, the description discloses that every change is recorded in the passport's audit trail and tagged as an API-key update. It also explains the 409 error condition for ambiguous serials and that the value type must match the field's dataType. This adds meaningful behavioral context without contradicting the annotation.

  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 compact and well-structured: a purpose sentence followed by a clear list of actions with their args and usage notes. Every sentence adds value; there is no redundant repetition of schema information. The format makes it easy to scan and understand the tool's behavior.

  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?

  Given the tool's complexity (two actions, nested args, optional disambiguator) and the presence of an output schema, the description covers all necessary aspects: purpose, action mechanics, error handling, audit trail, and value typing. No critical behavior is left unexplained, and the output schema handles return-value details.

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

  Parameters5/5

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

  Although the input schema describes each parameter, the description adds crucial semantic meaning by tying parameters to actions: it details the args structure for update vs update_by_serial, clarifies the optional `gtin` disambiguator, and specifies that `value` must match the field's dataType. This goes well beyond the schema's one-line descriptions.

  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 opens with a specific verb+resource: 'Update field values on a Digital Product Passport.' This clearly states the tool's function and distinguishes it from sibling tools that manage passports, products, parties, EPCIS, or templates. The two actions (update, update_by_serial) are concrete and further clarify the scope.

  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 gives clear guidance on choosing between the two actions: 'update' by passport id and 'update_by_serial' by your own serial. It explains the serial-uniqueness caveat within a GTIN and the 409 ambiguous_serial error, advising to pass `gtin` or use update by id. However, it does not explicitly compare this tool to sibling tools or state when to prefer this over them.

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

• tracepass_templatesA
  4.6/5.0
  Behavior5/5

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

  Beyond the readOnlyHint/idempotentHint annotations, the description adds substantial behavioral detail: the battery-specific resolution order, the warning that using `required` without checking scope invents obligations, and the mutually exclusive EV/LMT field sets. This goes far beyond what annotations alone convey.

  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?

  The description is long but well-structured: a lead purpose sentence, a clear action breakdown, and a focused battery caveat. Every sentence carries meaningful constraints or guidance, and the critical battery logic is visually separated. It is dense but appropriate for the tool's complexity.

  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?

  Combined with the rich input schema, output schema, and annotations, the description is complete: it covers scope, all categories, action-specific behavior, and the most confusing edge case (battery). It even references governing regulations and dates, leaving little ambiguity for an agent selecting or invoking this 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?

  Schema coverage is 100%, but the description adds semantic depth by explaining the action/args passing pattern and elaborating on the meaning of `category` (including the full enum and battery-specific resolution logic). It slightly duplicates what the schema already states, so it does not reach 5, but it does exceed the baseline.

  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 identifies this as a read-only discovery tool for regulatory DPP templates, with a specific verb ('Discover') and resource ('regulatory field schema for each DPP category'). It distinguishes itself from siblings (e.g., tracepass_passports, tracepass_products) by focusing on compliance requirements and template-level reference data.

  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?

  It provides clear usage context: 'Use this to advise on requirements before creating products/passports, and to gap-check a draft against the rules.' This tells the agent when to consult the tool, though it does not explicitly name sibling tools as alternatives or state 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.

• tracepass_productsA
  4.7/5.0
  Behavior5/5

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

  Despite minimal annotations (only idempotentHint=false), the description discloses important behaviors: list/get are read-only, create_batch has partial success with per-item status and consumes N writes upfront with 429 on daily cap, and archive is soft, reversible, and blocked with 409 when referenced by non-archived passports. This exceeds typical transparency expectations.

  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 well-structured with a clear opening, a contextual paragraph, and bulleted actions. Each sentence adds value—no fluff. The format is scannable and information-dense without being verbose, earning a high score.

  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?

  The tool is complex with six actions and nested args, but the description covers every action's arguments, constraints, error conditions, and edge cases (partial success, rate limit, conflict). Presence of an output schema means return-value details are not needed. Sibling context and annotations are adequately supplemented.

  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 coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema: category enum values, update requiring at least one field, batch element structure, and list filters. It also clarifies constraints like limit ≤100 and page numbering, which the schema describes but the description reinforces for usability.

  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 opens with 'Manage the TracePass product catalogue' and clearly defines the product as the catalogue layer, distinguishing it from passports and other sibling tools. It enumerates six specific actions with their arguments, making the tool's purpose and scope unmistakable.

  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 gives clear context on when to use this tool ('Manage the TracePass product catalogue') and explains the relationship to passports, implying use for catalogue-level operations. It does not explicitly name alternative tools for exclusion, but the product/passport distinction provides sufficient guidance.

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

• tracepass_epcisA
  4.8/5.0
  Behavior5/5

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

  With only idempotentHint: false in annotations, the description carries the full behavioral burden and does so extensively. It marks four actions as read-only, reveals that capture returns a 202 with a captureJobId and is asynchronous, and discloses specific error conditions like 409 ambiguous_serial and 403-style messages. 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 well-structured with a concise lead sentence, a critical plan-requirement note, and a clean action-by-action bullet list. Every sentence adds value, and the structure makes the multi-action tool easy to scan and understand.

  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?

  Given the tool's complexity (five actions, nested args, async behavior, plan restrictions), the description is complete. It covers all actions, their required args, error conditions, and asynchronous behavior. Return values are not detailed, but an output schema exists, so that omission is acceptable.

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

  Parameters5/5

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

  Although the schema already has 100% description coverage, the description adds substantial meaning beyond it. It maps each parameter to its action, clarifies that a serial is unique only within a GTIN, explains that events can be an EPCISDocument or an array, and gives examples of EPCIS query parameters. This goes well beyond the schema's field-level descriptions.

  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: 'GS1 EPCIS 2.0 supply-chain events.' It then enumerates each specific action (export, export_by_serial, capture, capture_job, query) with a precise verb and resource. This distinguishes it from sibling tools like tracepass_passports and tracepass_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?

  The description provides explicit usage context: it notes which actions are included on Starter plans vs. require the paid add-on, and explains when to use export_by_serial versus export with a GTIN. It does not explicitly name alternative sibling tools, but the action-level guidance is clear enough for correct selection.

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

• tracepass_passportsA
  5/5.0
  Behavior5/5

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

  The description discloses critical behavioral traits beyond the idempotentHint annotation: create is billable and may return 402, archive permanently 404s the QR, serials are only unique within a GTIN and trigger 409 errors, and registry_readiness is only a formal check not substantive compliance. These are non-obvious, high-impact details not visible in annotations or schema.

  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 long but well-structured: a short intro, a prominent billing/irreversibility warning, then a bullet-style action list with inline args and notes. Each sentence serves a purpose, and critical warnings are front-loaded before the action list. Despite the length, it is easy to scan and reference.

  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 12 actions, nested args, multiple enums, and high-stakes side effects, the description covers all bases: read vs write actions, per-action parameter requirements, error conditions (402, 409), and the distinction between registry readiness and compliance. The presence of an output schema for each action likely completes the picture, but the description alone is already thorough.

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

  Parameters5/5

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

  Though schema coverage is 100%, the description adds significant semantic value: it clarifies that `confirmOverage` must only be true after explicit user consent, that `format` values differ by action (summary/full vs svg/png), that `status` is an enum with exact values, and that `gtin` resolves ambiguous_serial. These enrich the schema definitions with usage context.

  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 opens with a clear verb+resource statement: 'Manage Digital Product Passports — create, read, and run lifecycle actions.' It then enumerates 12 specific actions with distinct purposes, effectively distinguishing this tool from siblings like tracepass_products (products) and tracepass_epcis (event data). No ambiguity about scope.

  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?

  Provides explicit guidance on when to use each action, including when to avoid certain ones: 'archive is IRREVERSIBLE... prefer suspend when a change might be undone.' It also explains when to pass `gtin` to resolve ambiguous serials, and warns about the billing implications of `create`. This goes well beyond basic context.

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