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?

  No annotations exist, so the description carries the burden. It discloses an environment-variable dependency and makes the check semantics clear. It does not describe failure behavior or side effects, though 'Check' implies a read-only 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 short sentences with no filler. The core purpose is front-loaded and the prerequisite is placed in a separate necessary sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a simple boolean codelist check and an output schema exists, so return structure need not be described. However, missing usage guidance and parameter-level detail leave the description merely minimally viable rather than complete.

  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 tells the agent the pair is for a Peppol process identifier. It does not explain valid scheme/value formats, examples, or point to list_process_ids for possible values, so parameter semantics remain under-specified.

  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?

  States a specific operation: check whether a (scheme, value) pair is a recognized Peppol process identifier. It separates itself from sibling codelist checks by naming process identifier distinctly.

  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?

  Provides a prerequisite (EINVOICING_PEPOL_CODELIST_DIR) but no explicit when-to-use guidance or comparison with sibling tools such as list_process_ids or check_document_type_id_in_codelist. The agent must infer usage from the tool name and first sentence.

  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?

  No annotations are present, so the description must carry behavioral weight. It discloses the environment-var requirement and the read-only nature implied by 'List', but it doesn't explicitly state side-effect safety, failure behavior without the env var, or any sorting/filtering behavior beyond what the schema already covers.

  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 short sentences with the purpose first and a one-line prerequisite second. No redundant explanation 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?

  For a simple list tool with one optional parameter and a present output schema, the description covers what is listed and the required setup. It doesn't address when-to-use selection, but that gap is handled under usage guidelines; nothing critical is missing for calling 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?

  Schema description coverage is 100%: the only parameter, active_only, is fully described in the input schema with its default and meaning. The description adds no extra parameter context, so the 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 names a specific verb (List), the exact resource (Peppol document type identifiers), and the source (OpenPeppol eDEC code list). This clearly distinguishes it from sibling tools like list_participant_id_schemes and list_process_ids.

  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 operational prerequisite (EINVOICING_PEPPOL_CODELIST_DIR) and points to list_participant_id_schemes for setup, but it never explicitly states when to choose this tool over sibling list tools or when not to use it. Usage context is only implied by the tool name and resource type.

  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 provided, the description must carry behavioral disclosure. It does reveal an environment-variable requirement and the 'List' verb implies a read-only operation, which is useful. It does not describe what happens if the environment variable is missing or whether entries are sorted/paginated, but the output schema covers return structure.

  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 concise sentences: the first states the core purpose, the second gives the required setup with a pointer to a sibling tool. No wasted words and the most important information is front-loaded.

  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 optional parameter and an output schema, the description is adequately complete. It identifies the source data, the required environment variable, and how to find setup guidance. It does not mention alternative tools for process-ID checks, but that is more relevant to usage guidelines than completeness for invoking this 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%, so the existing schema already documents the active_only parameter. The tool description adds no additional meaning about parameter behavior beyond what the schema 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 ('List') and resource ('Peppol process identifiers') and names the exact source code list ('OpenPeppol eDEC code list'). This clearly distinguishes it from sibling tools like check_process_id_in_codelist or list_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 Guidelines3/5

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

  The description gives a practical prerequisite (EINVOICING_PEPPOL_CODELIST_DIR) and points to list_participant_id_schemes for setup, which implies the intended context. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.

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

