Server Quality Checklist

Tool Scores

• check_process_id_in_codelistB
  3.4/5.0
  Behavior3/5

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

  There are no annotations, so the description bears the disclosure burden. It does reveal a meaningful dependency (the environment variable) and implies a read-only validation behavior via 'check'. It does not state what happens if the code list directory is absent or whether the lookup is local only, leaving some behavioral uncertainty.

  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 compact sentences, with the main operation first and the environment prerequisite second. No filler 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?

  For a two-string-parameter validation tool with an output schema, the description covers the operation and a critical environment dependency. It lacks usage differentiation from sibling tools, but the core invocation context is present. The output schema handles the return-value details.

  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 explain the parameters. It does add the core semantic that scheme and value together form a Peppol process identifier, which is more than the schema provides. However, it does not define valid scheme formats, examples, or constraints, so its compensation is partial.

  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 names a specific operation (checking a (scheme, value) pair) and the resource (Peppol process identifier), so its purpose is clear. It does not explicitly compare itself with sibling codelist checks, but 'process identifier' narrows the resource enough to separate it from other check tools.

  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 prerequisite (EINVOICING_PEPPOL_CODELIST_DIR) and points to list_participant_id_schemes, but never states when to prefer this tool over siblings such as list_process_ids, check_document_type_id_in_codelist, or check_participant_id_scheme_in_codelist. No explicit when/when-not guidance is provided.

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

• list_participant_id_schemesA
  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 burden of behavioral disclosure. It usefully discloses that the tool depends on a local code list export and is not bundled with the package, which is significant context. However, it does not describe what happens if the environment variable is missing, whether the tool performs any network access, or how filtering via active_only behaves at runtime.

  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 front-loaded with the tool's purpose and then gives essential setup context. The second sentence is somewhat long but every part contributes necessary operational information, such as the environment variable requirement and the reason the data is not bundled. It is concise without losing important detail.

  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-only tool with one well-documented parameter and an output schema present, the description is largely complete. The main missing piece is behavior under missing environment variables or invalid local data, but the prerequisite is clearly stated, and the output schema covers return structure.

  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 single parameter active_only is fully documented in the input schema, including its default value and meaning. The description adds no extra parameter-level information beyond what the schema already provides, so the baseline score of 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 states a clear, specific action: 'List Peppol participant identifier (ICD) schemes from the OpenPeppol eDEC code list.' This identifies both the verb and the resource scope, and differentiates it from sibling tools like list_document_type_ids and list_process_ids by naming participant identifier schemes specifically.

  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 whenever an agent needs to list Peppol participant identifier schemes, and it provides an important precondition: the EINVOICING_PEPPOL_CODELIST_DIR environment variable must point to a local copy. However, it does not explicitly state when to prefer this tool over alternatives such as check_participant_id_scheme_in_codelist, nor does it mention any exclusion criteria.

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

• peppol_get_service_endpointA
  3.7/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses DNS resolution, SMP metadata fetching, the redirect behavior where redirect_url is set and endpoint_url is None, and the one-hop limitation with a spec reference. This gives valuable behavioral context, though it does not cover failure modes or error handling.

  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 purpose is front-loaded in the first sentence, and the second sentence provides dense but relevant behavioral detail. The description is compact and avoids filler, though the redirect explanation is somewhat long and could be split for clarity.

  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?

  With an output schema present and only three parameters, the description covers the key edge case (SMP redirect) and gives a spec reference. It lacks explicit differentiation from sibling DNS/lookup tools, but for a straightforward endpoint-fetch operation it is reasonably 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 description coverage is 100%, so the baseline is 3. The description adds some meaning around document_type_id as the key used for service metadata lookup, but identifier and environment are already sufficiently described in the input schema and receive no additional semantics here.

  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 opens with a specific verb and resource: 'Fetch the AS4 endpoint for a Peppol participant's document type.' This clearly identifies what the tool does and is distinct from sibling tools like resolve_peppol_dns or peppol_lookup_participant, though it does not explicitly name them.

  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?

  Usage context is implied: use this tool when you need the AS4 endpoint for a participant document type. The description explains the internal resolution flow but does not explicitly state when to prefer this over siblings like resolve_peppol_dns or peppol_lookup_participant, nor does it mention any exclusions.

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

