France Payments (Stripe — Cartes Bancaires)
Server Details
France payments for AI agents — Cartes Bancaires 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 targets a distinct operation (create, query, cancel, refund) on distinct resources (payment vs subscription), with no overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_payment_link, query_subscription), making the surface predictable.
With 6 tools, the server is well-scoped for its purpose—covering creation, querying, cancellation, and refund without being bloated or sparse.
The domain (payments and subscriptions) is fully covered: create both link types, query both statuses, cancel subscriptions, and refund payments—no obvious dead ends.
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 already declare destructiveHint=true and idempotentHint=true. Description adds non-obvious context: default is non-destructive (end of period), immediate is destructive. Also mentions fairness, exceeding annotation scope.
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 action, then details. Every word serves a purpose; no filler or repetition.
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 2 parameters, no output schema, and annotations covering idempotency/destructiveness, description sufficiently covers behavior. Could mention idempotency explicitly, but not required.
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 covers both parameters fully. Description adds semantic nuance: 'fair to the buyer' for default, and clarifies id parameter accepts both session_id and subscription_id, which is not in 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?
Clearly states 'Cancel a subscription' with specific verb and resource. Distinguishes default behavior from immediate cancellation, and stands out from sibling tools like 'create_subscription_link' 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?
Provides clear guidance on when to use default (end of period) vs immediate=true, with rationale ('fair to the buyer'). Lacks explicit when-not-to-use or alternatives, but sufficiently directs 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 EUR for France via Stripe (Checkout Sessions). Buyer pays with Cartes Bancaires, 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 discloses key behaviors: returns a hosted checkout URL, payment completes automatically, money flow (buyer→Stripe→merchant), optional invoice creation, and tax ID collection. Annotations (openWorldHint=true, readOnlyHint=false) are consistent; 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?
The description is moderately sized and front-loaded with the core action. Each sentence adds value, though some parts (e.g., payment method details) could be slightly more concise. Overall 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?
Given 6 parameters and no output schema, the description covers authentication, payment flow, optional features, and return value (hosted URL). It explains the payment lifecycle adequately. Minor gaps: does not specify maximum string lengths beyond schema.
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 the purpose of issue_invoice and collect_tax_id in context (VAT-ready invoice, B2B) and mentioning the authentication header, going beyond 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 states the tool creates a payment link in EUR for France via Stripe Checkout Sessions, specifying the verb, resource, currency, country, and payment methods. It distinguishes from sibling tools (e.g., 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?
The description provides authentication guidance (x-stripe-secret-key header) and explains optional parameters (issue_invoice, collect_tax_id). It implies usage context but does not explicitly contrast with siblings like create_subscription_link or query_payment_status.
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 adds significant behavioral context beyond annotations: it explains the checkout flow (buyer enters card once, automatic recurring charges until canceled) and the pre-creation amount check. Annotations provide readOnlyHint and idempotentHint but not these details. Some details like idempotency are omitted.
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 that are front-loaded: first sentence states the core purpose, second provides key behavioral details. No redundant or extraneous content.
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 of 5 parameters and no output schema, the description covers the essential flow (checkout link creation, recurring billing, amount check). It could improve by explicitly mentioning what the tool returns (the checkout URL) and clarifying cancellation 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?
With 100% schema coverage, the description adds value by clarifying that 'amount_eur' is per billing period and that it is validated before creation. This goes beyond the schema's basic description of the field 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?
The description clearly states the verb 'Create' and the resource 'recurring subscription checkout link' with specific billing intervals (monthly/yearly/weekly) via Stripe. This immediately distinguishes it from sibling tools like 'create_payment_link' which would be for 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?
The description implicitly tells when to use by focusing on recurring subscriptions. It mentions policy guardrails ('same owner policy guardrails as payments') and a pre-creation check, but does not explicitly contrast with one-time payment links or state 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_payment_statusARead-onlyInspect
Check whether a France 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?
Describes direct Stripe query, pull-based nature, and behavior for paid status and conditional invoice fields. Adds significant context beyond annotations (readOnlyHint, 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, no redundant words. Efficiently conveys core purpose and key details.
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 input, behavior, and output details (paid boolean, optional invoice fields). No output schema needed; description is sufficient for this simple 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?
Only parameter (session_id) is already well-described in schema (100% coverage). Description reiterates its origin from create_payment_link but adds minimal new semantics.
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 the tool checks France payment status for payments created by create_payment_link. Specifies verb and resource, and distinguishes from siblings by referencing the specific payment method and creation 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?
Indicates pull-based approach as alternative to webhooks, and highlights conditional invoice inclusion. No explicit exclusion of alternatives, but context from sibling tools is sufficient.
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=true, and the description adds behavioral detail by explaining that active=true corresponds to ACTIVE or TRIALING status, and NOT_SUBSCRIBED_YET means incomplete checkout. This adds value 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 sentences, front-loaded with purpose, no redundant information. Every sentence is necessary and clear.
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 query tool with one parameter, no output schema, and annotations providing safety context, the description fully explains input format and output interpretation. 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% for the single parameter 'id', but the description adds semantic detail: it accepts session_id (cs_...) or subscription_id (sub_...), which is not present in 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?
The description clearly states the tool checks a subscription created by a specific sibling tool. It uses a specific verb and resource, distinguishing it from siblings like cancel_subscription or 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 indicates when to use: to check subscription status. It explains accepted input formats (session_id or subscription_id) but does not explicitly state when not to use or name alternatives. However, sibling context provides differentiation.
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?
Annotation destructiveHint=true is consistent with refund description. Adds context about the amount being checked before gateway interaction, but does not disclose potential side effects like idempotency or reversibility beyond than given.
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 the core action, efficient and without 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?
With 2 parameters fully described in schema, no output schema, and annotations present, the description adequately covers the tool's behavior and constraints.
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 clarifies the amount parameter's default behavior (full refund) and optional use for partial refund, 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?
The description clearly states the tool refunds a paid payment and associates it with create_payment_link, distinguishing it from siblings create_payment_link and query_payment_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?
Provides explicit guidance on full vs partial refund by default vs passing amount, and mentions the guardrail x-agentpay-max-amount, but does not cover when not to use the tool or alternatives.
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!