Belgium Invoices (Peppol BIS 3.0 via Storecove)
Server Details
Belgium 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 serves a distinct role in the invoice sending workflow: check_recipient validates recipient capability, create_invoice sends the invoice, and get_delivery_evidence retrieves delivery status. No functional overlap exists.
All tool names follow a consistent verb_noun pattern with snake_case: check_recipient, create_invoice, get_delivery_evidence. The naming is uniform and predictable.
With 3 tools, the set is appropriately scoped for the invoice sending workflow: pre-check, creation, and evidence retrieval. Each tool is necessary and no tool is redundant.
The tools cover the primary workflow (check, send, verify delivery). However, there is no tool for listing sent invoices or directly managing credit notes, which is a minor gap. The core functionality is complete.
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 Belgian B2B: pass the recipient identifier and scheme and learn if they are a registered Peppol participant. For Belgium use scheme 0208 with the 10-digit enterprise number (KBO/BCE), or 9925 with the VAT number BE0xxxxxxxxx. 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 0208 (Belgian enterprise number). Use 9925 for a Belgian VAT number. | |
| network | No | Network to check. Default peppol. | |
| identifier | Yes | The recipient Peppol identifier. Belgium: the 10-digit enterprise number (scheme 0208) or the VAT number BE0xxxxxxxxx (scheme 9925). | |
| 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?
Annotations already declare readOnlyHint=true; description adds context that it's a 'safe pre-flight' and explains return values. No contradictions, but doesn't mention potential errors or rate limits.
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?
Single paragraph with clear flow: purpose, details, fallback. Informative but slightly dense; could be broken into bullet points for clarity. Still efficient overall.
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 no output schema, description fully explains return values and behavior. Covers all parameters with context, usage scenarios, and fallback. Complete for agent decision-making.
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 significant value with specific guidance on identifier formats and scheme usage (e.g., '10-digit enterprise number (KBO/BCE)'). Goes beyond schema defaults.
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 tool checks if a business can receive electronic invoices on Peppol, with specific verb 'Check' and resource 'recipient'. It distinguishes from siblings by 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?
Provides explicit when-to-use: 'safe pre-flight for Belgian B2B'. Specifies scheme identifiers and fallback actions when can_receive is false (use create_invoice 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 Belgium B2B electronic invoice over the Peppol network in Peppol BIS 3.0 / EN 16931 format via Storecove (a certified Peppol Access Point). Belgium mandates structured e-invoicing for domestic B2B from 2026-01-01 (grace period to 2026-03-31; near-real-time reporting follows in 2028). Builds the structured invoice JSON from seller + buyer (name, Belgian VAT BE0xxxxxxxxx and/or enterprise number, address) and line items (description, quantity, net unit price, VAT rate 21/12/6/0), computes the Belgian 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. Belgian VAT rates: 21 (standard), 12, 6 (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|12|6|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_vat | No | Seller Belgian VAT number, format BE0xxxxxxxxx (BE + 10 digits). Provide this and/or seller_enterprise_number. | |
| seller_zip | Yes | Seller postal code. | |
| seller_city | Yes | Seller city. | |
| seller_name | Yes | Seller legal/company name. | |
| customer_vat | No | Buyer Belgian VAT number BE0xxxxxxxxx. Provide this and/or customer_enterprise_number (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 BE. | |
| 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 BE. | |
| recipient_peppol_id | No | Optional explicit Peppol participant identifier to route to (overrides deriving from the customer VAT/enterprise 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). Belgium: 0208 (enterprise number) or 9925 (VAT). Default 0208 when routing by enterprise number. | |
| seller_enterprise_number | No | Optional seller Belgian enterprise number (KBO/BCE), 10 digits (0xxxxxxxxx). | |
| customer_enterprise_number | No | Optional buyer Belgian enterprise number (KBO/BCE), 10 digits. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that submission is asynchronous, returns a submission guid, requires your own Storecove credentials, and explains the Peppol delivery process. No contradictions with annotations (readOnlyHint=false, destructiveHint=false); adds context 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?
The description is a single paragraph but well-organized with key information front-loaded. It is somewhat long, but every sentence serves a purpose (e.g., legal context, tips, prohibitions). Minor improvement could be breaking into bullet points, but still effective.
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 large number of parameters (24) and no output schema, the description adequately covers purpose, behavior, return value, and next steps. It provides enough context for an agent to use the tool correctly, including legal and temporal constraints.
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 value by explaining the role of seller_legal_entity_id, the header authentication, and how VAT rates are used, but the schema already provides good parameter descriptions. Still, the description enhances understanding beyond the schema.
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 it sends a Belgium B2B electronic invoice over Peppol, specifies the format (Peppol BIS 3.0 / EN 16931), and distinguishes itself from sibling tools (check_recipient and get_delivery_evidence) by being the actual submission tool.
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?
Explicit guidance: use check_recipient first, then create_invoice, then get_delivery_evidence. Also notes that cancellation is not possible and a credit note is needed instead. No ambiguity about when to use this tool versus alternatives.
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 already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: the asynchronous nature of Peppol delivery, that the tool returns proof and delivery status/receipt, and that polling is expected. No contradictions.
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 four sentences, front-loaded with the main action, then provides context, polling guidance, and safety note. Every sentence adds value with no repetition or fluff.
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 no output schema, the description explains the return values (proof of what was sent, delivery status/receipt from recipient Access Point). Combined with full parameter coverage and usage context (polling, asynchronous behavior), the description is complete for an agent to use the tool correctly.
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% and the schema already describes the guid parameter as 'The submission guid returned by create_invoice.' The description repeats this and adds the endpoint URL (Storecove GET), providing marginal extra context. 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 it fetches delivery evidence for an invoice using a submission guid, referencing the specific API endpoint. It distinguishes from siblings by mentioning create_invoice, which is a sibling, and describing the context of Peppol delivery.
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 explicit guidance: call it shortly after create_invoice, poll until delivery reported, and it's safe to call anytime. It doesn't explicitly mention when not to use or alternatives, but the context is sufficient for an agent to decide.
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!