• list_document_type_idsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral burden. It discloses the core read-only listing behavior and the required environment variable, but does not explain what happens if the variable is missing, whether results are complete or filtered, or any performance/authz considerations. The behavior is simple enough that the stated purpose and prerequisite provide adequate transparency for a listing 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?

  Two compact sentences with no filler. The first sentence states the tool's purpose immediately, and the second adds the only operational prerequisite. Every sentence earns its place.

  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 output schema exists, so return values are covered elsewhere. The single parameter is documented in the schema, and the description adds the environment-variable prerequisite and a pointer to a sibling tool for setup. The main gap is the absence of explicit usage comparison with sibling codelist tools, but this is minor for a simple enumeration 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 description coverage is 100%, and the sole parameter active_only is fully documented in the schema. The description adds no parameter-level meaning beyond the name, so the baseline score of 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 states a specific verb and resource: 'List Peppol document type identifiers from the OpenPeppol eDEC code list.' This clearly distinguishes it from siblings like list_participant_id_schemes (different code list) and check_document_type_id_in_codelist (enumerate vs check).

  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 a clear prerequisite (requires EINVOICING_PEPPOL_CODELIST_DIR) and points to list_participant_id_schemes for setup, which is useful context. However, it does not explicitly state when to use this tool versus alternatives, such as checking a single document type ID with check_document_type_id_in_codelist.

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

• list_process_idsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It accurately conveys a read-only listing behavior and the environment variable requirement, but it does not disclose failure modes, caching behavior, or what happens when the required directory is missing. The description is not misleading, but it leaves room for more 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?

  The description is only two sentences long, front-loaded with the primary purpose and followed by a necessary prerequisite. Every sentence earns its place; there is no filler or repetition.

  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 low complexity (one optional parameter, output schema present), the description is complete enough: it states the purpose, the data source, and the required environment variable. It could add a note about when this list is needed, but that gap is minor for such a simple read-only 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 input schema already provides a complete description of the only parameter (`active_only`), so the description does not need to add much. It does not mention `active_only` explicitly, but the schema covers it fully, earning the baseline score of 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 states a specific verb ('List'), a specific resource ('Peppol process identifiers'), and the source ('OpenPeppol eDEC code list'). This makes the tool's purpose immediately clear and distinguishes it from sibling tools that deal with other aspects of the Peppol directory.

  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 a clear prerequisite ('Requires EINVOICING_PEPPOL_CODELIST_DIR') and points to a sibling tool for reference. However, it does not explicitly state when to use this tool versus alternatives, nor does it give any exclusion criteria for when another tool would be more appropriate.

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

• peppol_lookup_participantA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It openly states the lookup sequence and defines the outcome: registration status plus supported document type identifiers. It does not explicitly say the operation is read-only, but the described behavior makes that apparent.

  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 tightly written sentences with the primary purpose front-loaded and the supporting technical process in the second sentence. There is no filler, and each sentence contributes meaningful information for tool selection and invocation.

  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 conveys the purpose, the lookup workflow, and what the agent can expect from the result. Since an output schema exists, return-value details do not need to be spelled out here. It could be slightly more complete with an explicit note about the production/test environment implications, but the schema already covers that.

  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 detailed descriptions for both parameters, including the identifier format and accepted environment values, so schema coverage is effectively 100%. The tool description adds no new parameter-level meaning beyond what the schema supplies, which matches the baseline score of 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 opens with a specific verb and resource: 'Check whether a business is registered on the Peppol network.' It then explains the two-step technical mechanism (DNS-over-HTTPS U-NAPTR lookup, then SMP service-group request), which clearly separates it from sibling tools like resolve_peppol_dns or peppol_directory_search.

  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 purpose implies when to use the tool: whenever an agent needs to verify a participant's registration status or supported document types. However, it provides no explicit guidance about when not to use it or which sibling tools to prefer for related lookups such as resolving endpoints or searching directories.

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

• check_document_type_id_in_codelistA
  4.1/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 and does a good job by disclosing a non-obvious behavior: it searches all entries regardless of state, so deprecated or removed document types are still reported as found. It also states the environment prerequisite, adding useful operational transparency.

  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 front-loaded: purpose first, then prerequisite, then behavioral nuance. Every sentence contributes essential information and no filler is present.

  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?

  An output schema exists, so the description does not need to explain return values. It covers the required environment dependency and the important deprecated-state behavior. The main gap is the thin parameter semantics, but the pointer to list_participant_id_schemes partially mitigates this.

  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 description coverage is 0%, and the description only refers to a '(scheme, value) pair' without explaining valid formats, allowed scheme identifiers, examples, or how the pair is matched. This leaves the agent without enough parameter-level guidance for correct invocation.

  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 ('Check whether') and names a precise resource: a (scheme, value) pair recognized as a Peppol document type identifier. This clearly differentiates it from sibling tools like check_process_id_in_codelist or check_participant_id_scheme_in_codelist by focusing on document type IDs.

  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 gives clear operational context: requires EINVOICING_PEPPOL_CODELIST_DIR and points to list_participant_id_schemes for related setup. It does not explicitly contrast with alternatives such as list_document_type_ids, but the purpose and scope make the appropriate use obvious enough.

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

