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 adds useful context: the search includes deprecated/removed entries and requires a dedicated environment variable. However, it does not disclose the return shape (e.g., boolean), error behavior, or performance characteristics, so transparency is partial.

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

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

The description is two sentences with no filler. The core purpose is the first clause, followed by a prerequisite and a behavioral nuance. Every sentence earns its place, and the structure is conventionally front-loaded.

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

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

For a simple two-parameter existence check, the description covers the essential semantics, an environmental prerequisite, and a non-obvious behavioral detail. Yet because there is no output schema and no annotation, the description still omits the exact return format and error conditions, which are the kind of details an agent would need to invoke it correctly in a broader workflow.

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

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 the pair as '(scheme, value)' without explaining each parameter's format, allowed values, or relationship. An agent can infer that scheme is the identifier scheme and value is an ID, but the description does not compensate for the absence of any property descriptions in the schema.

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

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 clear resource ('Peppol document type identifier') against a codelist, which immediately distinguishes it from sibling check_* tools such as check_process_id_in_codelist and check_document_name_code. The subject-verb-object structure is unambiguous and front-loaded.

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

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 a cross-reference to list_participant_id_schemes, but it never says when to use this tool versus the many adjacent check_* and list_* tools. No when-not or alternative guidance is provided, leaving tool selection to inference from the name.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does reveal an important prerequisite (EINVOICING_PEPPOL_CODELIST_DIR) and implies a read-only boolean check, but it doesn't describe error behavior, return format, or side effects. The presence of an output schema reduces the need to document return values, but the description alone is still fairly thin.

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

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

Two sentences with no filler. The core action and input format are front-loaded, and the prerequisite/environment-variable note is placed separately and clearly.

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

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

For a one-parameter predicate with an output schema, the description covers the input format and the key prerequisite. The reference to `list_participant_id_schemes` is slightly vague but still provides a path for an agent to discover more context. It is adequate but not exhaustive.

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

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

The schema only says `icd` is a string, but the description adds that it must be a 4-digit ISO 6523 ICD code with the example `0208`. This compensates for the 0% schema description coverage and gives enough format information for an agent to construct a valid argument.

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

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

The description states a specific action and resource: checking whether a 4-digit ISO 6523 ICD code is a recognized Peppol scheme. This is clear and more specific than generic ICD checks like `check_icd_code`, though it doesn't explicitly name an alternative to distinguish itself from siblings.

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

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

The intended use is clear: validate a participant identifier scheme code against the Peppol codelist. It adds a prerequisite (environment variable) and points to the companion `list_participant_id_schemes` tool, giving an agent useful context for when to invoke this tool, though it doesn't explicitly state when not to use it.

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

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

With no annotations, the description must carry behavioral disclosure. It usefully discloses an environment prerequisite, but does not state whether the check is read-only, what its return behavior looks like, or how failures are signaled. The output schema may cover return values, but the description itself is thin on side effects and error behavior.

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

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

Two sentences with no filler; the purpose is front-loaded and the prerequisite is the only additional information. Every sentence earns its place.

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

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

The tool is simple (two string params, output schema exists), so this description is mostly adequate for selecting and invoking it. However, given the directory requirement, the agent would benefit from a pointer to where process identifiers can be listed (e.g., list_process_ids) to fill valid values.

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

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 parameter definitions. It only says that scheme and value form a pair to be checked, adding little beyond their names; it never defines valid schemes/values or references list_process_ids for valid process identifiers.

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

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

The description states a specific action ('Check whether') on a specific resource: a (scheme, value) pair as a Peppol process identifier. This clearly distinguishes it from the list_* siblings, though it does not explicitly call out check_participant_id_scheme_in_codelist as its closest sibling.

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

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

The only usage guidance is the prerequisite EINVOICING_PEPPol_CODELIST_DIr and a pointer to list_participant_id_schemes for that context. It does not say when to prefer this over other check_* tools or list_process_ids, nor what to do when the pair is not recognized.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description carries the behavioral transparency burden. It clearly signals a read-only reporting action ('Report') and discloses that the value is based on local configuration rather than a remote source. It does not detail return shape, but the output schema can cover that.

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

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

