Loading ToolBench
phoss Peppol MCP server exposing Peppol functionality to AI models
Strong tool definitions with comprehensive descriptions and clear parameter schemas. All 14 tools have detailed, LLM-optimized descriptions (100-300 chars) explaining WHAT, WHEN, and HOW. Input schemas are well-typed with descriptions for all parameters. Naming follows verb_noun convention (check_, list_, search_, lookup_, validate_, resolve_). Key strengths: domain-specific guidance (e.g., 'Use this to diagnose why a Participant cannot be looked up'), parameter constraints (enums for certificateType, network, state), and pagination support (limit/offset). Gaps: no output schemas documented, no error handling guidance, no tool annotations (readOnlyHint), and no confirmation patterns for sensitive operations.
Validates an X.509 certificate against the official Peppol trust stores. Checks issuer trust, validity period, and revocation status (CRL/OCSP). Both Access Point (AP) and SMP certificates are supported, on both Production and Pilot/Test PKIs (G3). Provide the certificate as a PEM-encoded string (with or without the BEGIN/END markers). Use certificateType='AP' for Access Point certificates and 'SMP' for SMP signing certificates. Use network='production', 'test', or 'all' to choose which Peppol root CAs to check against.
Checks whether a Peppol Document Type identifier is present in the official Peppol Document Type codelist. This goes beyond syntactic validation: it verifies that the identifier is an officially registered value.
Checks whether the identifier scheme (ISO 6523 code) used in a Peppol Participant identifier is present in the official Peppol Participant identifier scheme codelist. For example, checks whether '0088' (GLN) or '0192' (Norwegian org number) is a recognized Peppol scheme. You can pass either a full Participant identifier like '0088:4012345678901' or just the ISO 6523 scheme code like '0088'.
Checks whether a Peppol participant supports receiving a specific document type, such as an invoice, credit note, or order. Use this when a user asks whether they can send a particular document type to a specific company. The documentTypeId should be a Peppol document type identifier, for example 'urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1' for a Peppol BIS Billing 3.0 invoice.
No output schemas documented. LLMs cannot infer what fields to expect from tool responses, forcing them to guess at downstream field names and risk broken tool chains.
No tool annotations (readOnlyHint, idempotentHint). All tools are read-only, but this is not declared in the schema. Clients cannot optimize caching or retry logic without explicit hints.
No error handling guidance. Tools lack descriptions of failure modes, recovery steps, or actionable error messages. E.g., 'certificate not found' should suggest 'Check PEM format or try network=all'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Checks whether a Peppol Process identifier is present in the official Peppol Process codelist.
Lists all Peppol Document Type identifiers from the official codelist, with optional filtering by state and search query.
Lists all Peppol Participant identifier schemes from the official codelist, with optional filtering by state and search query.
Lists all Peppol Process identifiers from the official codelist, with optional filtering by state and search query.
Looks up whether a company is registered in the Peppol Network and retrieves their registration details. Use this when a user asks whether a company can receive Peppol documents, or wants to know their Peppol registration status. The participantId must be in the format <scheme>:<value>, for example '0088:4012345678901' for a GLN, '0184:DK12345678' for a Danish CVR number, or '9915:AT123456789' for an Austrian UID. Common schemes: 0184 (DK CVR), 0192 (NO org), 9906 (IT VAT), 9915 (AT UID), 0060 (DUNS).
Resolves the Peppol U-NAPTR DNS chain for a Participant on the configured network. Returns the DNS hostname queried (a SHA-256 hash of the participant identifier prefixed onto the SML DNS zone) and — if a NAPTR record is found — the resolved SMP base URL. Use this to diagnose why a Participant cannot be looked up: missing DNS entries, wrong SML zone, or NAPTR misconfiguration. The participantId must be in the format <scheme>:<value>, e.g. '0088:4012345678901'.
Searches the Peppol Directory (directory.peppol.eu) for registered participants by company name, country, and document type. The Peppol Directory is the 'yellow pages' of the Peppol network.
Validates whether a string is a syntactically correct Peppol Document Type identifier. This checks format only — it does not verify whether the Document Type is known in the official Peppol codelist. The value should be a Document Type identifier string, e.g. 'urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##...'.
Validates whether a string is a syntactically correct Peppol Participant identifier. This checks format only — it does not verify whether the identifier exists in any codelist or is registered on the Peppol network. The expected format is scheme:value, for example '0088:4012345678901'. Use this before performing a live SMP lookup to catch format errors early.
Validates whether a string is a syntactically correct Peppol Process identifier. This checks format only — it does not verify whether the Process is known in the official Peppol codelist.
Parameter descriptions lack format/constraint details. E.g., 'participantId' says 'format scheme:value' but does not specify valid scheme codes or value length limits. LLMs may pass invalid formats.
No pagination guidance for large result sets. list_* tools accept limit/offset but do not document max result size, default limit, or whether a total_count is returned. Agents may request unbounded results.