Server Quality Checklist

Tool Scores

• parse_ediB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'plus a validation summary' and 'local operation', which hint at output and side-effect behavior, but it does not describe error handling, output format details, or limitations. This adds some value but remains thin.

  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 action and output, and no wasted words. The input requirement and safety note are efficiently included.

  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 tool with one parameter, existing annotations, and no output schema, the description covers the input requirement and states that output is structured JSON plus a validation summary. It could detail what the validation summary contains, but the description is otherwise sufficient for a low-complexity parser.

  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% for the single parameter 'content', which already describes the raw EDI document text. The description repeats this with 'Pass the full raw EDI text including the ISA/GS envelope', adding no new semantic detail beyond the schema's own description.

  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 verb 'Parse' and the resource 'raw X12 EDI interchange', with examples of document types. It implies a full-document scope via 'including the ISA/GS envelope', which somewhat distinguishes it from sibling tools like parse_segments, though it does not explicitly name an alternative.

  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 gives a usage instruction ('Pass the full raw EDI text') but offers no guidance on when to prefer this tool over siblings like validate_edi or parse_segments. There is no explicit 'use this when' or exclusion criteria.

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

• lookup_x12A
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'Local only; works in demo mode' and 'Read-only or local operation', but the latter is redundant. It does not describe return format or limitations beyond demo mode.

  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 short and front-loaded, with the main purpose in the first sentence. However, the final sentence 'Read-only or local operation' is redundant with the annotations and 'local only', introducing mild waste.

  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?

  With no output schema, the description does not explain what the tool returns or how results are structured. It covers local/demo behavior but leaves a gap for agents needing to know the output format for a search 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 coverage is 100%, with the 'query' parameter described as 'Segment id, ack code, or keyword.' The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 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 the tool searches the local X12 dictionary by segment id, ack code, or free text, with specific verb and resource. It distinguishes from the sibling tool 'lookup_element_definition' by focusing on segments and ack codes.

  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 notes 'Local only; works in demo mode', providing clear context on when to use this tool. It does not explicitly name alternatives or exclusions, but the local/demo scope gives practical guidance.

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

• validate_ediA
  3.9/5.0
  Behavior4/5

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

  The description goes beyond the annotations by disclosing the output format (validation summary with valid flag, errors, transaction set, control number, segment count) and explicitly stating 'Read-only or local operation', which aligns with the readOnlyHint annotation. It adds useful context about what is not returned (full parsed JSON), enhancing behavioral transparency beyond structured hints.

  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 primary purpose and then providing concise details about the return value. Every sentence contributes necessary information without any filler, making it appropriately sized and structured.

  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 single-parameter tool, the description is complete: it states the action, the input, and the output summary fields, while annotations cover safety characteristics (read-only). Since there is no output schema, disclosing the return summary list is essential and adequately covered. It lacks nothing for an agent to understand what this tool does and what to expect.

  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?

  With only one parameter and 100% schema description coverage, the schema already fully documents the 'content' parameter as 'The full raw EDI document text to validate.' The description repeats this concept without adding new details like format constraints, size limits, or encoding, so it adds no extra semantic value beyond the structured field.

  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 validates a raw EDI interchange against X12 structural rules, specifying the verb (validate), resource (EDI interchange), and rule set (X12 structural). This distinguishes it from sibling tools like parse_edi or validate_x12_structure, as it focuses on validation and returns a summary rather than the full parsed JSON.

  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 such as validate_x12_structure or parse_edi. It does not mention any exclusions, prerequisites, or competitor tools, leaving the agent to infer usage context from the tool purpose alone.

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

• lookup_element_definitionA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by clarifying the operation is 'read-only or local', scoping the search to specific dictionaries, and noting it is an alias. It does not contradict annotations and adds context beyond the structured safety hints.

  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, followed by a behavioral note. No filler or redundant information; every clause contributes to understanding the tool.

  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 lookup tool with 2 optional parameters, full schema coverage, and safety annotations, the description provides sufficient context about scope and behavior. It does not explain return values, but no output schema exists, and the tool is straightforward enough that this is not a major gap.

  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%, and the description echoes the schema's parameter descriptions but does not add substantial new meaning. The alias relationship between 'element' and 'query' is mentioned, but it is already present in the schema. 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 the tool is an alias for lookup_x12, used to search segment maps and ack codes within specific EDI dictionaries (850/810/856/837). This provides a specific verb ('search') and resource ('segment maps and ack codes'), distinguishing it from siblings like parse_edi or validate_edi.

  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 use for lookups and notes it is read-only or local, but it does not explicitly state when to use this tool versus lookup_x12 or other siblings. No exclusions or alternative conditions are given, so usage context is only implied.

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