The description is a single sentence with no filler, and the key subject ('OpenPeppol eDEC code list release version(s)') is front-loaded. Every word earns its place.

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

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

For a zero-parameter, local read-only status check, the description is nearly complete. It correctly frames what is being reported and where the data comes from, and the output schema can document the exact return structure. The only minor gap is not explicitly contrasting it with the EN16931 codelist version sibling.

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

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

The tool accepts zero parameters, so the schema is fully self-describing and there are no parameter semantics to explain. The baseline of 4 for zero-parameter tools applies, and the description adds no contradictory or unnecessary parameter information.

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

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

Description states a clear verb ('Report'), a specific resource ('OpenPeppol eDEC code list release version(s)'), and the local scope ('currently configured locally'). It is easy to distinguish from the sibling get_en16931_codelist_version because the description explicitly names the eDEC code list.

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

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

The intended use case—checking the locally configured eDEC code list version—is clear from the description and the tool name. It does not explicitly offer when-not-to-use guidance or point to the similar EN16931 tool, but the OpenPeppol eDEC mention gives enough context to select it appropriately.

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

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

With no annotations, the description carries the full disclosure burden and does well: it explains data provenance (CustomizationID from profile_registry at import time, ProfileID from a local constant), that no default is enforced, and the legacy status of BIS3. It does not cover error behavior for an invalid profile key, which is the main remaining gap.

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

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

The purpose is front-loaded in the first sentence, but the middle paragraphs are padded with parentheticals and meta-commentary (e.g., 'registered at import time in models/invoice.py', 'user-supplied guidance, not independently verified against an IRAS/IMDA notice') that dilute the actionable content.

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

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

An output schema exists, so return values need not be described, and the description supplies the provenance and selection guidance an agent needs. It is nearly complete for this narrow lookup tool, lacking only failure-mode behavior.

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

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

Schema coverage is 100% and the schema already lists the two legal values, so baseline is 3. The description adds genuine meaning beyond the schema: which value is recommended for new senders and which is legacy, aiding correct value selection.

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

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

The opening sentence states a specific verb (Return) and precise resources (CustomizationID BT-24 and ProfileID BT-23) scoped to Singapore profiles. It is immediately distinguishable from siblings like list_process_ids or get_peppol_codelist_version.

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

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

It gives clear guidance on value selection (PINT_SG recommended for new senders, BIS3 legacy) and explicitly states no hard default is enforced, which helps the caller choose. However, it never states when to use this tool versus sibling tools such as list_process_ids or list_document_type_ids, so routing guidance is only implied.

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

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

No annotations are provided, so the description must carry behavioral context. It discloses an important environment requirement, which is useful. However, it does not explicitly state that this is a read-only listing operation or describe any other behavioral traits such as error conditions or performance characteristics.

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

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

Two concise sentences with no filler. The main purpose is front-loaded, and the prerequisite is clearly separated in the second sentence. Every sentence contributes useful information.

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

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

Given the tool's low complexity, a single optional parameter, an existing output schema, and the environment prerequisite being mentioned, the description is mostly complete. The only notable gap is lack of explicit guidance on when to use this tool versus a sibling like check_document_type_id_in_codelist.

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

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

The schema already fully describes the only parameter (`active_only`) with a clear default and meaning. The description adds no additional semantic value for parameters, so the baseline of 3 applies.

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

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 clear resource ('Peppol document type identifiers from the OpenPeppol eDEC code list'). It is distinguishable from many sibling codelist tools, though it does not explicitly contrast with similar tools like list_document_name_codes or check_document_type_id_in_codelist.

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

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

The intended use is implied by the name and description, but there is no explicit when-to-use guidance or mention of alternatives. The prerequisite note about EINVOICING_PEPPOL_CODELIST_DIR provides useful context and points to a sibling for setup, but it does not explain when to choose this tool over another.

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

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 reveals that the data source is a local, non-bundled eDEC GeneriCode export, that an environment variable is required, and that redistribution rights are uncertain. This adds meaningful operational context beyond the input schema.

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

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

