Norway Invoices (Peppol BIS 3.0 / EHF via Storecove)
Server Details
Norway Peppol/EHF 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 clear, distinct purpose: checking recipient readiness, creating/sending an invoice, and retrieving delivery evidence. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (check_recipient, create_invoice, get_delivery_evidence), making them predictable and easy to understand.
Three tools is well-scoped for the domain—covering the essential steps of inquiring, sending, and verifying delivery without unnecessary redundancy.
The tool set covers the full lifecycle of sending a Peppol invoice: pre-flight check, submission, and delivery verification. Credit notes are handled via a new invoice, so no missing functionality.
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 Norwegian B2B: pass the recipient identifier and scheme and learn if they are a registered Peppol participant. For Norway use scheme 0192 with the 9-digit organisasjonsnummer. 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 0192 (Norwegian organisasjonsnummer). | |
| network | No | Network to check. Default peppol. | |
| identifier | Yes | The recipient Peppol identifier. Norway: the 9-digit organisasjonsnummer (scheme 0192). | |
| 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?
Discloses that it's a safe, read-only check (aligns with readOnlyHint), explains result semantics (can_receive=true/false, Storecove code OK), and gives fallback. No annotations contradicted.
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 tightly written sentences: one for purpose and endpoint, one for usage and fallback. No wasted words.
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 4 well-documented parameters and no output schema, description covers return value meaning and fallback behavior. Sufficient for safe invocation.
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 documentation is complete (100% coverage), so baseline is 3. Description adds practical context: for Norway use scheme 0192 with 9-digit organisasjonsnummer, enhancing understanding 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?
Clear verb ('Check') and resource ('recipient') with specific context: receiving electronic invoices on Peppol network. Distinguishes from siblings (create_invoice, get_delivery_evidence) by being a pre-flight check.
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 (before sending, safe pre-flight for Norwegian B2B) and provides fallback action if can_receive is false. Specifies country-specific parameters (scheme 0192, 9-digit number).
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 Norway B2B electronic invoice over the Peppol network in Peppol BIS 3.0 / EHF (EN 16931) format via Storecove (a certified Peppol Access Point). Norway is moving to mandatory structured e-invoicing for domestic B2B: the parliament (Stortinget) has adopted the reform and the sending obligation applies from 2027-01-01. Builds the structured invoice JSON from seller + buyer (name, Norwegian VAT NO<9 digits>MVA and/or organisasjonsnummer 9 digits, address) and line items (description, quantity, net unit price, VAT rate 25/15/12/0), computes the Norwegian VAT (MVA) 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. Norwegian VAT (MVA) rates: 25 (standard), 15 (food/groceries), 12 (transport/accommodation and other low-rate services), 0 (zero-rated/exempt/reverse charge). Amounts in NOK. 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, NOK), vat_rate (25|15|12|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 NOK. | |
| 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 Norwegian VAT number, format NO<9 digits>MVA (e.g. NO999999999MVA). 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 Norwegian VAT number NO<9 digits>MVA. 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 NO. | |
| 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 NO. | |
| seller_org_number | No | Optional seller Norwegian organisasjonsnummer (organization number), 9 digits. | |
| customer_org_number | No | Optional buyer Norwegian organisasjonsnummer (organization number), 9 digits. | |
| recipient_peppol_id | No | Optional explicit Peppol participant identifier to route to (overrides deriving from the customer organisasjonsnummer/VAT). | |
| 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). Norway: 0192 (organisasjonsnummer). Default 0192 when routing by organization number. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint false and non-destructive, but description adds crucial details: asynchronous delivery (returns guid), credential needed, VAT computation, and no cancellation. No contradiction 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?
Description is well-structured and front-loaded with purpose, but slightly long due to necessary details (VAT rates, credential, asynchronous behavior). Every sentence adds value; minimal waste given 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?
Covers all key aspects: purpose, format, prerequisites, VAT rules, asynchronous return (guid), follow-up tool, and no cancel. No output schema, but return type is clearly stated. Completeness for a complex tool is excellent.
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?
Despite 100% schema coverage, description adds meaning: explains VAT rate values, required fields context (e.g., seller_legal_entity_id from Storecove), routing logic (vat/customer_org_number), and that invoice_number auto-generates. Significantly enhances 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 the tool sends a Norway B2B electronic invoice over Peppol in specific formats, explicitly naming the network, standard, and access point. It distinguishes from siblings by referencing 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?
Provides explicit when-to-use (sending Norwegian e-invoices), tips (use check_recipient first), exclusions (no cancel, must issue credit note), and context (mandatory from 2027-01-01). Clear guidance on prerequisites like credential and seller_legal_entity_id.
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 and openWorldHint. Description adds valuable context: asynchronous Peppol nature, return content (proof, delivery status/receipt), and polling suitability. 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?
Four sentences, front-loaded with purpose, efficient use of words, no redundancy. Each sentence adds value: purpose, async context, usage guidance, safety note.
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?
Describes input (guid), return type (evidence/receipt), usage pattern (poll). Useful for decision-making. Lacks error conditions or explicit response format, but adequate for a simple retrieval 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% with description 'The submission guid returned by create_invoice.' Tool description echoes this. No additional semantic depth beyond schema, meeting baseline.
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' and specifies the source (submission guid from create_invoice). It distinguishes itself from siblings (check_recipient, create_invoice) by focusing on evidence retrieval after invoice creation.
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 usage guidance: 'Call it shortly after create_invoice and poll until it reports delivery.' Also notes safe to call anytime. Lacks explicit when-not-to-use or alternatives, but 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!