• check_participant_id_scheme_in_codelistA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does disclose the environment-variable dependency, which is meaningful, and the check semantics imply a read-only operation. But it does not mention behavior on missing environment variables, invalid ICD formats, or whether the lookup is local vs. remote.

  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 with no filler. The purpose is front-loaded, and the prerequisite is stated in a separate sentence. Every element earns its place.

  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 output schema exists, return values do not need to be described. The description covers the input format, the purpose, and the required environment variable. It is slightly incomplete only in not addressing error/edge-case behavior, but for a simple predicate tool this is a minor gap.

  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?

  Schema coverage is 0%, so the description must fully explain the `icd` parameter. It does this well by specifying the 4-digit ISO 6523 format and giving an example ('0208'). This is exactly the semantic detail the schema lacks.

  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 ('Check') and a precise resource: a 4-digit ISO 6523 ICD code against the Peppol scheme codelist. The example '0208' removes ambiguity, and the focus on participant ID schemes distinguishes it from sibling codelist-checking tools.

  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 mentions the required EINVOICING_PEPPOL_CODELIST_DIR environment variable and points to list_participant_id_schemes, which is useful prerequisite guidance. However, it does not explicitly state when to prefer this tool over sibling check_document_type_id_in_codelist or check_process_id_in_codelist; the usage context is implied rather than stated.

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

• get_profile_urn_sgA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It explains the internal data sources: CustomizationID comes from the profile_registry, while ProfileID comes from a local constant. It also discloses the provenance and verification status of the guidance, which is more transparent than typical. It does not mention error cases or response format, but the output schema covers the latter.

  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 main purpose is front-loaded in the first sentence, and subsequent paragraphs add useful implementation and recommendation context. The third paragraph is slightly lengthy with caveats about verification status, but it still earns its place by preventing over-reliance on the recommendation. Overall it is well-structured and not bloated for the information it conveys.

  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 one-parameter lookup tool, the description covers the purpose, the source of each returned value, the recommended parameter choice, and the legacy alternative. An output schema exists, so return value details are not needed in the description. No important context for correctly invoking this tool is missing.

  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?

  Input schema coverage is 100%, so the parameter is already documented, giving a baseline of 3. The description adds meaning beyond the schema by explaining the implications of choosing PINT_SG versus BIS3 and the legacy positioning of BIS3. This enriches the bare enum-like parameter description with decision-relevant semantics.

  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 opens with a specific verb and resource: 'Return the CustomizationID (BT-24) and ProfileID (BT-23) for a Singapore profile.' This clearly identifies what the tool does. It does not explicitly differentiate from sibling tools, but the unique output fields and Singapore scope make the purpose unambiguous.

  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 concrete guidance on which parameter value to choose: 'PINT_SG is the recommended profile for new senders' while BIS3 is 'positioned as legacy.' It also clarifies that this is not enforced as a hard default, so callers must choose explicitly. It does not discuss when to use this tool versus sibling tools, but for a parameter-driven lookup the profile recommendation is the key usage context.

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

• list_spis_use_case_idsA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It discloses the environment requirement and implies a local read-only codelist lookup, but it does not describe side effects, output shape, or how entries are filtered beyond the schema. For a simple list tool, this is adequate but not rich.

  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 compact sentences: the first states the purpose, the second gives the necessary prerequisite. There is no filler or repetition of schema content.

  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 single-optional-parameter listing tool with an output schema, the description covers the essential context: what is listed, from which code list, and what environment setup is needed. Return-value details are already handled by the output schema.

  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 single parameter has 100% schema description coverage, so the schema already documents active_only and its behavior. The description adds no parameter-level detail, 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 names a specific verb ('List') and resource ('Peppol SPIS use case identifiers from the OpenPeppol eDEC code list'), which clearly distinguishes it from sibling codelist-listing tools. It is concrete, not a tautology, and states exactly what the tool returns.

  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 states a concrete prerequisite (EINVOICING_PEPOL_CODELIST_DIR) and directs the agent to a sibling tool for setup, giving practical usage context. It does not explicitly contrast with alternatives, but the resource-specific purpose makes when-to-use apparent.

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