The description is front-loaded with the purpose and follows with essential setup context. There is no redundant text; every sentence contributes necessary information, including the source, prerequisite, and licensing caveat.

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

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

For a one-parameter list tool with an output schema, the description covers the data source, prerequisite, and licensing context. It does not mention alternative tools, but the main operational requirements are present, making it sufficiently complete.

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

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

The single parameter, 'active_only', is already fully described in the schema with its type, default, and behavior. The description adds no additional parameter semantics, so the baseline of 3 for high schema description coverage is appropriate.

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

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

The description clearly states a specific verb and resource: 'List Peppol participant identifier (ICD) schemes from the OpenPeppol eDEC code list.' This distinguishes the tool's subject matter, though it does not explicitly differentiate it from the similarly named sibling 'list_icd_codes'.

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

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

The description provides a concrete prerequisite: EINVOICING_PEPPOL_CODELIST_DIR must point to a local eDEC GeneriCode export. However, it gives no guidance on when to prefer this tool over alternatives such as list_icd_codes or check_participant_id_scheme_in_codelist.

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

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

With no annotations provided, the description carries the burden of explaining prerequisites. It does disclose that EINVOICING_PEPPOL_CODELIST_DIR is required, which is useful and non-obvious. However, it does not describe error behavior, return structure, or the read-only nature beyond the verb 'List', leaving some behavioral gaps.

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

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

The description is two sentences, front-loaded with the core purpose, and includes only necessary prerequisite information. Every sentence earns its place with no repetition or filler.

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

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

The tool has a simple schema, a single optional parameter, and an output schema, so minimal description is needed. The environment variable requirement is an important addition that makes the tool usable. It could be more complete by noting the relationship to the check counterpart, but this is a minor gap for a straightforward listing tool.

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

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

Schema description coverage is 100% for the single boolean parameter active_only, so the schema already fully documents its meaning. The description adds no additional parameter semantics, which is acceptable given the baseline of 3 when schema coverage is high.

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

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

The description clearly states the action ('List'), the resource ('Peppol process identifiers'), and the source ('OpenPeppol eDEC code list'). It differentiates from sibling tools like check_process_id_in_codelist by indicating that this tool returns a list rather than validating a single identifier.

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

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

The description mentions the required environment variable and points to list_participant_id_schemes for reference, but it does not explicitly explain when to use this tool versus the sibling check_process_id_in_codelist. The usage context is partially implied by the name and sibling list, but not fully stated.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose a significant dependency: the EINVOICING_PEPPOL_CODELIST_DIR environment variable. But it does not mention what happens if that directory is missing, whether the data is read locally, or any ordering/filtering behavior, so the behavioral picture is incomplete.

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

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

The description is two concise sentences: one states the purpose, the second states a requirement and points to a sibling for setup. There is no fluff 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.

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

For a simple list-only tool with one optional parameter and an output schema, the description covers the essentials: the data source and the required environment variable. It does not explain when to prefer it over related codelist tools, but it is otherwise complete enough for an agent to invoke correctly.

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

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 with its default value and effect. The description adds no parameter-specific meaning beyond that, so the schema already does the heavy lifting.

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

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

The description clearly states a specific verb and resource: it lists 'Peppol SPIS use case identifiers' sourced from the OpenPeppol eDEC code list. It is unambiguous, though it does not explicitly distinguish itself from sibling list tools such as list_process_ids 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.

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

The description implies usage by naming the resource, and it adds a key prerequisite by requiring EINVOICING_PEPPOL_CODELIST_DIR, even pointing to list_participant_id_schemes for setup. However, it does not state when to use this tool versus alternatives or when not to use it, leaving some selection guidance to inference.

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

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 does well by stating that the search is public and unauthenticated, which is important for an agent deciding how to invoke it. It also clarifies that this is not an SMP lookup, preventing a subtle misuse. It doesn't discuss pagination or rate limits, but the output schema and parameter descriptions cover most operational details.

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

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