• parse_segmentsA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context by stating 'Read-only or local operation' and mentions that it produces a validation summary, giving insight into side effects and output behavior beyond the safety flags. This is consistent 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 only two sentences, front-loads the essential purpose, and avoids unnecessary detail. Every word contributes to clarifying functionality and safety.

  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 single-parameter parse tool with clear annotations and sibling references, the description is sufficient. It explains the core operation, output, and safety profile. Minor gaps like the exact structure of the validation summary exist, but they are not critical for tool invocation.

  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 input schema documents the only parameter 'content' with 100% coverage, so the description does not need to add much. The phrase 'raw X12' in the description aligns with the schema's 'Full raw EDI document text', but no additional meaning is provided beyond the schema. 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 ('parse') and resource ('raw X12'), and specifies the output ('structured JSON plus validation summary'). It also distinguishes from siblings by identifying itself as an alias for parse_edi, making its function unambiguous.

  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 by saying it is an alias for parse_edi, so the agent can infer it should be used when parsing EDI content. However, it does not explicitly compare with alternatives like validate_edi or explain when this alias is preferred over the original, leaving some ambiguity in tool selection.

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

• validate_x12_structureA
  4/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true and destructiveHint=false, and the description's 'Read-only or local operation' mostly repeats this. The 'local operation' adds a small behavioral detail about network usage, and the alias relationship adds context, but the core behavior (validation) is already implied by the tool name and 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, front-loaded sentence that states the alias, purpose, input, and output with no wasted words. It is appropriately concise and easy to scan.

  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 tool with one parameter and no output schema, the description adequately covers what it does (validate), what it takes (raw X12), and what it returns (validation summary). However, it does not describe the contents of the validation summary or clarify why an alias exists, leaving a small gap in completeness.

  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 fully describes the single parameter 'content' as 'Full raw EDI document text' (100% coverage). The description does not add further parameter details beyond restating 'raw X12 interchange structure', which matches the schema, so no additional value is provided.

  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 validates a raw X12 interchange structure and returns a validation summary. It also identifies itself as an alias for validate_edi, making the purpose explicit and distinguishable from other siblings by naming the specific function.

  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 says 'Alias for validate_edi' which tells the agent this tool is interchangeable with validate_edi, providing a clear usage alternative. It also notes the read-only/local nature, but does not explicitly state when not to use it or contrast with other validation/parsing tools.

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

• explain_edi_errorA
  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 destructiveHint=false, and the description adds that it never calls the network and operates in demo mode—information not present in annotations. It also states the output contents (meaning, typical cause, fix, lookup_x12 cross-refs), which is useful behavioral 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?

  Two sentences, front-loaded with purpose and containing no redundant filler. The description efficiently includes purpose, data source, output contents, and network/read-only behavior.

  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 read-only explainer tool, the description covers output contents (meaning, cause, fix, cross-refs), offline mode, and no network usage, which is sufficient given the annotations cover safety. It lacks an explicit return type but that is not critical for an explanation 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 coverage is 100% with clear descriptions for code, segment, and rawError, so the description need not detail parameters. The description adds no parameter-specific semantics beyond the schema, thus 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 uses a specific verb ('explain') and resource ('EDI validation or functional-ack error') and clarifies the data source ('local X12 dictionary'), distinguishing it from validation/lookup siblings. The mention of lookup_x12 cross-refs further differentiates it from simple lookup 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 implies usage for explaining errors from validate_edi or 997/999 via the rawError parameter, but doesn't explicitly state exclusions or alternatives. It does provide clear context for when to use it (error explanation) and notes it works in demo mode without network calls, which may guide usage.

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