• peppol_sendA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It goes beyond a simple verb by describing the pipeline: SMP endpoint lookup, ebMS3/AS4 envelope construction, and transmission using signing credentials. This gives the agent a meaningful model of the operation, though it does not discuss failure modes or side effects in production.

  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 concise sentences that front-load the primary purpose and then provide the essential process steps. Every clause adds useful information, and there is 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?

  Given the 8 parameters, 100% schema coverage, and an output schema, the description is largely complete. It explains the transmission workflow and references signing credentials, which aligns with the certificate and key parameters. It could add a note about production versus test impact, but the schema already covers the environment 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?

  Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description does not add parameter-level detail, but it does not need to; the baseline of 3 applies because the schema carries the semantic weight.

  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 action ('Send'), a specific resource ('UBL/CII invoice'), and a specific target ('Peppol participant via AS4'). This clearly distinguishes it from the sibling tools, which are lookup, validation, and generation tools rather than transmission 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 makes the use case clear: use this tool when you need to transmit an invoice to a Peppol participant. It does not explicitly name alternatives or state when not to use it, but the contrast with siblings like generate_invoice_sg and validate_invoice_sg is implicit and sufficiently obvious.

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

• resolve_peppol_dnsA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly reveals the tool's scope boundary — DNS-only U-NAPTR lookup, deliberately not fetching the SMP service group — which is the key behavioral trait distinguishing it from sibling tools. It does not explicitly state read-only/no-side-effect behavior or failure modes, but the core boundary is well disclosed.

  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 tight paragraphs, four sentences, no waste. The one-line summary is front-loaded with the verb and resource, and the second paragraph adds the technical mechanism plus the diagnostic use case. Every sentence earns its place.

  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 2-parameter diagnostic tool with a 100%-covered schema and an output schema present, the description is largely complete: it covers purpose, mechanism, scope boundary, and when to use it. The only notable gap is behavior on failure — e.g., what happens when a participant is not registered in the SML (e.g., DNS NXDOMAIN) — which would add further practical value.

  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 the schema fully documents both parameters: identifier ('Peppol participant ID or adaptable national identifier') and environment ('production' or 'test'). The description adds useful domain context (SML, U-NAPTR) but no parameter-level 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 states a specific verb and resource: 'Resolve the SMP hostname for a Peppol participant via DNS only.' It further differentiates itself from siblings like peppol_lookup_participant and peppol_get_service_endpoint by explicitly scoping the operation to 'the raw U-NAPTR (SML) lookup without fetching the SMP service group.' An agent can immediately tell what this tool does and how it differs from the fuller lookup siblings.

  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 clear usage context: 'useful for diagnosing whether a participant is registered in the SML independently of SMP reachability.' This tells an agent exactly when this tool is the right choice. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion guidance.

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

• get_peppol_codelist_versionA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden. The verb 'Report' and the qualifier 'locally' make clear this is a non-mutating, local configuration read, which effectively communicates the main behavioral trait. It does not elaborate on potential side effects, but none are implied for this simple query.

  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, tightly worded sentence with no filler. It front-loads the action and object, then adds the key scope qualifier 'currently configured locally'.

  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 zero parameters, no annotations, and the presence of an output schema, the description fully covers what an agent needs to invoke the tool correctly. It states what is reported and where the configuration is read from, 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.

  Parameters4/5

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

  This tool has zero parameters, so there is nothing for the description to add beyond the schema. The absence of parameter detail is appropriate, and the description correctly implies an unparameterized invocation.

  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 ('Report') and a clearly defined object ('OpenPeppol eDEC code list release version(s) currently configured locally'). It distinctly identifies this as a version-inspection tool, differentiating it from sibling tools that check memberships or list code values.

  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 'currently configured locally' implies this tool is for inspecting local OpenPeppol configurations, which is useful context. However, there is no explicit guidance on when to choose this tool over alternatives or when it is not appropriate, leaving usage mostly to inference.

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

• get_gst_category_codes_sgA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It discloses the source IRAS e-Tax Guide, explicitly scopes the code list, and explains that `rate` is null for categories with no fixed rate, which adds real behavioral detail beyond the tool name.

  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 with each sentence earning its place: the first states the core purpose, the second provides source and scope, and the third clarifies null behavior. It is front-loaded and compact with no fluff.

  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 zero-parameter lookup with no annotations and an existing output schema, the description fully covers necessary context: source, scope, and a key return-value edge case. Nothing critical is missing for an agent to invoke this tool correctly.

  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 and the input schema is empty, so the schema coverage is effectively complete. The description correctly adds no unnecessary parameter information, meeting the baseline for a parameterless tool.

  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 names a specific action ('Return') and resource ('IRAS GST category codes accepted on Singapore invoices'), making the tool's purpose unambiguous. It also distinguishes this from sibling codelist tools by specifying the exact tax category codes and the Singapore invoice context.

  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 for use by stating the source is the supply/output-tax side only and explicitly excludes purchase-side codes for sent invoices. It does not name an alternative tool for purchase-side codes, but the exclusion still provides useful guidance.

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