The description is concise: three short sentences with no filler. It front-loads the core purpose, then adds the access mode and the essential 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.

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

Given the tool has 8 parameters, a rich schema, and an output schema, the description covers the most important contextual gaps: public access, non-SMP scope, and the required-filter constraint. It could additionally name the sibling for SMP lookup, but the explicit 'no relation to SMP lookup' warning largely compensates.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful value by specifying the non-obvious requirement that at least one of q/participant/name/country/doctype must be supplied, which is not enforceable in the schema since all parameters are optional. This helps the agent avoid calling the tool with no filters.

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

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

The description uses a specific verb ('Search') and resource ('Peppol Directory', 'registered participants'), immediately clarifying what the tool does. It further distinguishes itself by explicitly stating it has 'no relation to SMP lookup', which separates it from sibling tools 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.

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

The description provides clear context: this is a public, unauthenticated directory search. It also states a critical usage constraint: at least one of q/participant/name/country/doctype must be supplied. However, it doesn't explicitly name an alternative tool for SMP lookup, so the guidance stops short of fully routing the agent to the correct sibling.

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

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

With no annotations provided, the description carries full behavioral disclosure responsibility. It details the internal workflow (DNS resolution then service metadata fetch) and precisely describes the redirect edge case: `redirect_url` set, `endpoint_url` None, and a hard limit of one redirect hop per SMP 1.4.0 §3.2. This is explicit, operational context that goes well 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.

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

The description is two sentences with the primary action front-loaded and the critical redirect caveat placed immediately after. Every clause adds relevant information; there is no filler or repetition.

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

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

For a tool with three parameters and an output schema, the description covers the full workflow and a significant non-obvious edge case (redirect handling). It does not mention error behavior when DNS resolution or SMP fetching fails, but given the output schema exists and the parameter schema is complete, the core operational knowledge needed to invoke correctly is present.

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

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

The input schema already documents all three parameters with 100% coverage, so the baseline is 3. The description references `document_type_id` in the workflow and contextualizes it as the target of metadata fetching, but adds no new parameter-level syntax or format details beyond what the schema provides.

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

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.' It clearly states the tool's objective and distinguishes itself from sibling tools like resolve_peppol_dns by mentioning the DNS resolution step, making the tool's scope unambiguous.

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

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

The purpose sentence implies the tool is for endpoint discovery, and the technical detail about DNS resolution suggests how it works. However, it does not explicitly name alternatives or state when to prefer this tool over similar siblings like resolve_peppol_dns or peppol_lookup_participant. A short 'use this when...' phrase would elevate it.

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

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 does well by revealing that the tool performs network lookups (DNS-over-HTTPS and SMP requests) to determine registration status and document type identifiers, implying a read-only, non-mutating operation.

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

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

The description is concise and front-loaded: the first sentence states the purpose, and the second sentence explains the operational flow. Every sentence adds necessary information without repetition or filler.

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

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

Given the presence of an output schema and full parameter documentation, the description is largely complete: it states the purpose, the lookup method, the determined outcome, and the identifier scope. It could be slightly more complete by noting when to prefer this over related Peppol lookup tools, but that is not a critical gap.

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

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

The input schema provides 100% coverage of both parameters: identifier and environment, each with clear descriptions. The tool description adds no additional parameter-level meaning beyond what the schema already states, 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.

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 also clarifies the mechanism (DNS-over-HTTPS U-NAPTR lookup + SMP service-group request), making it easy to distinguish from siblings 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.

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

The intended use case is clear from the description: verify Peppol registration status and supported document types. However, it does not explicitly contrast itself with sibling tools such as peppol_get_service_endpoint, resolve_peppol_dns, or peppol_directory_search, so an agent must infer when this tool is the right choice.

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

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 goes beyond a simple 'sends an invoice' by disclosing the steps: SMP lookup, ebMS3/AS4 envelope construction, and credential use. It does not mention irreversibility or delivery side effects, but the transmission intent is explicit, making this reasonably transparent.

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

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

Two clear sentences with no wasted words. The first sentence gives the essential purpose, and the second adds meaningful operational process detail. The description is well front-loaded and appropriately sized for the tool's complexity.

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

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