• get_peppol_codelist_versionA
  3.9/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 explaining behavior. 'Report' clearly signals a non-mutating query, and 'currently configured locally' clarifies scope. It does not discuss side effects or edge cases, but the tool takes no parameters and appears to be a straightforward read 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?

  A single sentence that immediately states the action, subject, and scope. There is no redundant wording, and the key fact ('currently configured locally') is placed prominently.

  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 zero-parameter informational tool with an output schema present, the description is largely complete. It could briefly mention that this is a local/read-only check or clarify why the version matters, but the core information needed to invoke the tool correctly is present.

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

  Parameters4/5

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

  The input schema has zero parameters, so the description does not need to explain parameter meaning. The baseline for zero-parameter tools is 4, and the description adds appropriate context about what is being reported without needing to compensate for undocumented parameters.

  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 identifies the verb 'Report' and the resource 'OpenPeppol eDEC code list release version(s) currently configured locally.' It is specific enough to distinguish this from the sibling check/list operations, though it does not explicitly contrast itself with any sibling.

  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 the tool is appropriate when an agent needs to know which code list version is installed locally. However, it provides no explicit when-to-use guidance or exclusions relative to sibling codelist tools.

  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/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 and does add one key behavioral fact: the tool depends on EINVOICING_PEPPOL_CODELIST_DIR being set. It also implies a non-destructive verification operation consistent with the 'check' semantics. It does not disclose failure behavior (e.g., missing env var, malformed input) or caching, though the output schema covers the return shape.

  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 totaling roughly 25 words, with the purpose front-loaded in the first sentence and the prerequisite in the second. There is no redundancy or filler; every phrase 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 single-parameter check tool with an output schema and no annotations, the description covers the purpose, the input format, and the one environmental dependency, and it routes the agent to a sibling for the full list. The only omissions — error behavior and explicit return phrasing — are minor because the output schema already exists.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate for the undocumented `icd` parameter — and it does: '4-digit ISO 6523 ICD code' specifies format and digit count, and the example '0208' clarifies the leading-zero convention. This fully covers the single parameter's semantics; only marginal details like exact matching behavior are omitted.

  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 predicate ('Check whether'), a precise resource (4-digit ISO 6523 ICD code), and a concrete example ('0208') to identify the subject as a recognized Peppol scheme. This clearly differentiates it from the sibling codelist checks (check_document_type_id_in_codelist, check_process_id_in_codelist) by naming the exact code type being validated.

  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 states a prerequisite ('Requires EINVOICING_PEPPOL_CODELIST_DIR') and references list_participant_id_schemes for context, which gives useful operational guidance. However, it never explicitly says when to use this tool over the sibling codelist checks or gives when-not-to-use conditions; usage context must be inferred from the name and subject matter.

  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
  4/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 behavioral disclosure burden. It clearly discloses an important environmental dependency: a local copy of the eDEC GeneriCode export must exist and EINVOICING_PEPPOL_CODELIST_DIR must point to it. It also notes the data is not bundled and points to a module docstring for further details, which is genuinely informative beyond a trivial 'list' statement.

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

  Conciseness5/5

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

  The description is compact and well-structured: the main purpose appears first, followed by the crucial configuration requirement. The second paragraph is dense but each clause earns its place, especially the pointer to the module docstring for setup instructions. There is no redundant filler or repetition of schema 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?

  For a read-only list tool with an output schema and one optional parameter, the description is largely complete: it states the data source, the required environment variable, the non-bundled nature, and where to find more details. It does not explicitly describe failure behavior if the env var is unset, but the dependency is clearly surfaced and the module docstring pointer covers deeper setup context.

  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 fully covers the single optional parameter active_only, including its default and semantics. Since schema description coverage is 100%, the description does not need to re-explain the parameter. The baseline of 3 applies because the schema is doing the heavy lifting and the description adds no supplemental parameter detail.

  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 ('List') and a precise resource ('Peppol participant identifier (ICD) schemes from the OpenPeppol eDEC code list'). This clearly separates it from sibling tools like list_document_type_ids and list_process_ids, and from the check_* tools that test membership rather than enumerate entries.

  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: whenever a consumer needs to enumerate Peppol participant identifier schemes. However, it does not explicitly discuss when to prefer an alternative, such as check_participant_id_scheme_in_codelist, nor does it mention exclusions or related tools. The prerequisite about EINVOICING_PEPPOL_CODELIST_DIR is useful but not a usage-vs-alternative guideline.

  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/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 usefully exposes a required environment variable and the authoritative data source, which are not visible elsewhere. It does not spell out the failure mode if the directory is missing, but the operation is a low-risk list and the name implies read-only behavior.

  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, no filler. The first sentence states the core purpose immediately; the second sentence provides a necessary operational prerequisite. Both sentences earn their 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 simple one-parameter list tool with an output schema available, the description is nearly complete: it names the source, states the environment dependency, and routes the agent to a sibling for the directory context. It could add a note about read-only side effects, but nothing critical is missing for calling it 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 only parameter, active_only, is fully documented in the schema including its default and meaning, so the description does not need to repeat it. The tool description adds no parameter-level information, and with 100% schema coverage 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 first sentence states a specific action ('List'), a specific resource ('Peppol SPIS use case identifiers'), and the source list ('OpenPeppol eDEC code list'). It is easily distinguished from sibling tools like list_document_type_ids and list_process_ids because it names a different kind of identifier.

  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 gives a clear prerequisite by requiring EINVOICING_PEPOL_CODELIST_DIR and points to a related sibling for context. However, it never explicitly states when to choose this tool over the other list_* siblings or when not to use it.

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