• generate_test_documentA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds 'Local only; works in demo mode' and 'Read-only or local operation', which provide extra context about execution environment and side effects. However, the phrase 'Read-only or local operation' is slightly ambiguous and doesn't add rich behavioral detail beyond what annotations already convey.

  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 primary action and parameters. Each sentence adds distinct information: first covers functionality and overrides, second covers execution constraints. 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 generator with good annotations and a clear schema, the description covers the essential aspects: what is generated, the document types, overrides, and local/demo nature. It does not detail return format, but this is not critical given the tool's simple purpose and the absence of an output schema. Overall, it is adequately complete for an AI agent.

  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 only 50%, with poNumber and controlNumber lacking descriptions. The description compensates by naming 'control number, PO, and date overrides', clarifying the purpose of these parameters. It also lists the document types for the 'type' parameter, reinforcing the enum values. This adds meaningful value beyond the schema.

  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 renders synthetic X12 samples for specific transaction types (850, 810, 856, 837) with optional overrides. This specific verb-resource pairing distinguishes it from sibling tools like parse_edi or validate_edi, making the purpose 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 provides context that this is a local, demo-mode operation, implying it is intended for testing and not production use. It does not explicitly name alternatives or state when not to use the tool, but the 'local only' and 'demo mode' clues give clear usage context.

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

• get_partner_kitA
  4.2/5.0
  Behavior4/5

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

  The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by disclosing an authentication requirement (platform API key) and clarifying that the operation is read-only or local, which goes beyond the annotation hints. It also gives a glimpse of the content (structured endpoints, webhook events, sample payloads) without contradicting 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-loads the primary purpose, and contains no fluff. Every sentence contributes essential information (what it does, where from, auth, safety), making it a model of conciseness.

  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 read operation with no output schema, the description covers the key usage aspects: what it fetches, the source catalog, auth requirement, and read-only nature. It does not detail the exact return shape or error behavior, but the mention of 'structured endpoints, webhook events, sample payloads' gives a reasonable picture. The schema fills in parameter details, so the tool is adequately specified for an agent to invoke.

  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%, and both parameters (kitId, partnerId) are described in the schema. The description only mentions kitId in prose ('by kitId'), but does not add meaning beyond the schema, such as when to use partnerId instead. Thus it meets the baseline for high schema coverage but adds little extra semantic 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 action: 'Fetch one API kit by kitId' from the /api/v1/kits catalog. It also specifies the resource scope (structured endpoints, webhook events, sample payloads) and differentiates from siblings like list_partner_kits by emphasizing a single kit retrieval.

  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 a prerequisite ('Requires a platform API key') and notes the operation is 'Read-only or local operation', providing clear context. While it does not explicitly say when to use this vs. list_partner_kits, the singular 'one API kit by kitId' implies a targeted fetch, which is sufficient for an agent to select it appropriately.

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

• list_partner_kitsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, and the description reinforces this with 'read-only or local operation.' It adds a meaningful auth requirement (platform-scoped API key) that is not in the annotations, though 'local operation' is somewhat ambiguous.

  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, consisting of two sentences that get straight to the point. It front-loads the core purpose and then adds necessary context without any 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 simple no-parameter list tool, the description covers the essential aspects: endpoint, content categories, auth, and safety. The phrase 'local operation' is unclear, but overall the description is sufficient for an agent to understand and invoke the 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 no parameters, so the description has nothing to add beyond the schema. The baseline for zero parameters is 4, and the description does not mislead or omit anything relevant.

  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 packaged SignalEDI API kits, naming specific categories and the endpoint. The verb 'list' distinguishes it from the sibling get_partner_kit, which implies fetching a single item.

  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 listing kits) but does not explicitly mention alternatives or when not to use it. The API key requirement is a constraint, not a usage guide relative to siblings.

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

• list_transactionsA
  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 destructiveHint=false. The description adds behavioral details: 'newest first' ordering, API key scoping, and the statement 'Read-only or local operation'. It also lists the fields returned, which helps the agent understand what to expect. No contradictions 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, front-loaded with the action, and each clause adds information: scope, ordering, returned fields, and safety. No filler or redundancy beyond the read-only note which aligns with annotations.

  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 list operation with one parameter and good annotations, the description provides sufficient context: scope, ordering, and row contents. It lacks pagination details beyond the limit parameter, but that's not critical for a basic list. The absence of an output schema is compensated by listing the fields, so it's adequately complete.

  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% for the single 'limit' parameter, with min/max and a note about server cap. The description does not add further parameter detail beyond what the schema provides, so baseline 3 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 uses the specific verb 'List' with a clear resource ('recent EDI transactions') and includes ordering and scope details ('newest first', 'scoped to the API key'). It distinguishes from sibling 'get_transaction' by indicating a list vs single transaction.

  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 clearly indicates this is for listing recent transactions with an API key scope, implying its use for browsing transaction history. It does not explicitly contrast with alternatives like get_transaction, but the context is clear. No exclusions or conditional guidance is provided, so it's a 4.

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

