Tanod MCP server

utilpeek: Peppol participant lookup (registered? SMP URL, accepted document types)

peppol_lookup

Read-onlyIdempotent

Check whether a company's Peppol participant ID is registered on the e-invoicing network, returning its SML DNS status, SMP URL, and listed document types.

Instructions

utilpeek: Check whether a company is registered on the Peppol e-invoicing network. For the legal entity use search_lei. Returns whether a Peppol participant ID (such as 0192:983887457) is registered on the Peppol e-invoicing network, from its SML DNS record; if so, its SMP URL and the document types the SMP lists (BIS Billing 3.0 invoice and credit note, order, despatch advice and invoice response labelled; others raw). A DNS registration only shows the participant is reachable on Peppol, not that the company is verified. If the SMP cannot be read the DNS answer is still returned with smp_error. Bad IDs are a 422 and a DNS outage a 503 (neither charged). Typically 0.2-2 s. Price: USD 0.002. Free: 10 utilpeek calls per IP per UTC day. Docs: https://tanod.dev/learn/peppol-participant-lookup-api.html

Input Schema

TableJSON Schema

Name	Required	Description	Default
`scheme`	No	Identifier scheme. Only iso6523-actorid-upis (the default) is supported.	iso6523-actorid-upis
`participant`	Yes	Peppol participant ID: a four-digit ICD, a colon and the identifier (1-50 of letters, digits, '.', '_', '-'), such as 0192:983887457 (a Norwegian organisation number). The full form iso6523-actorid-upis::0192:983887457 is accepted too.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`scheme`	No
`smp_url`	No
`sml_name`	No
`smp_error`	No
`checked_at`	No
`registered`	No
`participant`	No
`document_types`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent safety, and the description adds substantial context beyond them: the answer comes from the SML DNS record, a DNS hit means reachable rather than verified, unreadable SMP still returns DNS plus `smp_error`, bad IDs are 422 and outages 503 with neither charged, and typical latency is 0.2-2 s. Pricing (USD 0.002) and the 10-free-calls-per-IP-per-day limit further inform invocation decisions.

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

Conciseness4/5

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

Purpose is front-loaded in the first sentence, then caveats, error semantics, latency, pricing and docs follow in a logical order. It is dense and runs long, but nearly every sentence carries decision-relevant information, so little is wasted.

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?

An output schema exists, yet the description still flags the key return semantics (SMP URL, labelled vs raw document types, smp_error fallback) and all failure modes with status codes, latency and cost. For a read-only, open-world lookup with two parameters, nothing an agent needs before calling it 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 description coverage is 100%, so both `scheme` (only iso6523-actorid-upis) and `participant` (ICD:identifier format, accepted full form) are already fully documented. The description repeats the example ID but adds no syntax or constraint detail beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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 ('Check whether a company is registered on the Peppol e-invoicing network') and immediately scopes the input as a participant ID such as 0192:983887457. It also distinguishes itself from the legal-entity sibling by pointing to search_lei, so an agent can separate it from lookup_lei/search_lei without opening either schema.

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?

Gives clear context (Peppol network registration/reachability) and an explicit alternative for a related need ('For the legal entity use search_lei'). It does not spell out a full when-not-to-use list (e.g. versus validate_identifier), but the routing guidance is concrete and actionable.

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

Deploy Server