• peppol_lookup_participantA
  4/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 behavioral disclosure burden. It clearly states that the tool performs a DNS-over-HTTPs U-NAPTPR lookup followed by an SMP service-group request, revealing the network-dependent and multi-step nature of the operation. It does not discuss failure modes, rate limits, or whether the operation is strictly read-only, but the word 'lookup' and the described flow strongly imply a safe read operation.

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

  Conciseness5/5

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

  The description is two sentences with no wasted words. The primary purpose is front-loaded, and the second sentence adds precise technical context about the lookup mechanism and expected result. Every part contributes to understanding what the tool does.

  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 that an output schema exists, the description does not need to explain return values in detail. It covers the essence of the operation, the protocol steps, and the result type. It could still be more complete by noting network reliability implications or how the 'environment' parameter affects the lookup, but it is sufficient for correct invocation in most cases.

  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 (identifier and environment) are already documented in the input schema. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline score 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 ('Check') and a specific resource ('whether a business is registered on the Peppol network'), then explains the underlying mechanism and the concrete outcome: registration status and supported document type identifiers. This clearly separates it from siblings like resolve_peppol_dns or peppol_get_service_endpoint, even without naming 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?

  The description implies when to use the tool: when you need to determine if a participant is registered on Peppol and what document types they support. However, it does not state explicit exclusions or mention sibling alternatives such as resolve_peppol_dns or peppol_directory_search, which would help an agent with tool selection.

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

• peppol_sendA
  4/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 behavioral burden. It discloses that the tool performs a multi-step outbound transmission: looks up the recipient's AS4 endpoint, builds the envelope, and sends it using signing credentials. This is meaningful behavioral detail beyond the name and schema, though it does not warn about irreversibility or production-environment consequences.

  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: a single leading sentence names the action, followed by one sentence explaining the pipeline. No filler or repetition of schema field names, and the most important information is front-loaded.

  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?

  Together with a fully self-describing schema and an output schema, the description provides enough for an agent to invoke the tool correctly: what it sends, to whom, via what protocol, and with which credentials. Minor gaps are the lack of explicit guidance on validation-before-send and any caution about production sends, but these are not essential to correct 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?

  Since schema description coverage is 100%, the schema already documents all eight parameters, including the distinction between test and production environments and the optional private key password. The description adds no parameter-level semantics, but it does not need to because the schema is complete.

  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 ('Send') with a clear resource ('UBL/CII invoice to a Peppol participant via AS4') and outlines the mechanism (SMP lookup, ebMS3/AS4 envelope). This clearly distinguishes it from sibling tools that validate, parse, or look up participants.

  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 a UBL/CII invoice needs to be sent to a Peppol participant. However, it does not explicitly say when not to use it, mention prerequisites such as prior validation, or contrast with alternatives like validate_invoice_ae or peppol_lookup_participant. Usage context is present but not explicit.

  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.2/5.0
  Behavior4/5

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

  With no annotations present, the description carries the behavioral disclosure burden. It explicitly states that 'Searches all entries regardless of state' and that deprecated/removed entries are still reported as found, which is a valuable non-obvious behavior. It also discloses the environment requirement, though it does not mention whether the operation has any side effects (which 'check' broadly implies as read-only).

  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 well-structured: a one-sentence core purpose, a necessary prerequisite, and an important behavioral caveat. Every sentence earns its place and the main action is front-loaded.

  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, two parameters, and an existing output schema, the description covers the essential behavioral and prerequisite context. It could be slightly more complete by pointing to sibling enumeration tools for known schemes/values, but nothing critical is missing for calling 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?

  The schema has no descriptions for `scheme` or `value`, so the description must compensate. It clarifies that the two parameters form a (scheme, value) pair identifying a Peppol document type, but it does not explain accepted scheme formats, value syntax, or allowed examples. This is sufficient but not rich.

  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 (scheme, value) pair is a recognized Peppol document type identifier.' This clearly distinguishes it from sibling codelist-checking tools, which target process IDs and participant ID schemes rather than 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?

  The description gives clear context for when to use this tool: to verify a single document type identifier pair. It also notes an environmental prerequisite and references list_participant_id_schemes, though it does not explicitly contrast with list_document_type_ids or the other check_*_in_codelist tools.

  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
  4.2/5.0
  Behavior5/5

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

  With no annotations, the description carries full behavioral burden and delivers. It discloses the two-step resolution process (DNS -> service metadata), the redirect edge case (redirect_url set, endpoint_url None), and the one-hop limit with a spec citation. This goes far beyond a generic fetch description and preempts the most likely failure mode.

  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 sentences, front-loaded with the core action, then the process, then the critical edge case. Every sentence earns its place, and the spec citation is compact. 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?

  An output schema is present, so return values are largely covered, and the description usefully highlights the redirect behavior with endpoint_url/redirect_url. The only gap is explicit guidance on when to use this tool over siblings, but the purpose alone covers most of that. For a single-purpose lookup tool, this is nearly 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 no significant parameter meaning beyond what the schema provides; it mentions document_type_id only in passing. It does not explain identifier format or environment specifics, but those are already described 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?

  Opens with a specific verb+resource pair: 'Fetch the AS4 endpoint for a Peppol participant's document type.' This clearly distinguishes it from siblings like resolve_peppol_dns and peppol_lookup_participant, which focus on DNS resolution or participant data. The reference to document_type_id further narrows scope.

  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 statement implicitly tells an agent when to use this tool: whenever the AS4 endpoint for a participant's document type is needed. However, it does not explicitly mention alternatives or give exclusion criteria, relying on the name and sibling list for disambiguation. Only implied usage guidance, not explicit routing.

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

