Czechia Payments (Stripe — cards / Apple Pay)
Server Details
Czechia payments for AI agents — cards / Apple Pay via Stripe. 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.5/5 across 6 of 6 tools scored.
Each tool has a distinct purpose: payment vs subscription, create vs query vs cancel vs refund. Descriptions are detailed and leave no ambiguity.
All tools follow a consistent verb_noun pattern in snake_case (e.g., cancel_subscription, query_payment_status). No deviations.
6 tools is well-scoped for a payment server covering both one-time payments and subscriptions. Neither sparse nor bloated.
Covers the core CRUD-like operations for payments and subscriptions: create, query, cancel, refund. Missing update subscription or pause, but these are minor gaps for the stated domain.
Available Tools
6 toolscancel_subscriptionADestructiveIdempotentInspect
Cancel a subscription. By default the subscription stays active until the end of the current paid period (fair to the buyer); pass immediate=true to cancel right now.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | session_id (cs_...) or subscription_id (sub_...) | |
| immediate | No | true = cancel immediately. Default false = cancel at period end. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true; description adds important behavioral context: default cancellation at period end and immediate option. 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?
Two short sentences: first states purpose, second explains key behavior. Every word adds value, 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?
For a simple mutation tool with 2 parameters and no output schema, the description fully explains purpose, parameter details, and behavioral nuances. No gaps.
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%; description adds value by specifying accepted id formats (cs_... or sub_...) and explaining the immediate parameter's default behavior.
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 'Cancel a subscription' and elaborates on default vs immediate behavior, distinguishing it from sibling tools like create_payment_link or 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 describes when to use immediate=true vs default period-end behavior, but does not mention when to avoid using the tool or refer to alternatives beyond its own options.
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 CZK for Czechia via Stripe (Checkout Sessions). Buyer pays with cards, Apple Pay / Google Pay — whatever is enabled on the Stripe 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-stripe-secret-key; free test credentials from dashboard.stripe.com never move real money). Money always flows buyer→Stripe→merchant; this service never touches funds. Optional: issue_invoice=true auto-creates a VAT-ready invoice (PDF + hosted page, emailed to the buyer) after payment; collect_tax_id=true collects the buyer's business tax ID (e.g. EU VAT number) at checkout and puts it on the invoice.
| Name | Required | Description | Default |
|---|---|---|---|
| amount_czk | Yes | Amount in CZK (decimals allowed), e.g. 150. Minimum 15. | |
| 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. | |
| issue_invoice | No | true = Stripe automatically creates and emails a post-payment invoice (PDF + hosted invoice page). Ideal for B2B / VAT bookkeeping. Note: Stripe charges a small Invoicing fee per invoice issued. | |
| collect_tax_id | No | true = ask the buyer for their business tax ID (e.g. EU VAT number) on the checkout page; it appears on the invoice. Combine with issue_invoice for a VAT-compliant receipt. | |
| customer_email | No | Optional buyer email. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: payment auto-completes, service never touches funds, and optional features like invoice and tax ID collection. Annotations already indicate it's a mutation (readOnlyHint=false), so the description adds valuable detail 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 thorough and well-structured, with each sentence providing useful information. It is slightly lengthy but still efficient, earning a 4.
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 (6 parameters, no output schema), the description covers creation, behavior, credentials, optional features, and consequences comprehensively. It leaves no major gaps.
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 input schema has 100% coverage, so each parameter is already described. The description adds extra context (e.g., Stripe Invoicing fee) that enhances understanding beyond the schema. A score of 4 reflects this added value.
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 creates a payment link in CZK for Czechia via Stripe Checkout Sessions, specifying the currency and region, which distinguishes it from sibling tools like create_subscription_link.
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 explains when to use the tool (create a payment link) and provides guidance on credentials and optional invoice/tax ID features. It does not explicitly state when not to use it, 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_subscription_linkAInspect
Create a recurring subscription checkout link (monthly/yearly/weekly billing) via Stripe. The buyer opens the URL, enters their card once, and is then charged automatically every period until canceled. Amount is per billing period in the local currency major unit. Respects the same owner policy guardrails as payments (the per-period amount is checked before anything is created).
| Name | Required | Description | Default |
|---|---|---|---|
| interval | No | Billing period. Default "month". | |
| amount_czk | Yes | Amount charged per billing period (local currency major unit) | |
| description | Yes | What the subscription is for (shown to the buyer, <=200 chars) | |
| success_url | No | Optional https URL to send the buyer to after subscribing. | |
| customer_email | No | Optional buyer email (pre-filled at checkout; receipt goes there). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it explains the checkout process (buyer enters card once, charged automatically each period), the amount meaning, and guardrails. This adds value without contradicting annotations (readOnlyHint=false, destructiveHint=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?
Four sentences, each serving a distinct purpose: purpose, process, amount clarification, guardrails. Front-loaded with the core action. No redundant or superfluous 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?
For a 5-parameter tool with no output schema and adequate annotations, the description covers core behavior, guardrails, and parameter context sufficiently. No major gaps; an agent can correctly invoke the 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?
With 100% schema coverage, baseline is 3. The description clarifies that amount_czk is 'per billing period in local currency major unit' and description is 'shown to the buyer, <=200 chars'. However, it omits 'day' from interval enumeration (schema includes it), a minor gap. It does not add deep semantics 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?
The description states the specific verb 'Create' and resource 'recurring subscription checkout link', and mentions the billing period options (monthly/yearly/weekly), clearly distinguishing it from siblings like create_payment_link (one-time) and cancel_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?
The description provides clear context about using this for recurring billing via Stripe and mentions guardrails ('same owner policy guardrails as payments'). It implies when to use but does not explicitly state when not to use or list alternatives, though sibling context clues exist.
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 Czechia payment (created by create_payment_link) has been paid. Queries Stripe directly — pull-based, no webhook needed. paid=true when status is PAID. If the payment was created with issue_invoice=true, the result also includes invoice_url and invoice_pdf once paid.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session_id returned by create_payment_link |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds concrete behavior: paid=true status, invoice_url/invoice_pdf when issue_invoice=true. Complements readOnlyHint and openWorldHint 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?
Three sentences covering purpose, mechanism, and conditional output. No unnecessary 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?
For a simple tool with one required parameter and no output schema, description fully covers input, output conditions, and usage scenario.
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% and description does not add details beyond schema's session_id description. Baseline score.
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 verb 'check', resource 'payment status', and links to sibling 'create_payment_link'. Distinct from siblings like refund_payment.
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 describes pull-based query without webhook, implying real-time check. Could mention when to use webhook instead, 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.
query_subscriptionARead-onlyInspect
Check a subscription created by create_subscription_link. Accepts the session_id (cs_...) or subscription_id (sub_...). active=true when the subscription is ACTIVE or TRIALING; NOT_SUBSCRIBED_YET means the buyer has not completed checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | session_id (cs_...) returned by create_subscription_link, or subscription_id (sub_...) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds useful behavioral context beyond those: it explains the meaning of active status and the NOT_SUBSCRIBED_YET state. 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?
Two sentences, no waste. Every word adds clarity: the input format, response interpretation, and relationship to create_subscription_link are all efficiently communicated.
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?
With no output schema, the description adequately explains the key response states (active, NOT_SUBSCRIBED_YET). It could mention error handling or missing subscriptions, but for a simple status check, it's sufficiently 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that the id parameter can be either a session_id (cs_...) or subscription_id (sub_...), which goes beyond the schema description.
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 it checks a subscription created by create_subscription_link, distinguishing it from sibling tools like cancel_subscription or create_payment_link. Verb 'Check' and resource 'subscription' are specific and unambiguous.
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?
Description specifies acceptable inputs (session_id or subscription_id) and explains response values for active=true and NOT_SUBSCRIBED_YET. While it doesn't explicitly state when not to use, the context is clear given the sibling tools.
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. | |
| session_id | Yes | The session_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?
Discloses refund behavior (full vs partial), policy checks on amount before gateway interaction, and that it is a destructive mutation (consistent with annotations). Adds meaningful context beyond annotations about the underlying process.
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, no wasted words. Every sentence adds value.
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?
Adequate for a 2-parameter tool with no output schema. Covers refund type, guardrails, and parameter usage. Could mention error conditions or prerequisites, but not necessary 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 already describes both parameters with 100% coverage. Description reinforces that amount is optional and session_id matches query_payment_status, adding subtle context but not significantly 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 it refunds a paid payment created by create_payment_link, distinguishing it from siblings that create or query payments. The verb 'refund' and resource 'payment' are specific and unambiguous.
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 default full refund and optional partial refund with amount parameter. Mentions owner policy guardrails. Does not explicitly state when not to use or provide alternatives, but context is sufficient 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!