The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Peppol listing page.
Check whether a company is registered on the Peppol e-invoicing network, list the document types it accepts, and get the AS4 endpoint a sender needs — walked live through the Peppol SML and SMP, with no network membership required.
Part of Pipeworx — an MCP gateway connecting AI agents to 1683+ live data sources.
lookup_participant(participantId, scheme?, environment?) — the authoritative
registration check. Resolves the participant through the SML (DNS/BDXL) to its
SMP and reads the ServiceGroup. Answers "can I send this company an e-invoice,
and in which formats?" Returns registered: false with a reason, plus
determinate, when there is no SML record.get_participant_endpoint(participantId, documentTypeId, documentTypeScheme?, scheme?, environment?)
— the AS4 delivery details for one document type: transport profile, receiving
endpoint URL, process identifier, and the service activation/expiration
window. Answers "where do I actually deliver this, and is it still live?"search_participants(q, country?, limit?) — searches the Peppol Directory by
company name, VAT number or organisation number. Answers "what is this
company's Peppol identifier?", which is the input the other two tools need.Keyless. All three upstreams are public and need no Peppol network membership, no Access Point contract and no PKI certificate. Reading the network's discovery layer is deliberately open — it is what lets any sender find any receiver.
(Note the asymmetry: reading discovery is open, sending over AS4 is not. Delivering a document needs an accredited Access Point and a Peppol certificate. This pack covers the read half only.)
https://cloudflare-dns.com/dns-query and https://dns.google/resolve — the
SML NAPTR lookup, over DNS-over-HTTPS because the Workers runtime has no DNS
resolver. Cloudflare first, Google as fallback.iso6523-actorid-upis.edelivery.tech.ec.europa.eu (production) and
iso6523-actorid-upis.acc.edelivery.tech.ec.europa.eu (pilot), operated by the
European Commission — maps a participant identifier to its SMP base URL.https://smp.elma-smp.no, https://smp.horus-software.be) — serve
/{scheme}::{participantId} and /{scheme}::{participantId}/services/{docTypeId}.https://directory.peppol.eu/search/1.0/json — the Peppol Directory, the
network's opt-in business-card index, operated by OpenPEPPOL.The MD5 lookup scheme every write-up describes is dead. Most Peppol
documentation (and most blog posts) describe the SML as
B-{md5(lowercased participant id)}.iso6523-actorid-upis.{zone} resolving to a
CNAME. That NXDOMAINs today for every participant, including ones you can see
listed in the Peppol Directory. The live scheme is OASIS BDXL: the record name is
the unpadded base32 of SHA-256 over the lowercased identifier, and the record
is a NAPTR whose service field is Meta:SMP and whose regexp field carries
the SMP URL as !.*!https://smp.example/!. Getting NXDOMAIN on a company you
know is registered means you are on the MD5 path, not looking at an unregistered
company — that costs an hour if you trust the docs over a live dig.
Hash the identifier value only. The input to SHA-256 is 0192:989995278,
never iso6523-actorid-upis::0192:989995278. Including the scheme prefix
NXDOMAINs silently, which looks exactly like "not registered".
The two DoH providers return NAPTR RDATA in different shapes. Cloudflare
quotes the character-strings (100 10 "U" "Meta:SMP" "!.*!https://x!" .), Google
does not (100 10 U Meta:SMP !.*!https://x! .). Parse both or the fallback path
silently returns nothing.
SMPs disagree about Accept. smp.elma-smp.no (Spring-based) answers
406 Not Acceptable to Accept: application/xml, while
smp.horus-software.be serves it. Both accept text/xml. Send a q-list, or the
pack works against one operator's SMP and 406s against another's — and a 406 here
reads like the participant is broken rather than like our header is.
XML prefixes vary by SMP implementation. The same elements come back as
smp:ServiceGroup from one operator and ns2:ServiceGroup from another. Match on
local name, never on prefix.
Absence from the Directory is not absence from the network. Business cards
are opt-in, so search_participants returning nothing does not mean a company
cannot receive e-invoices. lookup_participant against the SML is the
authoritative answer; the Directory is a convenience index for turning names into
identifiers.
The participant identifier is {icd}:{value}, and the ICD prefix is part of
it. 989995278 is a Norwegian org number; 0192:989995278 is a Peppol
participant. The same company can appear under several ICDs (e.g. 0208 company
number and 9925 VAT for the same Belgian entity), each a separate registration
with its own document types.
Add to your MCP client (Claude Desktop, Cursor, Windsurf, etc.):
tools/list at https://gateway.pipeworx.io/peppol/mcp returns the tools in the table
above plus the shared Pipeworx meta-tools — ask_pipeworx,
discover_tools, search_within, remember/recall and the rest of the
gateway-wide set. So the tool count you see is larger than this table: a
single-pack endpoint currently lists roughly 30 shared tools alongside the
pack's own. The connection's initialize response states its exact scope, and
is the authoritative answer for a given day.
This is deliberate, not multiplexing by accident. The meta-tools are what let a
scoped connection answer a question this pack does not cover — via
ask_pipeworx, which routes across the whole catalog — without you adding a
second MCP server. There is currently no way to mount a pack endpoint without
them; if the extra schemas cost you more context than the routing is worth,
connect to the full gateway once rather than to several pack endpoints.
Or connect to the full Pipeworx gateway to get every pack's tools listed directly, instead of just this one's:
Both URLs reach the same gateway and the same 1683+ data sources. The
only difference is which pack's tools are listed directly; ask_pipeworx
reaches all of them from either one.
No account needed for the first calls. Inspect any tool: GET https://gateway.pipeworx.io/v1/tools/lookup_participant. Find one: POST https://gateway.pipeworx.io/v1/tools/search_packs with {"query":"..."}.
This package also runs as a local stdio MCP server — no Pipeworx account, no gateway round-trip:
Or run it directly to confirm it starts:
It speaks MCP over stdin/stdout and answers initialize/tools/list/tools/call
for only this pack's tools — none of the shared meta-tools the gateway
connection above adds. Same source, same tools, no ask_pipeworx routing.
Instead of calling tools directly, you can ask questions in plain English — this works on the pack endpoint above as well as on the full gateway:
The gateway picks the right tool and fills the arguments automatically.
MIT