• quickbooks_export_to_ediA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds valuable context: dryRun preview behavior, mandatory confirm and idempotencyKey, and required OAuth scopes, which go beyond the 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 compact, front-loaded with the primary purpose, and includes critical usage notes in three sentences. Every sentence adds value and there is no redundant or filler content.

  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 complexity (8 parameters, no output schema), the description covers the main usage scenarios, prerequisites, and safety flags. It does not explain return values, but the schema descriptions for parameters are thorough, making the description sufficient for an agent to select and invoke the tool correctly.

  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 each parameter already has a description. The tool description adds cross-parameter constraints (e.g., partnerId required unless dryRun, confirm and idempotencyKey required) but does not add per-parameter semantics beyond the schema, aligning with baseline 3.

  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 specific action: 'Pull QuickBooks entities and emit them as outbound EDI to a trading partner.' It distinguishes from siblings by naming the EDI types (Invoice→810, PurchaseOrder→850) and the integration from QuickBooks.

  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 how to use the tool: dryRun for preview, partnerId requirement, required scopes, and confirm/idempotencyKey. It does not explicitly state when not to use it or mention alternatives, but the context is sufficient for an agent to decide.

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

• get_transactionA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this with 'Read-only or local operation' and adds the ownership constraint plus the range of returned data (timestamps, partner, error, SLA). This is useful behavioral context beyond the 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 sentence that is front-loaded with the action and resource, and every phrase adds value: scope, return contents, and read-only nature. No wasted 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 simple one-parameter read operation with strong annotations and no output schema, the description fully covers the return payload (lifecycle status fields), ownership constraint, and safety. It is sufficiently complete for an agent to select and 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?

  The schema covers the lone 'id' parameter at 100%, and the description's 'by id' adds no further detail about format or semantics. With full schema coverage, a baseline of 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 uses a specific verb 'Fetch', names the resource 'single EDI transaction', and includes the by-id scope. It clearly differentiates from list_transactions by specifying a single item rather than a collection.

  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 phrase 'you own by id' provides clear context that this is for fetching one specific, owned transaction. It does not explicitly state when to prefer list_transactions, but the single-item framing makes the intended use case obvious.

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

• quickbooks_sync_to_qboA
  4.4/5.0
  Behavior4/5

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

  Annotations already indicate destructive and idempotent behavior. The description adds the de-duplication behavior ('QBO creates are de-duplicated against prior successful syncs') and required scopes, which goes beyond the annotations. No contradictions found.

  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 three sentences, front-loaded with the primary action, and every sentence adds value. No fluff or repetition of schema details.

  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 selection modes, prerequisites, scopes, and de-duplication. No output schema exists, but the tool is a straightforward sync action. It lacks explicit error handling info, but the description is sufficient for an agent to invoke 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?

  Schema coverage is 100%, so baseline is 3. The description adds meaning by specifying the 'exactly one of' constraint among transactionId, transactionIds, and all, and the 50-item limit for transactionIds. This goes beyond the individual parameter descriptions in the schema.

  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: 'Push EDI transactions INTO QuickBooks Online' with specific transaction types (810 Invoice, 850 Bill, 835 Payment). It distinguishes from sibling tools like quickbooks_export_to_edi (which likely does the reverse direction) and send_outbound_document (which sends documents to trading partners).

  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 explicit usage context: 'Provide exactly one of: transactionId (one), transactionIds (up to 50), or all:true'. It also states required prerequisites (confirm:true, idempotencyKey) and scopes. It does not explicitly mention alternatives or when not to use, but the context is clear.

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