The tool is a high-stakes external transmission operation with 8 parameters. An output schema exists, so return values are covered, but the description omits useful preconditions such as SMP discoverability, environment selection, and the relationship between sender_id and the signing credentials. It also does not connect to related lookup tools like peppol_lookup_participant or peppol_get_service_endpoint, which could be prerequisite steps.

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

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

The schema documents all 8 parameters with descriptions, so the baseline is 3. The description adds no parameter-level detail beyond referencing the supplied signing credentials, which map to certificate and private key params. It does not need to compensate for missing schema coverage because coverage is 100%.

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

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: 'Send a UBL/CII invoice to a Peppol participant via AS4.' It clearly identifies the operation and distinguishes it from invoice creation, validation, and lookup tools among the siblings.

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

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

The intended use is clear from the description: use this when an invoice document needs to be transmitted to a Peppol participant. It does not explicitly state when not to use it or name alternatives, but none of the sibling tools perform this exact sending function, so the context is sufficient.

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

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

With no annotations provided, the description carries the behavioral burden and does well: it discloses that the tool is DNS-only, performs a raw U-NAPTR lookup, and explicitly does not fetch the SMP service group. This gives the agent an accurate model of side effects and limitations, though it does not discuss network dependency or error behavior.

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

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

The description is two tightly scoped sentences: the first states the core action, the second adds the key behavioral distinction and use case. No filler or repetition exists.

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

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

For a simple two-parameter tool with an output schema, the description is largely complete: it explains the operation, its scope, and its diagnostic purpose. It could slightly improve by naming a sibling alternative, but this is not required for correctness.

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

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

Schema description coverage is 100%, so the schema already documents both parameters well. The description reinforces what 'identifier' refers to implicitly via 'participant', but does not add new parameter-level detail beyond the schema. Baseline 3 is appropriate.

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

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

The description names a specific verb ('Resolve'), resource ('SMP hostname for a Peppol participant'), and method ('via DNS only'). It further distinguishes itself from sibling tools by clarifying it performs the raw U-NAPTR lookup without fetching the SMP service group.

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

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

The description clearly implies when to use it: for diagnosing SML registration independently of SMP reachability. It does not explicitly name alternative tools or when not to use it, but the context is strong enough that an agent can infer the appropriate scenario.

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

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

With no annotations, the description carries the full burden and meets it: it discloses the dependency on the optional xslt2 extra, that a missing install returns level="unavailable", and that results carry a scope field and an EN16931-BASE-UNAVAILABLE warning. Failure modes and known limitations are surfaced before the agent calls.

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

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

The scoping is reasonably front-loaded, but the second paragraph leaks implementation detail unhelpful to an agent: a reference to validators/schematron.py's module docstring and the internal ticket [CORE-EN16931-BASE-SG-CROSSWALK-1]. Those sentences consume space without changing invocation behavior.

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

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

An output schema exists, so return values need not be exhaustively explained, and the description still usefully names key result fields (scope, level, the warning code). For a one-parameter validation tool the coverage is adequate; only the alternative-tool routing for the uncovered rulesets is missing.

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

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

Schema description coverage is 100% for the single xml_content parameter, whose schema text already specifies 'UBL 2.1 Invoice or CreditNote XML content to validate.' The description restates UBL 2.1 invoice XML but adds no format, encoding, or size guidance 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.

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

States a specific verb and resource — validate a UBL 2.1 XML invoice against IRAS's C5 acceptance-layer Schematron — and immediately scopes what that means (IRAS's own acceptance layer, e.g. missing buyer/seller UEN). This is distinguishable from the sibling generate_invoice_sg and the various codelist/lookup tools.

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

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

Explicitly defines when this tool applies (IRAS acceptance-layer checks) and, more usefully, when it does not: the CEN EN16931 base ruleset, PINT-SG overlay, and SG Peppol BIS Billing 3.0 are NOT checked. That negative scoping is strong routing guidance, though it never names an alternative tool for the unchecked rulesets.

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