Cyprus Payments (Stripe — cards / Apple Pay)
Server Details
Cyprus payments for AI agents — cards / Apple Pay via Stripe. Never holds funds.
- 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.4/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: creating payment links, creating subscription links, querying payment status, querying subscription status, canceling subscriptions, and refunding payments. No overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_payment_link, query_subscription), making them predictable and easy to distinguish.
With 6 tools, the set is well-scoped for a payment/subscription service. Each tool addresses a core operation without unnecessary bloat or missing essentials.
The tool set covers creation, querying, cancellation, and refunding for both one-time payments and subscriptions. Missing features like updating subscriptions or listing payments are minor gaps for this focused 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?
The description adds behavioral context beyond annotations (e.g., default period-end vs immediate cancellation). Annotations already indicate destructiveness and idempotency; no contradiction is present.
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 concise sentences that front-load the core purpose and then elaborate with the key parameter nuance. 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?
The description covers the main behavior and parameter options. It does not mention return values or error handling, but with no output schema, this is acceptable for a straightforward cancellation 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%, and the description largely echoes schema descriptions (e.g., immediate parameter). It does not add substantial new meaning beyond what the schema provides.
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 action ('Cancel') and resource ('subscription'), and distinguishes from siblings like create_payment_link and query_subscription by focusing on cancellation.
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 guidance on when to use the `immediate` parameter (default vs immediate cancellation) but does not explicitly mention when not to use this tool or suggest alternatives among siblings.
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 Cyprus 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_eur | Yes | Amount in EUR (decimals allowed), e.g. 5.0. Minimum 0.5. | |
| 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 extensively discloses behavioral traits: authentication via HTTP header, money flow (buyer→Stripe→merchant), no fund handling by service, automatic payment completion, and optional invoice/tax ID features. This goes far beyond the minimal annotations provided.
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 moderately concise and front-loaded with the core purpose. Each sentence adds unique information, though it could be slightly more compact without losing clarity.
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?
The description covers the tool's return value (hosted checkout URL), authentication, money flow, and optional features comprehensively. It lacks details on error handling or idempotency, but given the external service nature and annotations, this is acceptable.
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 description coverage, baseline is 3. The description adds meaningful context for optional parameters like issue_invoice and collect_tax_id, explaining their business use cases and side effects (e.g., Stripe invoicing fee, VAT compliance). This provides value beyond the 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 the tool creates a payment link in EUR for Cyprus via Stripe Checkout Sessions, with specifics on payment methods and return value. It distinguishes itself from sibling tools like create_subscription_link by focusing on one-time payments.
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 implicitly guides usage by detailing the tool's purpose and features (e.g., one-time payment, VAT invoice), but does not explicitly state when to use this tool vs. alternatives like create_subscription_link, nor when not to use it.
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_eur | 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 discloses key behaviors: the buyer opens a URL, enters card once, and is charged automatically every period until canceled. It also mentions the amount check before creation. This adds significant context beyond the annotations (readOnlyHint, destructiveHint, idempotentHint are false), which do not contradict the description.
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 two sentences with no unnecessary words. The first sentence front-loads the core purpose, followed by a sentence explaining the buyer experience and guardrails. 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?
For a tool with no output schema, the description explains the input and behavior well but does not explicitly state the output (a checkout URL). It assumes knowledge of Stripe's standard behavior. Given the sibling tools and annotations, the description is nearly complete but could mention that the return value is a URL.
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 the baseline is 3. The description adds value by clarifying that amount_eur is per billing period in local currency major unit, and it restates the interval options with a default. It also provides context for success_url and customer_email. The description 'monthly/yearly/weekly' slightly under-represents the 'day' enum option, but this is minor.
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 action (create a recurring subscription checkout link), the provider (Stripe), and the billing cycles (monthly/yearly/weekly). It distinguishes itself from the sibling tool create_payment_link by explicitly mentioning recurring billing and the automatic charging behavior.
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 context on when to use this tool (creating recurring subscriptions) and implies not for one-time payments. It mentions the 'owner policy guardrails' and that the amount is checked before creation, offering some usage guidance. However, it does not explicitly state when not to use or list alternatives beyond the implied contrast with create_payment_link.
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 Cyprus 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 value beyond annotations by specifying pull-based direct Stripe query, condition for paid=true, and additional invoice fields. No contradiction with readOnlyHint and openWorldHint.
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, no wasted words. Efficiently conveys all 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?
Covers main functionality, condition for paid, and optional invoice fields. Lacks details on error handling or return format for invalid session_id, but acceptable for a 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 already covers the parameter ('The session_id returned by create_payment_link') with 100% coverage, so the tool description adds no new parameter-specific information beyond that.
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 checks Cyprus payment status, specifies it queries Stripe directly (pull-based), and defines when paid=true and additional fields for invoiced payments. Differentiates from sibling tools like create_payment_link and 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 states when to use: after create_payment_link to check payment status. Implies no webhook needed. Does not explicitly mention when not to use, but context with siblings makes it 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 declare readOnlyHint and openWorldHint. Description adds concrete behavior: active=true for ACTIVE or TRIALING, NOT_SUBSCRIBED_YET for incomplete checkout. 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, each necessary and front-loaded. No fluff, clearly 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?
For a simple read tool with one parameter and no output schema, the description covers key return field. Could briefly mention other possible return fields, but openWorldHint mitigates.
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 the description reinforces the parameter's purpose with examples of ID prefixes, adding value beyond the 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 the tool checks a subscription created by create_subscription_link, specifying the resource (subscription) and action (check). It distinguishes from siblings like query_payment_status 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?
Describes when to use this tool—to inspect a subscription after creation. Specifies valid ID formats (session_id or subscription_id). Lack of explicit when-not-to-use is minor given context.
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?
The description adds value beyond annotations by explaining that refunds respect x-agentpay-max-amount guardrails and that the amount is checked before gateway processing. This behavioral context is helpful. 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 filler, front-loaded with key action and default behavior. Every sentence earns its place.
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 two parameters and 100% schema coverage, the description is complete: it specifies default behavior, optional parameter, guardrails, and relationship to other tools. No output schema needed.
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?
While schema covers 100% of parameters, the description adds context: session_id is the same as used in query_payment_status, and amount is explained as optional partial refund. This aids understanding beyond the 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 explicitly states 'Refund a paid payment' and specifies the resource (payment created by create_payment_link). It distinguishes itself from siblings like cancel_subscription and create_payment_link by the action and resource.
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 tells when to use the tool (to refund paid payments) and mentions that it respects owner policy guardrails. It also contrasts full vs partial refund. However, it doesn't explicitly state when not to use it or compare to alternatives like cancel_subscription.
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!