• validate_tdd_aeA
  4.2/5.0
  Behavior5/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, and it clearly discloses the non-obvious trait that this tool always returns an explicit 'unavailable' result. This prevents an agent from expecting a real validation outcome and gives the reason why. There is no annotation contradiction.

  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 purpose, and immediately warns about the stub behavior. Every sentence earns its place and there is no 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?

  For a one-parameter tool with full schema coverage and an output schema, the description provides the essential behavioral context: it always returns unavailable. It does not mention sibling validate_invoice_ae for comparative routing, but nothing about how to invoke the tool or what outcome to expect is missing.

  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 already fully describes the single xml parameter as 'Raw Peppol AE Tax Data Document (TDD) XML content' at 100% coverage. The description's 'Raw' and TDD wording adds no meaningful semantics beyond the schema, so the 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 names a specific operation and resource: validating a Peppol AE Tax Data Document (TDD), which is distinct from the sibling validate_invoice_ae. The second sentence clarifies the actual available behavior (always returns unavailable), so there is no ambiguity about what the tool is for.

  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 does not explicitly state when to use this tool instead of alternatives, nor does it name validate_invoice_ae as the route for Peppol invoice validation. However, the explicit note that no TDD validation is currently available implies an agent should not expect real validation from this tool, which is an implicit usage signal.

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

• generate_invoice_aeA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries full disclosure burden. It goes well beyond a basic statement by specifically describing the output dict keys, the IDs applied, and the mandatory UBL elements emitted. It does not cover error handling or validation failure behavior, but provides strong insight into the tool's transformation behavior.

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

  Conciseness5/5

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

  The description is well-structured and efficient. It front-loads the core purpose, then adds meaningful technical details, and ends with a clear bulleted return contract. Every sentence contributes useful information without repetition 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?

  For a tool with two parameters, full schema coverage, and an explicit output dict description, the description is sufficiently complete. It tells the agent what the generated document contains and what the tool returns. It could mention validation of the input data before generation, but the receipt is minor given the provided schema and output description.

  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 value by explaining that variant drives the selected CustomizationID/ProfileID and that invoice_data should match the AEInvoice schema, including a specific nested field (AEParty.trade_license_number). This clarifies how the parameters relate to the generated XML.

  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?

  States the specific action 'generate', the artifact 'PINT AE UBL 2.1 e-invoice XML document', and the input 'structured data'. It also names the key distinguishing behaviors — applying CustomizationID (BT-24) and ProfileID (BT-23) — which separates it from sibling parse/validate 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?

  Clear context: use this tool when structured invoice data must be turned into a PINT AE UBL XML. It explains the variant selects billing vs selfbilling profiles, giving practical usage direction. It does not explicitly state when not to use it versus parse or validate, but the generation purpose is unambiguous.

  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, the description carries the behavioral burden and does disclose that the search is public, unauthenticated, unrelated to SMP lookup, and requires at least one search filter. It does not cover pagination/rate-limit details, but the output schema covers return structure.

  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-loads the core action, and every clause adds useful context: scope, authentication, relationship to SMP, and input requirements. 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 an 8-parameter search tool with a full output schema and 100% schema coverage, the description supplies the missing preconditions and scoping: public access, directory-resource, no SMP relation, and the minimum filter requirement. An agent can call the tool correctly without further inference.

  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 description adds value mainly by declaring that at least one of q, participant, name, country, doctype must be supplied, which is not visible in the schema's required array. That is a meaningful invariant beyond the parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource: 'Search the Peppol Directory for registered participants.' It also distinguishes itself from related operations by explicitly saying this is not SMP lookup, which separates it from siblings like peppol_lookup_participant.

  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?

  Clearly identifies public, unauthenticated use and gives an explicit 'no relation to SMP lookup' exclusion, but does not name the alternative tools to use for SMP lookup. It also specifies the minimum filter condition, which is practical guidance.

  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.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 disclosure burden. It clearly states what the tool does ('raw U-NAPTR (SML) lookup'), what it does not do ('without fetching the SMP service group'), and what it is useful for, leaving little ambiguity about side effects or scope.

  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: the core action appears in the first line, followed by one tightly scoped sentence that explains the technical behavior and diagnostic value. Every clause contributes useful information and no filler is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's modest complexity, complete parameter schema, and presence of an output schema, the description fully covers what an agent needs: the exact lookup mechanism, the boundary to SMP fetching, and the diagnostic use case. Nothing critical is missing.

  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%, so the input schema already explains both 'identifier' and 'environment' fully. The description reinforces the identifier as a PePPol participant ID but does not add meaning beyond the schema, so the baseline score 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 and resource: 'Resolve the SMP hostname for a Peppol participant via DNS only.' It also clarifies it performs a raw U-NAPTR (SML) lookup without fetching the SMP service group, which separates it from sibling lookup and service-endpoint 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 gives a clear use case: diagnosing whether a participant is registered in the SML independently of SMP reachability. It does not explicitly name alternatives or say when not to use it, but the 'without fetching the SMP service group' wording strongly implies the intended narrow diagnostic scenario.

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