• peppol_directory_searchA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It clearly discloses that the operation is public, unauthenticated, and search-only, and clarifies that it is unrelated to SMP lookup. It doesn't discuss response size or error behavior, but the presence of an output schema reduces the need for describing return values.

  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 tight sentences with no filler. The core action is front-loaded, followed by the access mode, the SMP lookup caveat, and the required parameter constraint. Every sentence earns its place.

  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 full schema descriptions and the presence of an output schema, the description is sufficiently complete. It specifies the search scope, access characteristics, a key non-relation to SMP lookup, and the mandatory parameter condition, which is all an agent needs to invoke the tool correctly.

  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?

  All 8 parameters already have detailed schema descriptions, so the baseline is 3. The description adds valuable cross-parameter meaning by stating that at least one of q/participant/name/country/doctype must be supplied, which the schema alone does not express since required is empty.

  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 and resource: 'Search the Peppol Directory for registered participants.' It immediately distinguishes itself from SMP lookup with 'no relation to SMP lookup', which is important given sibling tools like peppol_lookup_participant and resolve_peppol_dns.

  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 states that this is a public, unauthenticated search and explicitly excludes SMP lookup, providing useful routing context. It also gives a concrete precondition by listing which parameters must be supplied. It does not name alternative sibling tools directly, but the exclusion is clear enough.

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

• validate_invoice_sgA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full transparency burden. It discloses the tool's limited validation depth, a concrete rejection example (missing buyer/seller UEN), the non-included rulesets, a warning that will appear in results, the rationale, and the optional xslt2 dependency.

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

  Conciseness3/5

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

  The description is purpose-first and separated into clear blocks, but the second paragraph becomes dense with implementation references such as validators/schematron.py, a roadmap file, and a ticket ID. These details add noise for an agent whose main job is selecting and invoking the tool correctly.

  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 a single required parameter, no annotations, and an available output schema, the description supplies everything needed: input format, validation target, limitations, expected warning behavior, and installation prerequisite. The agent can call the tool without needing further clarification.

  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 single xml parameter is already documented as the UBL 2.1 XML invoice content to validate. The tool description adds surrounding context but no material parameter-level meaning beyond what the schema already provides.

  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 first sentence states a specific verb and resource: validate a UBL 2.1 XML invoice against IRAS's C5 acceptance-layer Schematron. It is further differentiated from sibling tools by naming the exact ruleset scope and what is not included.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use the tool (for C5 acceptance-layer checks) and, more importantly, when not to rely on it for full compliance by listing the EN16931 base ruleset, PINT-SG overlay, and SG Peppol BIS Billing 3.0 as not checked. It also directs the caller to the EN16931-BASE-UNAVAILABLE warning in the result.

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

• generate_invoice_sgA
  5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden. It discloses the output shape (UBL XML string plus customization_id/profile_id), the TX2_Annex Annex B matched-pair requirement, and the important boundary that Schematron validation is not performed. This is strong behavioral transparency beyond the 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 three compact paragraphs with no filler. The first sentence states the core purpose, the second handles profile-selection semantics, and the third covers return values and the validation boundary. Every sentence earns its place.

  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 one complex structured parameter and an output schema, the description covers input semantics, profile selection rules, return format, and the downstream validation step. It gives an agent everything needed to call the tool correctly and know what to do next.

  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 schema coverage is 100%, the description adds crucial meaning beyond the generic invoice_data schema. It identifies invoice_data['profile'] as CustomizationID and invoice_data['business_process'] as ProfileID, explains that they select PINT-SG or SG Peppol BIS Billing 3.0, and requires them to be a matched pair. This materially helps an agent construct valid input.

  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 pair: 'Build an SGInvoice from structured data and serialize it to UBL 2.1 XML.' It clearly distinguishes itself from the sibling validate_invoice_sg by explicitly stating that it does not validate against Schematron, and from get_profile_urn_sg by directing the agent there for profile lookup.

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

  Usage Guidelines5/5

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

  The description gives explicit routing guidance: use get_profile_urn_sg to look up both customization_id and profile_id together, and call validate_invoice_sg on the returned XML for Schematron validation. It also explains the matched-pair constraint, which tells the agent when not to set profile values independently.

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