list_process_ids

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

With no annotations provided, the description carries full weight for behavioral disclosure. It adds a genuinely useful piece of context beyond the schema: the tool requires the EINVOICING_PEPPOL_CODELIST_DIR environment variable, which is a concrete external dependency. However, it doesn't discuss what happens if that variable is unset, or mention the return format characteristics (beyond the output schema existing). The disclosed prerequisite is valuable, but for a straightforward list operation the behavioral surface is small. Compared to the scoring guide's emphasis on adding context, this description does add something meaningful, so above baseline, but doesn't go as far as discussing auth, error handling, or response behavior. Weights: 1=misleading/missing (no, since the env var note is there), 2=no guidance (no, env var note exists), 3=adequate, 4-5=rich contextual detail.

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 short, front-loaded sentences with zero waste. The first sentence states the purpose, and the second conveys an essential prerequisite while efficiently redirecting to a sibling tool for related context. 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 low-complexity, list-style tool with one optional boolean parameter, this description is largely complete. It explains the source (OpenPeppol eDEC code list), the resource (process identifiers), and the single critical dependency (env var). The tool has an output schema but the description need not cover return values per the rubric. A minor gap is not mentioning how to check a single process ID's existence (the sibling check_process_id_in_codelist), which could help an agent decide between listing and checking, but this is a nice-to-have given the tool's simplicity.

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% — the single optional 'active_only' parameter is fully described inline ('When True (default), omit deprecated/removed entries.'). The long description adds no parameter-specific detail, but it doesn't need to since the schema already fully explains the one parameter. Per the rubric, high schema coverage sets a baseline of 3, and there's no gap for the description to fill.

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 gives a specific verb+resource+source: 'List Peppol process identifiers from the OpenPeppol eDEC code list.' This clearly identifies what the tool does and, given the sibling context (list_participant_id_schemes, list_document_type_ids), distinguishes it as the one for process IDs. Naming the code list authority (OpenPeppol eDEC) adds precision.

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 an implicit usage hint by referencing the shared prerequisite and pointing to list_participant_id_schemes for env var details. However, it never explicitly explains when to use this tool versus alternatives. Interestingly, a related check function (check_process_id_in_codelist) exists as a sibling, but the description doesn't clarify when to use a list vs. a check. The cross-reference provides some context, but no explicit when/when-not guidance. Weights: 1=misleading, 2=no guidance, 3=implied usage, 4=clear context, 5=explicit alternatives.

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