• parse_invoice_aeA
  4.7/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 and does so thoroughly. It discloses that the tool extracts EN 16931 fields plus AE extensions, re-validates as an AEInvoice, re-checks TRN format and tax-rate/category consistency, and returns a structured success/failure envelope.

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

  Conciseness5/5

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

  The description is well-structured and front-loaded: purpose, accepted input scope, behavioral detail, then return format. Each sentence adds distinct information with no filler or redundancy.

  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-parameter parse tool with an output schema and no annotations, the description is complete. It covers accepted document types, extracted fields, validation behavior, and the exact success/error response shape, leaving no operational gap for an agent choosing or calling 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?

  Schema coverage is 100% for the single xml_content parameter, so the baseline is 3. The description adds valuable semantic detail beyond the schema by specifying that billing and self-billing documents are accepted and that both Invoice and CreditNote roots are valid, which helps the agent understand what content to pass.

  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 opening sentence states a specific verb and resource: parse a PINT AE UBL 2.1 XML invoice into a structured dict. The description further distinguishes this from sibling generate/validate tools by clarifying it extracts fields and re-validates parsed content, leaving no ambiguity about its role.

  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 acceptable inputs: PINT AE billing or self-billing UBL 2.1 documents with Invoice or CreditNote roots. It does not explicitly name alternatives or state when not to use the tool, but the accepted-input scope and parse-focused behavior make the usage context clear.

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

• validate_invoice_aeA
  4.7/5.0
  Behavior5/5

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

  Annotations are absent, so the description carries the full burden, and it does an excellent job: it discloses exact scope metadata values, constant warnings, expected BR-CO-09 behavior on genuine AE invoices, known limitations with UAE TRNs, and the fact that the variant parameter does not change execution. This is far beyond what the input schema reveals.

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

  Conciseness5/5

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

  The description is long but every sentence earns its place: purpose, scope limitation, expected warnings, known limitation, conformance caveat, artifact reference, return behavior, and variant semantics are all packed tightly. The most important scoping information appears early, and there is no 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?

  Given the tool's complexity and that an output schema exists, the description is complete: it explains exactly what validation is performed, what is excluded, what warnings are always included, why a known rule fires, and how the variant parameter behaves. An agent has enough context to invoke the tool and interpret its scope 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?

  Schema coverage is 100%, so the parameters are already well documented; the description adds genuine value by revealing that the variant parameter exists only for interface stability and does not affect which rules run. This is useful semantic detail not inferable from the schema enum alone.

  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: 'Validate a PINT AE UBL 2.1 invoice against the CEN EN16931 base Schematron.' It also actively differentiates itself from sibling validation tools by stating what it does NOT check and that it is not a full PINT AE conformance check, so an agent can distinguish it from validate_tdd_ae and related 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 gives strong when-to-use and when-not-to-use context: it explicitly says this tool covers only the CEN EN16931 base rules, excludes the PINT-AE jurisdiction overlay, and warns that passing documents may still be rejected by a real Peppol Access Point. It does not explicitly name an alternative tool for full conformance checking, which keeps it from a 5.

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