Sweden Invoices (Peppol BIS 3.0 via Storecove)
Server Details
Sweden 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.6/5 across 3 of 3 tools scored.
Each tool has a distinct purpose: pre-flight eligibility check, sending an invoice, and retrieving delivery evidence. There is no functional overlap, so an agent can unambiguously select the correct tool.
All tool names follow the verb_noun pattern (check_recipient, create_invoice, get_delivery_evidence), providing clear and predictable naming without any deviations.
Three tools are appropriate for the narrow domain of Peppol e-invoicing. Each tool covers an essential step (check, send, verify) without redundancy or unnecessary operations.
The tool set covers the core workflow (check, send, verify delivery). Missing a tool for cancellation or listing sent invoices, but cancellation is handled via a new credit note, and the workflow is otherwise complete for the stated B2B/B2G invoicing 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 Swedish B2B/B2G: pass the recipient identifier and scheme and learn if they are a registered Peppol participant. For Sweden use scheme 0007 with the 10-digit organisationsnummer, or 9955 with the VAT number SExxxxxxxxxx01. 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 0007 (Swedish organisationsnummer). Use 9955 for a Swedish VAT number. | |
| network | No | Network to check. Default peppol. | |
| identifier | Yes | The recipient Peppol identifier. Sweden: the 10-digit organisationsnummer (scheme 0007) or the VAT number SExxxxxxxxxx01 (scheme 9955). | |
| 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 declare readOnlyHint=true and openWorldHint=true. The description adds that it's a safe pre-flight, returns can_receive=true/false, and what to do in each case. Could mention potential errors or timeouts, but sufficient for the tool's simplicity.
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 4 sentences, front-loaded with the core purpose. No redundant words. Perfectly concise for a tool with clear functionality.
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 value (can_receive boolean) and expected behavior. Covers all key parameters and provides fallback guidance. Given the tool's simplicity, this is fully complete.
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?
All 4 parameters are described in the schema (100% coverage). The description adds concrete context: specifies identifier format (10-digit org number or VAT number), document_types default, and scheme defaults. 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 clearly states the tool checks if a business can receive electronic invoices on the Peppol network, with a specific focus on Swedish B2B/B2G. It distinguishes itself from siblings by being a safe pre-flight and mentions 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?
Explicitly states when to use (pre-flight) and provides guidance on when not to (if can_receive is false, fallback or ask to register). Provides scheme codes and identifier formats for Sweden. Could have directly contrasted with sibling get_delivery_evidence, but the fallback mention to create_invoice is helpful.
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 Sweden B2B/B2G electronic invoice over the Peppol network in Peppol BIS 3.0 / EN 16931 format via Storecove (a certified Peppol Access Point). Sweden mandates Peppol e-invoicing for public-sector suppliers (B2G) since 2019-04-01; B2B is voluntary today and expected to follow the EU ViDA timeline, so Peppol is already the Swedish rail. Builds the structured invoice JSON from seller + buyer (name, Swedish VAT SExxxxxxxxxx01 and/or organisationsnummer, address) and line items (description, quantity, net unit price, VAT rate 25/12/6/0), computes the Swedish VAT (moms) 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. Swedish VAT rates: 25 (standard), 12 (food/lodging), 6 (books/newspapers/passenger transport), 0 (zero-rated/exempt/reverse charge). Amounts in SEK. 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, SEK), vat_rate (25|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 SEK. | |
| 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 Swedish VAT number, format SExxxxxxxxxx01 (SE + 10-digit organisationsnummer + 01). Provide this and/or seller_org_number. | |
| seller_zip | Yes | Seller postal code. | |
| seller_city | Yes | Seller city. | |
| seller_name | Yes | Seller legal/company name. | |
| customer_vat | No | Buyer Swedish VAT number SExxxxxxxxxx01. Provide this and/or customer_org_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 SE. | |
| 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 SE. | |
| seller_org_number | No | Optional seller Swedish organisationsnummer (organization number), 10 digits (NNNNNN-NNNN). | |
| customer_org_number | No | Optional buyer Swedish organisationsnummer, 10 digits. | |
| recipient_peppol_id | No | Optional explicit Peppol participant identifier to route to (overrides deriving from the customer VAT/organisationsnummer). | |
| 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). Sweden: 0007 (organisationsnummer) or 9955 (VAT). Default 0007 when routing by organisationsnummer. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behaviors: asynchronous submission, returns a submission guid, computes Swedish VAT, requires external credentials, and no cancellation. Annotations already indicate write and open-world, and the description aligns without 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?
The description is detailed but well-organized, front-loading the main action and following with context, instructions, and tips. Every sentence adds value, though length is appropriate for the complexity.
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?
For a complex tool with 24 parameters and no output schema, the description covers purpose, flow, prerequisites, behavior, output guidance, and supplementary tips. No gaps remain for effective use.
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 provides full descriptions (100% coverage), but the description adds valuable context on parameter relationships, defaults, and business logic (e.g., VAT rates, recipient routing). This augments the schema significantly.
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's specific purpose: sending a Sweden B2B/B2G electronic invoice over Peppol via Storecove. It explicitly distinguishes from sibling tools by mentioning check_recipient as a prerequisite and get_delivery_evidence for follow-up.
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 context (B2G mandated, B2B voluntary), prerequisites (Storecove credentials, seller_legal_entity_id), and excludes cancellation, directing users to issue a credit note instead. Also recommends using check_recipient first.
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 that the tool returns 'proof of what was sent and the delivery status/receipt' and states it is 'Safe to call anytime.' 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?
Three sentences, front-loaded with the tool's action, no wasted words. Efficiently conveys purpose, usage, and behavior.
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 asynchronous Peppol delivery context and lack of output schema, the description sufficiently explains the polling behavior, what the tool returns, and that it is safe to call anytime. It compensates well for missing output schema.
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 the 'guid' parameter described as 'The submission guid returned by create_invoice.' The description repeats this but adds no new semantic detail. 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 'Fetch the delivery evidence for an invoice sent by create_invoice', specifying the verb 'Fetch', the resource 'delivery evidence', and the context of use. It distinguishes from sibling tools like create_invoice and check_recipient.
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 usage guidance: 'Call it shortly after create_invoice and poll until it reports delivery.' It indicates when to use (after invoice creation) and that Peppol delivery is asynchronous. It does not explicitly mention when not to use or alternatives, but the context is clear.
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!