Romania Payments (Stripe — cards / Apple Pay)
Server Details
Romania 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.4/5 across 6 of 6 tools scored.
All six tools have clearly distinct purposes: creating payment/subscription links, querying status, canceling subscriptions, and refunding payments. No overlap or ambiguity.
Every tool follows a consistent verb_noun pattern using snake_case (e.g., create_payment_link, query_subscription, refund_payment), making it predictable and easy to understand.
With 6 tools, the set is appropriately scoped for managing payments and subscriptions. It covers all essential operations without being overwhelming or too sparse.
The tool surface covers core workflows: create, query, cancel, and refund. A minor gap is absence of update functionality (e.g., modifying subscription plans), but the set is largely complete for typical use.
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?
Description aligns with annotations (destructiveHint=true, readOnlyHint=false). Discloses that default cancellation is non-destructive to the current period, and immediate=true is destructive. Adds fairness 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?
Two concise sentences. Each sentence carries essential information. No wasted words. Front-loaded with the main action.
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 no output schema, description adequately explains the action and key parameter. Could mention what the response looks like, but not strictly 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 covers both parameters (100% coverage). Description adds nuance: explains the effect of 'immediate' and the default behavior. Provides value beyond raw 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 ('Cancel') and resource ('subscription'). Distinguishes from siblings like 'query_subscription' and 'refund_payment'. Specifies the default versus immediate 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?
Provides guidance on when to use 'immediate=true' vs default. Implicitly suggests fair treatment by default. Could be more explicit about when not to use, but sufficient for an AI agent.
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 RON for Romania 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_ron | Yes | Amount in RON (decimals allowed), e.g. 20. Minimum 2. | |
| 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?
Description adds significant context beyond annotations: automatic payment completion, money flow (buyer→Stripe→merchant), service never touches funds, credential handling via HTTP header, and optional invoice/tax ID features. 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?
Efficient and well-structured: first sentence captures core purpose, followed by key details (payment methods, return value, credentials, optional features). 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?
Covers main action, return value, payment flow, credentials, and optional features. Missing some details like exact response structure or error handling, but given the tool's complexity and available annotations, it 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?
Schema coverage is 100% with descriptive parameter descriptions. The description adds some value by explaining how issue_invoice and collect_tax_id work together, but this is supplemental, not essential. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a payment link in RON for Romania via Stripe Checkout Sessions, returning a hosted checkout URL. It distinguishes from sibling tools like create_subscription_link (subscriptions) and refund_payment (refunds) by specifying one-time payments in a specific currency/region.
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?
While not explicitly saying 'use this for X, use that for Y', the description implies the use case: one-time payments in RON for Romania. The context of sibling names makes the distinction clear enough, but explicit differentiation would improve clarity.
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_ron | 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?
Discloses that buyer opens URL, enters card once, automatic periodic charges. No contradiction with annotations (readOnlyHint=false, destructiveHint=false). Adds context on guardrails.
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, second sentence adds billing details and behavior. 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?
No output schema, but description explains the checkout flow implicitly. Covers billing, guardrails, and optional parameters. Siblings provided for context.
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 100% with descriptions. Description adds value by stating 'Amount is per billing period in local currency major unit' and clarifying success_url is optional.
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 creates a recurring subscription checkout link via Stripe, with billing periods (monthly/yearly/weekly). Distinguishes from sibling tools 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?
Mentions owner policy guardrails and per-period amount checking, implying when to use. Lacks explicit when-not-to-use or alternatives, but sibling list provides context.
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 Romania 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?
Beyond annotations (readOnlyHint, openWorldHint), the description adds that the tool queries Stripe directly, is pull-based, defines paid=true, and specifies conditional invoice fields. 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 succinct sentences front-load the core purpose and append relevant conditional details. Every word serves a purpose.
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 fully covers behavior, conditions, and output fields, making it self-contained and actionable.
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 a clear parameter description. The tool description reinforces the origin of session_id but adds no new semantic detail 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 clearly states it checks whether a Romania payment has been paid, specifying the backend (Stripe), the pull-based nature, and the condition for paid=true. It distinguishes itself from siblings like create_payment_link and refund_payment by focusing on status query.
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 implies use after create_payment_link and notes pull-based querying, eliminating need for webhook. However, it does not explicitly exclude alternative tools or mention when not to use this tool.
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, so the description's contribution is context about return semantics (active=true meaning ACTIVE or TRIALING, NOT_SUBSCRIBED_YET meaning incomplete checkout). This adds value beyond annotations 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?
Two sentences, front-loaded with purpose and accepted inputs. No extraneous information; every sentence adds value. Ideal conciseness.
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?
Without an output schema, the description explains key return fields (active=true, NOT_SUBSCRIBED_YET) and acceptable id types. It does not cover error handling or all possible statuses, but is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already documents the id parameter. The description adds examples of prefix patterns (cs_..., sub_...), providing additional semantic clarity beyond the schema's generic 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?
The description clearly states the tool checks a subscription created by create_subscription_link, with a specific verb ('Check') and resource ('subscription'). It distinguishes from sibling tools like cancel_subscription and create_subscription_link by focusing on status retrieval.
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 implies usage after creating a subscription via create_subscription_link, but does not explicitly state when not to use it or compare to alternatives like query_payment_status. Sibling tools are listed without guidance, so usage context is implied but not directive.
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?
Adds context beyond annotations: full default, amount check before gateway, policy guardrails. Annotations already indicate destructiveHint=true and readOnlyHint=false, but description enriches with operational details.
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: first sentence defines action and context, second explains default behavior and guardrails. No filler text.
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?
No output schema but description covers core usage and constraints. Missing return value/error info but sufficient for typical invocation. Annotations handle idempotency hint.
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 mentioned in description with usage guidance (omit amount for full refund). Schema coverage 100% but description reinforces and adds 'local currency major unit' 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?
Clearly states 'Refund a paid payment' with specific context (created by create_payment_link). Distinguishes from siblings: create_payment_link and query_payment_status by 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?
Explicitly describes full refund default and partial refund via amount parameter. Mentions policy guardrails (x-agentpay-max-amount) for awareness. Does not explicitly exclude alternatives but siblings are distinct.
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!