• send_outbound_documentA
  4.4/5.0
  Behavior5/5

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

  Beyond annotations (readOnly false, destructive true, idempotent true), the description adds SignalEDI serialization, async webhook acknowledgment, and the return of document id/status. These behavioral details are useful and not present in 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?

  Three concise sentences with front-loaded purpose, followed by behavioral details and requirements. No wordiness 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?

  Given complexity (7 params, nested payload, no output schema), the description covers serialization, delivery, async acknowledgment, scopes, and required flags. It doesn't elaborate on error cases or metadata echo, but the schema covers those, and no output schema exists to explain.

  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 parameters are well documented structurally. The description adds emphasis on confirm and idempotencyKey requirements but doesn't enrich the meaning of partnerId, documentTypeCode, or payload beyond the schema.

  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 'Send an outbound EDI document to a trading partner' with a specific verb and resource. It distinguishes itself from sibling parsing/validation tools by emphasizing the actual sending and serialization behavior.

  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 clear context with prerequisites: required scopes, confirm:true, and idempotencyKey. However, it doesn't explicitly mention alternatives or when not to use, though no direct sibling conflict exists.

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

• quickbooks_disconnectA
  4.5/5.0
  Behavior5/5

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

  The description goes well beyond the annotations by detailing the OAuth revocation, connection removal, irreversibility, and required scopes. It also explains the need for explicit confirmation and an idempotency key, providing substantial behavioral context that annotations alone do not convey.

  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 and front-loaded, with two sentences that immediately state the action and then provide essential behavioral and prerequisite details. Every sentence adds valuable information with no redundancy or filler.

  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 disconnect tool with two fully documented parameters and clear annotations, the description covers purpose, behavior, scope requirements, and confirmation requirements. No output schema is present, but the description does not need to explain return values for this action, making it complete for the given complexity.

  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%, and the description only reiterates the requirement for confirm:true and idempotencyKey without adding new semantic detail. It does not explain the purpose or format of the idempotencyKey beyond what the schema already provides, so the baseline of 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 the tool's action with a specific verb and resource: 'Disconnect QuickBooks Online for your workspace.' It also explains the mechanism ('revokes the OAuth grant at Intuit and removes the connection'), which distinguishes it from sibling tools like quickbooks_status or quickbooks_sync_to_qbo.

  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 the primary usage scenario (disconnecting QuickBooks) and provides prerequisites such as required scopes and the need for confirm:true and idempotencyKey. However, it does not explicitly mention when not to use the tool or compare it with alternatives, 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.

• quickbooks_list_entitiesA
  4.5/5.0
  Behavior5/5

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

  The description states 'Read-only or local operation' and 'Returns the QBO rows as-is (no tokens)' which adds meaningful context beyond the readOnlyHint annotation. It clarifies that no transformation or tokenization occurs, aligning with the sibling quickbooks_export_to_edi tool but explicitly distinguishing this tool from such transformations.

  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 action and scope, and no filler. Every phrase contributes to understanding the tool's purpose and 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 simple nature of the tool, full schema coverage, and readOnlyHint annotation, the description is sufficient. It explains what is returned, the entity options, and the read-only/local nature, making it complete for an agent to invoke correctly.

  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 input schema already provides 100% coverage with descriptions for both limit and entity, including enum values. The description's mention of entity types is redundant with the schema, and it adds no extra semantics for the limit parameter. 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 the tool lists QuickBooks entities and enumerates the specific entity types (Invoice, PurchaseOrder, Customer, Vendor, Item). This effectively differentiates it from sibling tools like list_transactions or get_transaction by focusing on entities for preview/mapping.

  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 phrase 'for preview/mapping' provides a clear use case, but does not explicitly mention when not to use it or name alternative tools. It gives enough contextual guidance for an agent to understand when this tool is appropriate.

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

• quickbooks_statusA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond these: 'No tokens are returned' and 'masked realm id' indicate sensitive data is protected, and 'local operation' suggests no side effects. This exceeds what annotations alone provide.

  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 front-loads the purpose and adds essential safety information. Every part is useful and no words are wasted.

  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, zero-parameter, read-only status tool with no output schema, the description fully covers what the agent needs to know: the return values, the read-only nature, and the lack of token exposure. There are no gaps.

  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 tool has zero parameters, which is the baseline 4 per rubric. There is nothing to clarify about parameter semantics, and the description does not need to compensate for any schema documentation gap.

  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 ('Get') and resource ('QuickBooks Online connection status'), and enumerates the exact return values (connected state, masked realm id, environment, last error). This clearly distinguishes it from siblings like quickbooks_disconnect or quickbooks_sync_to_qbo.

  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 clearly implies when to use this tool (to check QBO connection status) and notes it is read-only/local, but it does not explicitly exclude alternatives or mention when not to use it. Given the obvious purpose and sibling names, this is clear context without exclusions.

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