Luxembourg Invoices (Peppol BIS 3.0 via Storecove)
Server Details
Luxembourg 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 distinct purpose: checking recipient eligibility, creating an invoice, and fetching delivery evidence. No overlap in functionality.
All tools follow a consistent verb_noun snake_case pattern (check_recipient, create_invoice, get_delivery_evidence), making them predictable.
Three tools cover the essential workflow (pre-flight check, send, status). The count is appropriate for a focused invoicing server, though a few more optional tools could be added without bloat.
The set covers the core invoice sending process end-to-end. Minor gaps exist (e.g., no credit note tool, no bulk operations), but for a single-invoice workflow it 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 Luxembourg B2B: pass the recipient identifier and scheme and learn if they are a registered Peppol participant. For Luxembourg use scheme 9938 with the VAT number LUxxxxxxxx. 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 9938 (Luxembourg VAT number). | |
| network | No | Network to check. Default peppol. | |
| identifier | Yes | The recipient Peppol identifier. Luxembourg: the VAT number LUxxxxxxxx (scheme 9938). | |
| 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 and openWorldHint=true. The description adds specific behavioral details: returns can_receive=true when 'Storecove code OK', false otherwise, and interprets the result. No contradictions with 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 concise (three sentences), front-loaded with the main action, and well-structured. Every sentence adds necessary context without redundancy.
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 covers input formatting, output interpretation, and fallback. For a read-only discovery tool with comprehensive annotations (readOnlyHint, openWorldHint), this provides complete guidance for correct invocation and result 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 description coverage is 100%, so the baseline is 3. The description adds value by providing a concrete example ('scheme 9938 with the VAT number LUxxxxxxxx'), clarifying defaults, and explaining how parameters map to the use case. This goes beyond the schema's generic 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 specific verb ('Check whether'), identifies the resource ('electronic invoices on Peppol network'), and provides the geographic/use-case scope ('Luxembourg B2B'). It also implicitly distinguishes from siblings by framing itself as a pre-flight check and mentioning create_invoice as a fallback.
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', 'safe pre-flight') and provides fallback actions ('fall back to recipient_email in create_invoice or ask them to register'). It does not explicitly mention when not to use, but the context is clear enough.
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 Luxembourg B2B electronic invoice over the Peppol network in Peppol BIS 3.0 / EN 16931 format via Storecove (a certified Peppol Access Point). Luxembourg has mandated structured e-invoicing over Peppol for B2G since 2023 (fully in force), and B2B e-invoicing is expected to be legislated around 2026. Builds the structured invoice JSON from seller + buyer (name, Luxembourg VAT LUxxxxxxxx, address) and line items (description, quantity, net unit price, VAT rate 17/14/8/3/0), computes the Luxembourg 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. Luxembourg VAT rates: 17 (standard), 14 (intermediate), 8 (reduced), 3 (super-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 (17|14|8|3|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 | Yes | Seller Luxembourg VAT (TVA) number, format LUxxxxxxxx (LU + 8 digits). Required — Luxembourg parties are identified on Peppol by their VAT number (scheme 9938). | |
| seller_zip | Yes | Seller postal code. | |
| seller_city | Yes | Seller city. | |
| seller_name | Yes | Seller legal/company name. | |
| customer_vat | No | Buyer Luxembourg VAT number LUxxxxxxxx (used to route on Peppol, scheme 9938, 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 LU. | |
| 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 LU. | |
| recipient_peppol_id | No | Optional explicit Peppol participant identifier to route to (overrides deriving from the customer 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). Luxembourg: 9938 (LU VAT number). Default 9938 when routing by VAT number. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses asynchronous delivery returning a submission guid, no cancellation capability, and need to fetch delivery evidence via get_delivery_evidence. Complements annotations (non-readOnly, non-destructive) with crucial operational details.
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?
Detailed but well-structured; front-loaded with primary action and followed by necessary specifics. Minor redundancy but every sentence contributes to understanding for a complex tool.
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?
Comprehensively covers prerequisites, process, return value handling, and interplay with sibling tools. Addresses lack of output schema by explaining what is returned and how to use it.
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. Description adds meaningful context beyond schema, such as explaining VAT rates, required seller_legal_entity_id, and credential header, justifying a 4.
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 Luxembourg B2B electronic invoice via Peppol, specifying format, mandate details, and distinguishing itself from sibling tools like 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?
Explicit usage guidance including when to use (B2B invoicing), prerequisites (Storecove credentials, legal entity ID), tip to call check_recipient first, and note that cancellations require a credit note as a new invoice.
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 declare read-only and open-world hints. Description adds critical behavior: asynchronous nature, returns proof and delivery status, safe to poll. 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?
Two sentences, front-loaded with purpose and method, no redundancy. Every sentence earns its place.
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?
Covers purpose, usage timing, polling behavior, and return content. No output schema, but description sufficiently explains what is returned. Sibling tools listed provide additional context.
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?
Only one parameter 'guid' with 100% schema coverage. Description reinforces its source (create_invoice) and its role in the API path, adding value 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?
Description clearly states the verb 'Fetch', the resource 'delivery evidence', and links to the specific API endpoint. It differentiates from siblings by specifying it is for evidence after invoice sending.
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 timing advice ('call shortly after create_invoice') and polling instruction. Lacks explicit when-not-to-use but gives sufficient context for correct usage.
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!