Germany Payments (Mollie — Klarna / SEPA)
Server Details
Germany payments for AI agents — Klarna / SEPA via Mollie. Never holds funds.
- 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 7 of 7 tools scored.
Each tool addresses a distinct action: subscription activation, cancellation, payment link creation, subscription link creation, status queries for both payments and subscriptions, and refunds. No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., activate_subscription, create_payment_link, query_payment_status), making them predictable and easy to understand.
With 7 tools, the set is well-scoped for handling both one-time payments and recurring subscriptions, covering creation, activation, querying, cancellation, and refunds without unnecessary bloat.
The tool surface covers the full lifecycle of payments and subscriptions except for listing tools (e.g., list_subscriptions or list_payments) and potentially updating subscriptions, but these are not critical for core workflows.
Available Tools
7 toolsactivate_subscriptionAIdempotentInspect
Second step of the Mollie subscription flow. After the buyer has opened the create_subscription_link URL and paid the first payment (which authorizes the mandate), call this with the customer_id and payment_id that create_subscription_link returned. If the mandate is now valid it creates the recurring subscription (for the periods after the first payment) and returns subscription_id (sub_...). If the buyer has NOT finished authorizing yet, it does NOT error — it returns activated=false with a readable mandate_status so you can keep polling (call query_subscription, wait ~20s, then call activate_subscription again). Idempotent: if the subscription already exists it returns the existing one. The plan parameters (amount / period / interval / total_count) were stored on the first payment, so you do not re-supply them here.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | The payment_id (tr_...) returned by create_subscription_link (it carries the stored plan parameters). | |
| customer_id | Yes | The customer_id (cst_...) returned by create_subscription_link. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining non-error behavior on unready state (returns activated=false), idempotency (returns existing subscription), that plan parameters are stored on first payment, and that it returns subscription_id. 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 well-structured and front-loaded, with each sentence providing useful information. While slightly verbose in the idempotency note, it remains 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?
Covers all necessary context: prerequisites, two-step flow, polling behavior with timeout, idempotency, return values, and what not to supply. Despite no output schema, the description explains the return format adequately.
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?
Both parameters are described as coming from create_subscription_link, with payment_id explicitly noted as containing stored plan parameters. This adds context beyond the schema 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 positions this as the second step in the subscription flow, detailing its function (trigger recurring subscription creation after first payment). It distinguishes from sibling tools like create_subscription_link and query_subscription by specifying when to call it.
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 call (after buyer paid and authorized mandate) and when not to (if not finished, it returns activated=false, so keep polling with query_subscription and wait ~20s). Also highlights idempotency, so no need to worry about calling multiple times.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_subscriptionADestructiveInspect
Cancel a Germany subscription so it stops charging. Pass the customer_id (cst_...) and the subscription_id (sub_...) from activate_subscription / query_subscription. Mollie cancellation is immediate — no further billing periods are charged. (If the buyer never authorized the mandate, there is nothing to cancel; just let the first payment expire.)
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes | The customer_id (cst_...) the subscription belongs to. | |
| subscription_id | Yes | The subscription_id (sub_...) to cancel — get it from activate_subscription or query_subscription. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive, non-read-only, non-idempotent behavior. The description adds that cancellation is immediate with no further billing, and handles the mandate edge case. No 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 sentences, front-loaded with main action, no redundancy. Every sentence adds necessary information.
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 fully covers the mutation's effect (immediate cancellation) and edge case (unauthorized mandate). Complete for agent to understand tool behavior.
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 covers both parameters with 100% description coverage. The description adds value by specifying exactly where to obtain the IDs (from activate_subscription or query_subscription), which aids agent in parameter resolution.
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 cancels a Germany subscription to stop charging, with specific required IDs and sourcing instructions. It distinguishes from siblings like activate_subscription and query_subscription.
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 (pass customer_id and subscription_id from other tools) and when not to (if mandate not authorized, let payment expire). Provides clear context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_payment_linkAInspect
Create a payment link in EUR for Germany via Mollie. Buyer pays with cards, PayPal, Klarna, SEPA bank transfer, and other methods enabled on the Mollie account. Returns a hosted checkout URL the buyer opens to pay — payment completes automatically, no confirm step. Bring your own credentials via HTTP header (x-mollie-api-key; free test credentials from my.mollie.com never move real money). Money always flows buyer→Mollie→merchant; this service never touches funds.
| Name | Required | Description | Default |
|---|---|---|---|
| amount_eur | Yes | Amount in EUR (decimals allowed), e.g. 10. Minimum 1. | |
| description | Yes | What this payment is for (shown to the buyer, ≤200 chars) | |
| success_url | No | Optional https URL to send the buyer to after payment. | |
| customer_email | No | Optional buyer email. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it explains the return type (hosted checkout URL), automatic payment completion, authentication via HTTP header, and money flow. 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?
The description is compact (4 sentences) and front-loaded with the core purpose. Each sentence adds value without redundancy. Well-structured.
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 moderate complexity (4 parameters, no output schema), the description covers all essential aspects: purpose, return value, authentication, financial implications, and test credentials. It is complete for agent 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 description coverage is 100%, providing baseline 3. The description does not add parameter-specific details beyond what the schema already provides, but it reinforces the purpose of the key parameters.
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 creates a payment link in EUR for Germany via Mollie, specifying the currency, region, and payment provider. It distinguishes from the sibling tool 'query_payment_status' which is obviously different.
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 clear context for when to use this tool (e.g., for Germany, EUR, via Mollie). Although it does not explicitly list when not to use it, the sibling tool is distinct and the usage is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_subscription_linkAInspect
Create a recurring subscription in EUR for Germany via Mollie (cards, PayPal, SEPA Direct Debit — whatever recurring methods are enabled on the Mollie account). Mollie recurring is a two-step, honest flow (there is no single call that returns a ready subscription, because the buyer must authorize a mandate first): this tool creates a Mollie customer and a FIRST payment (sequenceType=first) and returns a hosted checkout URL. The buyer opens it once and pays — that first payment IS the first billing period AND authorizes the mandate. Then call activate_subscription with the returned customer_id and payment_id to start the recurring plan for the remaining periods. amount_eur is charged PER billing period. Requires x-mollie-api-key. Respects the same owner policy guardrails (x-agentpay-max-amount / x-agentpay-approval-above) as payments — the per-period amount is checked before anything is created. Money always flows buyer→Mollie→merchant; this service never touches funds.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Billing period. Default "monthly". | |
| interval | No | Charge every N periods (period=monthly, interval=3 = every 3 months). Default 1. (Yearly is billed as 12-month intervals; interval multiplies that.) | |
| amount_eur | Yes | Amount charged PER billing period, in EUR (decimals allowed), e.g. 9.99. Minimum 1. | |
| description | Yes | What the subscription is for (shown to the buyer; also used as the Mollie subscription description, ≤200 chars). | |
| success_url | No | Optional https URL to send the buyer to after they authorize/pay the first payment. | |
| total_count | No | Total number of billing periods to charge, INCLUDING the first payment (e.g. 12 monthly = one year). Omit for an open-ended subscription that renews until cancelled. | |
| customer_name | No | Optional buyer name (stored on the Mollie customer). | |
| customer_email | No | Optional buyer email (Mollie sends receipts there). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: it creates a Mollie customer and first payment, requires x-mollie-api-key, respects guardrails, and explains the money flow. This adds significant context beyond the annotations (readOnlyHint false, openWorldHint true), which already indicate creation and non-read-only behavior.
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 yet dense, with essential information front-loaded. Every sentence adds value—purpose, flow, prerequisites, guardrails—and the structure is logical and easy to follow.
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 complexity (8 parameters, no output schema, multiple sibling tools), the description is complete: it explains the entire process, prerequisites, guardrails, region/currency, and return value expectations (checkout URL, customer_id, payment_id). It sets proper expectations for the two-step flow.
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?
The schema has 100% coverage with descriptions for all 8 parameters. The tool description reinforces parameter roles (e.g., 'amount_eur is charged PER billing period') and explains the workflow, but does not add substantially new semantic meaning beyond the schema's 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 creates a recurring subscription in EUR for Germany via Mollie, explaining it creates a customer and first payment, returning a hosted checkout URL. It distinguishes from siblings like create_payment_link and activate_subscription by outlining the two-step flow.
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 clear when-to-use guidance by explaining the two-step flow and directing to call activate_subscription afterwards. It implies use for recurring subscriptions and differentiates from one-time payments, though it doesn't explicitly list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_payment_statusARead-onlyInspect
Check whether a Germany payment (created by create_payment_link) has been paid. Queries Mollie directly — pull-based, no webhook needed. paid=true when status is PAID.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | The payment_id (tr_...) returned by create_payment_link |
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 it queries Mollie directly and specifies the condition for paid=true, providing behavioral 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 extremely concise with two sentences, front-loading the purpose. Every word adds value with no 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?
Given no output schema, the description adequately explains the return semantics (paid=true when status is PAID). It also specifies the Germany context, making it complete for this simple query 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 description coverage is 100%, so baseline is 3. The description adds value by explicitly stating that payment_id is the one returned by create_payment_link, clarifying the expected input.
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 whether a Germany payment has been paid, specifying the verb (check/query) and resource (payment). It distinguishes from the sibling tool create_payment_link by indicating it's a query 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?
The description provides usage guidance by stating 'pull-based, no webhook needed,' implying when to use this tool instead of relying on webhooks. It also mentions the payment is created by create_payment_link, setting context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_subscriptionARead-onlyInspect
Check a Germany subscription. Pass customer_id alone for an overview: status AWAITING_AUTHORIZATION (buyer has not authorized the mandate yet — keep polling / call activate_subscription), MANDATE_VALID (buyer authorized; call activate_subscription now to start the recurring plan), or ACTIVE (a subscription is running; subscription_id is returned). Pass customer_id AND subscription_id (sub_...) to check one subscription directly: ACTIVE | PENDING | CANCELED | SUSPENDED | COMPLETED, with next_charge_date. Pull-based — no webhook needed.
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes | The customer_id (cst_...) returned by create_subscription_link. | |
| subscription_id | No | Optional subscription_id (sub_...) from activate_subscription to check one subscription directly. Omit for a mandate + subscription overview. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description fully aligns with annotations (readOnlyHint=true) and adds behavioral details: no side effects, returns statuses with actions, and includes next_charge_date for specific subscriptions. 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?
Description is slightly long but well-structured: first sentence states purpose, then explains modes with statuses and actions. Every sentence provides useful information, but minor redundancy could be trimmed.
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 fully explains return values (statuses and next_charge_date) for both modes, along with follow-up actions. Complete for a read-only tool with two parameters.
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%, baseline 3. Description adds value by explaining the origin of each parameter (create_subscription_link for customer_id, activate_subscription for subscription_id) and their role in the two calling patterns, exceeding schema meaning.
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 tool checks Germany subscription status, with two distinct modes (overview vs. specific subscription) and lists possible statuses. It distinguishes from siblings by explaining when to use each mode and what actions to take based on status.
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 each parameter combination: customer_id alone for overview, both IDs for specific subscription. Provides guidance on what to do based on returned status (e.g., 'keep polling / call activate_subscription', 'call activate_subscription now'). Also notes it's pull-based, no webhook needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refund_paymentADestructiveInspect
Refund a paid payment (created by create_payment_link). Full refund by default; pass amount for a partial refund where supported. Refunds respect the same owner policy guardrails (x-agentpay-max-amount) as payments — the amount is checked before anything is sent to the gateway.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Optional partial-refund amount in the local currency major unit. Omit for a full refund. | |
| payment_id | Yes | The payment_id of the paid payment (same id used by query_payment_status) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds context about the same owner policy guardrails (x-agentpay-max-amount) and that the amount is checked before gateway. It also notes partial refund support is conditional ('where supported').
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, no redundant words. The main action is front-loaded. Every sentence adds necessary information.
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 tool with 2 parameters and no output schema, the description covers purpose, partial refund, and guardrails. It lacks mention of return values or failure behavior, but overall is fairly 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?
Both parameters are fully described in the schema (100% coverage). The description adds value by clarifying 'Omit for a full refund' for amount and linking payment_id to query_payment_status, providing relational context.
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 specifies the verb 'Refund' and the resource 'paid payment (created by create_payment_link)'. It clearly distinguishes from sibling tools: create_payment_link creates, query_payment_status queries, refund_payment refunds.
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 states 'Full refund by default; pass amount for a partial refund where supported', and mentions that refunds respect owner policy guardrails. While it does not explicitly list when not to use, the context with siblings makes it clear that this is for refunding paid payments.
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!