Netherlands Invoices (Peppol BIS 3.0 via Storecove)
Server Details
Netherlands Peppol BIS 3.0 e-invoices for AI agents: send, check recipient, get delivery proof.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 3 of 3 tools scored.
Each tool has a unique and clear purpose: check_recipient verifies if a business can receive invoices, create_invoice sends the invoice, and get_delivery_evidence retrieves delivery status. There is no overlap.
All tool names follow a consistent verb_noun pattern in snake_case (check_recipient, create_invoice, get_delivery_evidence). The naming is predictable and clear.
With 3 tools, the server is tightly scoped to the specific task of sending Dutch Peppol invoices. Each tool is necessary for the core workflow, and the count is appropriate for this focused domain.
The tool set covers the essential workflow: pre-flight check, invoice creation, and evidence retrieval. Missing a direct cancel/credit note tool, but the description explains that a credit note is a new invoice, so the surface is reasonably complete for the stated purpose.
Available Tools
3 toolscheck_recipientARead-onlyInspect
Check whether a business can receive electronic invoices on the Peppol network before you send (Storecove POST /discovery/receives). This is the safe pre-flight for Dutch B2B: pass the recipient identifier and scheme and learn if they are a registered Peppol participant. For the Netherlands use scheme 0106 with the 8-digit KVK number, or 9944 with the VAT number NLxxxxxxxxxBxx. Returns can_receive=true when the party is reachable (Storecove code OK). If can_receive is false, the recipient is not on Peppol — fall back to recipient_email in create_invoice or ask them to register.
| Name | Required | Description | Default |
|---|---|---|---|
| scheme | No | Peppol/ISO6523 scheme. Default 0106 (Dutch KVK number). Use 9944 for a Dutch VAT number. | |
| network | No | Network to check. Default peppol. | |
| identifier | Yes | The recipient Peppol identifier. Netherlands: the 8-digit KVK number (scheme 0106) or the VAT number NLxxxxxxxxxBxx (scheme 9944). | |
| document_types | No | Document types to check receipt for. Default ["invoice"]. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by stating the return value ('can_receive=true when reachable, Storecove code OK') and the fallback behavior. Annotations already mark it as read-only, so the burden is lower, but error scenarios beyond 'not on Peppol' are not covered.
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 paragraph with essential information front-loaded. It is dense but not verbose; however, it could be slightly more concise by combining some sentences without losing clarity.
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 4 parameters and no output schema, the description covers the main behavior, parameter usage, and fallback actions. It provides enough context for an agent to decide when and how to use the tool, though it does not detail the full response structure or error handling.
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 baseline is 3. The description adds practical meaning by explaining scheme usage for Netherlands, the expected identifier format (KVK number, VAT number), and the default document_types, which goes beyond the schema descriptions.
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 clear verb ('Check') and resource ('whether a business can receive electronic invoices on Peppol'), specifies the context (Dutch B2B), and distinguishes from siblings by calling it a 'safe pre-flight' and mentioning fallback to create_invoice.
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 explicitly states when to use this tool ('before you send'), provides specific parameter usage for the Netherlands (scheme 0106 with KVK, 9944 with VAT), and what to do if the recipient is not on Peppol (fall back to recipient_email or ask to register).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_invoiceAInspect
Send a Netherlands B2B electronic invoice over the Peppol network in Peppol BIS 3.0 / EN 16931 format via Storecove (a certified Peppol Access Point). The Netherlands has mandated Peppol e-invoicing for B2G since 2017 and has one of the highest Peppol adoption rates in Europe for B2B; B2B is voluntary today, with EU-wide ViDA mandatory e-invoicing expected by 2030. Builds the structured invoice JSON from seller + buyer (name, Dutch VAT NLxxxxxxxxxBxx and/or KVK number, address) and line items (description, quantity, net unit price, VAT rate 21/9/0), computes the Dutch VAT breakdown, and submits it under YOUR OWN Storecove credentials. Bring your own credential as header x-storecove-key. You must also pass seller_legal_entity_id — the legalEntityId of the sender you created in your Storecove account. Dutch VAT rates: 21 (standard), 9 (reduced), 0 (zero-rated/exempt/reverse charge). Amounts in EUR. Delivery over Peppol is asynchronous: this returns a submission guid — use get_delivery_evidence with it to fetch the delivery proof/status. Tip: call check_recipient first to confirm the buyer is reachable on Peppol. There is no cancel over Peppol: to reverse an invoice you issue a credit note (a new invoice).
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional free-text note on the invoice. | |
| lines | Yes | Invoice line items. Each: description, unit_price (net, VAT-exclusive, EUR), vat_rate (21|9|0), optional quantity (default 1), optional tax_category (S standard / Z zero-rated / E exempt / AE reverse charge; default S for rate>0, Z for rate 0), optional item_name. | |
| currency | No | Document currency. Default EUR. | |
| due_date | No | Optional payment due date, YYYY-MM-DD. | |
| issue_date | No | Invoice issue date, YYYY-MM-DD. Default: today (UTC). | |
| seller_kvk | No | Optional seller Dutch Chamber of Commerce (KVK) number, 8 digits. Used to route on Peppol (scheme 0106) if given. | |
| seller_vat | No | Seller Dutch VAT (btw) number, format NLxxxxxxxxxBxx (NL + 9 digits + B + 2 digits). Provide this and/or seller_kvk. | |
| seller_zip | Yes | Seller postal code. | |
| seller_city | Yes | Seller city. | |
| seller_name | Yes | Seller legal/company name. | |
| customer_kvk | No | Optional buyer Dutch KVK number, 8 digits (preferred Peppol routing identifier, scheme 0106). | |
| customer_vat | No | Buyer Dutch VAT number NLxxxxxxxxxBxx. Provide this and/or customer_kvk (used to route on Peppol if no explicit recipient id is given). | |
| customer_zip | Yes | Buyer postal code. | |
| customer_city | Yes | Buyer city. | |
| customer_name | Yes | Buyer legal/company name. | |
| invoice_number | No | Invoice number. Auto-generated if omitted. | |
| seller_address | Yes | Seller street address. | |
| seller_country | No | Seller country code. Default NL. | |
| recipient_email | No | Optional email fallback — used if the recipient is not on Peppol (Storecove can email a copy). | |
| customer_address | Yes | Buyer street address. | |
| customer_country | No | Buyer country code. Default NL. | |
| recipient_peppol_id | No | Optional explicit Peppol participant identifier to route to (overrides deriving from the customer KVK/VAT number). | |
| seller_legal_entity_id | Yes | REQUIRED. The Storecove legalEntityId of the sender (created in your Storecove account under Senders). Numeric id, passed through to Storecove. | |
| recipient_peppol_scheme | No | Optional explicit Peppol routing scheme (EAS/ISO6523). Netherlands: 0106 (KVK number) or 9944 (VAT). Default 0106 when routing by KVK number. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes asynchronous delivery, returns submission guid, requires credentials, and explains VAT computation. Annotations correctly indicate write operation, no idempotency, no destruction; no contradiction.
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?
Well-structured and front-loaded, but somewhat lengthy due to background context. Every sentence serves a purpose, though could be slightly trimmed.
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?
Despite lacking an output schema, the description fully covers return value (guid), prerequisites, process, tips, and limitations, making it complete for a 24-parameter 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 coverage is 100%, but description adds critical context like Dutch VAT rate meanings, routing logic (KVK vs VAT), default behaviors, and credential requirements beyond schema property descriptions.
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 specifies the exact action: sending a Netherlands B2B electronic invoice over Peppol via Storecove, and distinguishes from sibling tools by mentioning check_recipient and get_delivery_evidence.
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 states when to use (sending e-invoice), when not (no cancellation, need credit note), and suggests companion tools (check_recipient first, get_delivery_evidence for status).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_delivery_evidenceARead-onlyInspect
Fetch the delivery evidence for an invoice sent by create_invoice, using its submission guid (Storecove GET /document_submissions/{guid}/evidence). Peppol delivery is asynchronous — this returns the proof of what was sent and the delivery status/receipt from the recipient Access Point. Call it shortly after create_invoice and poll until it reports delivery. Safe to call anytime.
| Name | Required | Description | Default |
|---|---|---|---|
| guid | Yes | The submission guid returned by create_invoice. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint. The description adds that Peppol delivery is asynchronous and explains what the tool returns (proof, status, receipt). It also states safety, enhancing transparency beyond annotations.
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?
Three concise sentences, each adding value: purpose, behavioral context, and usage advice. No redundant information, well-structured and 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?
Given the simple schema (one param, no output schema), the description sufficiently covers what the tool returns and how to use it. Minor omission: no mention of error conditions or format of evidence, but not critical.
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% with a description for the 'guid' parameter. The description mentions 'submission guid' and the Storecove endpoint but does not add new semantic details 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 clearly states the verb 'Fetch', the resource 'delivery evidence for an invoice', and references the specific submission guid from create_invoice. It distinguishes the tool from siblings by specifying the context of Peppol delivery and the async workflow.
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?
Provides explicit when to use: 'Call it shortly after create_invoice and poll until it reports delivery.' Also indicates it is 'Safe to call anytime.' This gives clear usage context and polling advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!