Finland Invoices (Peppol BIS 3.0 via Storecove)
Server Details
Finland Peppol/Finvoice e-invoices for AI agents: send, check recipient, get delivery proof.
- Status
- Healthy
- 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 serves a distinct and non-overlapping purpose: pre-flight recipient check, invoice creation and sending, and delivery evidence retrieval. No ambiguity between the three.
All tool names follow a consistent verb_noun pattern in snake_case: check_recipient, create_invoice, get_delivery_evidence. Clean and predictable.
Three tools is minimal but well-scoped for the core workflow of sending a Finnish Peppol invoice. Each tool earns its place, though a slightly larger set could cover additional operations like listing sent invoices.
The tools cover the essential lifecycle: pre-flight check, send invoice, fetch delivery proof. Gaps like cancel or credit note are handled externally (credit note is a new invoice). Minor missing features like managing credentials or listing submissions.
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 Finnish B2B/B2G: pass the recipient identifier and scheme and learn if they are a registered Peppol participant. For Finland use scheme 0037 with the Y-tunnus business ID (OVT), or 0213 with the VAT number FIxxxxxxxx. 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 0037 (Finnish OVT / Y-tunnus). Use 0213 for a Finnish VAT number. | |
| network | No | Network to check. Default peppol. | |
| identifier | Yes | The recipient Peppol identifier. Finland: the Y-tunnus business ID (scheme 0037, OVT) or the VAT number FIxxxxxxxx (scheme 0213). | |
| 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 mark readOnlyHint=true, so safety is known. Description adds that it returns can_receive boolean and explains network behavior (Peppol discovery). Does not contradict annotations. Adds context about return values and error handling 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?
Single paragraph, front-loaded with purpose. Every sentence contributes meaningful information—no filler. Efficiently conveys purpose, usage, parameters, and fallback in a compact form.
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, description explains return values ('can_receive=true/false') and gives fallback guidance. It covers all necessary aspects: what the tool does, when to use, how to set parameters, and what to do with the result. Complete for a read-only discovery 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 descriptions cover all parameters (100% coverage), but description adds context like scheme meanings (0037 for Y-tunnus, 0213 for VAT) and document_types default. Also explains the identifier format for Finland, which is not in schema. Provides extra value beyond 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 'Check whether a business can receive electronic invoices on the Peppol network before you send', specifying the verb (check), resource (recipient), and network (Peppol). It distinguishes from siblings by positioning itself as a pre-flight check for 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 tells when to use ('before you send') and provides fallback actions: 'fall back to recipient_email in create_invoice or ask them to register' for when can_receive is false. Also specifies schemes for Finland, guiding correct parameter selection.
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 Finland B2B/B2G electronic invoice (verkkolasku) over the Peppol network in Peppol BIS 3.0 / EN 16931 format via Storecove (a certified Peppol Access Point). Finland mandates structured e-invoicing for public-sector suppliers (B2G) since 2020-04-01, and a business has the right to require an e-invoice from another business (turnover over EUR 10,000) under the Act on Electronic Invoicing (241/2019) — not a blanket B2B mandate, but Peppol/Finvoice is the Finnish rail. Builds the structured invoice JSON from seller + buyer (name, Finnish VAT FIxxxxxxxx and/or Y-tunnus business ID, address) and line items (description, quantity, net unit price, VAT rate 25.5/14/10/0), computes the Finnish VAT (ALV) 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. Finnish VAT rates: 25.5 (standard, decimal, since 2024-09-01), 14 (food/restaurant), 10 (books/pharmaceuticals/passenger transport), 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 (25.5|14|10|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 Finnish VAT number, format FIxxxxxxxx (FI + 8 digits, derived from the Y-tunnus). Provide this and/or seller_business_id. | |
| seller_zip | Yes | Seller postal code. | |
| seller_city | Yes | Seller city. | |
| seller_name | Yes | Seller legal/company name. | |
| customer_vat | No | Buyer Finnish VAT number FIxxxxxxxx. Provide this and/or customer_business_id (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 FI. | |
| 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 FI. | |
| seller_business_id | No | Optional seller Finnish business ID (Y-tunnus), 7+1 digits, format NNNNNNN-N. | |
| recipient_peppol_id | No | Optional explicit Peppol participant identifier to route to (overrides deriving from the customer VAT/business ID). | |
| customer_business_id | No | Optional buyer Finnish business ID (Y-tunnus), 7+1 digits. | |
| 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). Finland: 0037 (OVT / Y-tunnus) or 0213 (VAT). Default 0037 when routing by business ID. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond annotations: it computes VAT, submits asynchronously (returns a guid, use get_delivery_evidence for status), requires a custom header (x-storecove-key), and explains that invoices cannot be canceled (only credit notes). No contradictions with annotations (readOnlyHint=false, idempotentHint=false).
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 long but highly informative, front-loading the core purpose. Every sentence adds necessary detail. It could be slightly restructured for readability, but it remains efficient and focused.
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 tool's complexity (24 parameters, no output schema, asynchronous Peppol delivery), the description is remarkably complete. It covers purpose, prerequisites, VAT rates, asynchronous delivery, fallback email, mentions sibling tools, and explains the return value (submission guid).
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 baseline is 3. The description adds value by explaining how the invoice is built from seller/buyer data and line items, and provides context for parameter combinations (e.g., seller_vat and seller_business_id). It also gives examples of VAT rates and explains the tax_category default derivation. This is more than minimal.
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 Finland B2B/B2G electronic invoice over Peppol in a specific format (Peppol BIS 3.0 / EN 16931) via Storecove. It uses the verb 'Send' and specifies the resource (e-invoice). It also distinguishes from siblings by mentioning check_recipient and get_delivery_evidence as separate tools for checking and tracking.
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 on when to use the tool: for sending structured e-invoices in Finland, with prerequisites like Storecove credentials and seller_legal_entity_id. It also advises when not to use it (no cancellation, instead issue a credit note) and recommends calling check_recipient first. It explains the Peppol mandate context and the need for a header key.
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?
Discloses async Peppol delivery, polling requirement, and safety to call anytime. Annotations already indicate read-only and open-world; description adds operational details 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?
Three concise sentences with no wasted words: purpose, context, usage guide. Front-loaded and efficient.
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?
Single parameter tool with clear description. Covers what tool does, when to use, what it returns, and async nature. No output schema needed for completeness given simplicity.
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 of guid already states it's the submission guid from create_invoice. Description repeats this without additional depth. High schema coverage (100%) makes baseline 3 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?
Clearly states it fetches delivery evidence for an invoice sent by create_invoice, specifying the action and resource. Distinguishes from siblings check_recipient and 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 says to call shortly after create_invoice and poll until delivery reported. Provides clear context for when to use, though does not explicitly mention when not to use or alternatives.
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!