Israel Payments (Stripe — cards / Apple Pay)
Server Details
Israel 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.2/5 across 6 of 6 tools scored. Lowest: 3.6/5.
Each tool has a clearly distinct purpose: creating payment or subscription links, querying their status, canceling subscriptions, and refunding payments. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_payment_link, query_subscription), making the set predictable and easy to navigate.
With only six tools, the server is well-scoped for its purpose—handling payments and subscriptions in Israel via Stripe. Each tool covers a core operation without unnecessary bloat.
The set covers the essential lifecycle: creating payment/subscription links, querying status, canceling, and refunding. The only minor gap is the lack of an update subscription tool (e.g., change plan or billing period), but the core workflow is complete.
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 significant behavioral detail beyond the annotations (destructiveHint=true, etc.). It explains the default cancellation at period end and the effect of setting immediate=true, which is crucial for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences to convey key information. It is front-loaded with the purpose and immediately provides critical usage nuance.
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?
While the description covers the operation well, it lacks information about the return value or error conditions. No output schema is provided, so agents are left guessing about what the tool returns on success or failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters clearly (100% coverage). The description adds user-friendly context, explaining the default behavior of immediate and why it defaults to false, enhancing understanding.
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 'Cancel a subscription' with a specific verb and resource. It distinguishes between immediate cancel and cancel at period end, which differentiates it from sibling tools 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?
The description provides guidance on when to use the immediate parameter and explains the default behavior as 'fair to the buyer.' However, it does not explicitly state when not to use this tool or contrast it with alternatives like refunds.
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 ILS for Israel 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.
| Name | Required | Description | Default |
|---|---|---|---|
| amount_ils | Yes | Amount in ILS (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. | |
| customer_email | No | Optional buyer email. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) are consistent with the description, which adds details: automatic payment completion, no confirm step, money flow (Stripe never touches funds), and test vs real money distinction. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose and key details. Every sentence adds value without repetition or fluff.
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 (external payment integration) and absence of output schema, the description covers essential aspects: payment flow, credentials, money handling, and return value. Sibling tools are clearly different.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 applies. The description does not add parameter-specific meaning beyond the schema, but it contextualizes the output (hosted checkout URL) and overall flow.
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 'a payment link in ILS for Israel via Stripe (Checkout Sessions)'. It specifies the payment methods (cards, Apple Pay, Google Pay) and distinguishes this tool from siblings 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 clear context on when to use the tool, including payment methods and credential requirements (HTTP header). It lacks explicit 'when not to use' but implies its role vs siblings like creating subscription links.
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_ils | 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 the checkout flow (buyer opens URL, enters card, automatic charges until canceled) and references owner policy guardrails, adding context beyond annotations. Annotations (readOnlyHint=false) are not contradicted.
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. Could be slightly more concise (e.g., merging policy mention), but overall efficient and to the point.
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 5 parameters and no output schema, the description explains the buyer's flow and guardrails but does not mention what the tool returns (e.g., a URL). This is a notable gap for a tool with no output 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 marginal value by clarifying that amount_ils is 'per billing period in local currency major unit', but other parameters like interval or description are already well-defined in 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 creates a recurring subscription checkout link via Stripe, specifying monthly/yearly/weekly billing. It implicitly distinguishes from sibling tools like create_payment_link (one-time) by emphasizing 'recurring', but does not explicitly name alternatives.
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 for recurring billing and mentions policy guardrails, but lacks explicit guidance on when to use vs. alternatives (e.g., one-time payments) or when not to use. It does not state prerequisites or exclusions.
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 Israel payment (created by create_payment_link) has been paid. Queries Stripe directly — pull-based, no webhook needed. paid=true when status is 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?
Annotations already indicate readOnlyHint and openWorldHint. Description adds behavioral details: direct Stripe query, pull-based nature, and the condition for paid=true. Does not contradict 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 extraneous information. Every word 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 read operation with one parameter, the description explains purpose, mechanism, and result condition. Could mention error handling or return structure but sufficient overall.
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 session_id described. Description repeats the relationship to create_payment_link but adds no new meaning 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 action (check payment status), the specific context (Israel payment from create_payment_link), and the mechanism (direct Stripe query). It distinguishes from siblings 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?
Provides context on when to use (after creating payment link) and that it's pull-based, no webhook needed. Does not explicitly state when not to use or alternatives, but context is sufficiently 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 indicate readOnlyHint=true, and the description adds valuable context by explaining the interpretation of 'active' and the special status 'NOT_SUBSCRIBED_YET', enhancing transparency beyond the 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 with no redundancy; purpose is front-loaded. Could be slightly more structured (e.g., separate parameter details from status explanations).
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-only query with one parameter and no output schema, the description adequately covers input format and key output interpretations, though missing error handling details.
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 essentially repeats the schema's parameter description without adding new syntactic details, so 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 'Check a subscription' with specific resource and action, and distinguishes from siblings like create_subscription_link and cancel_subscription by focusing on status checking.
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 what inputs are accepted (session_id or subscription_id) and the meaning of key status values, but does not explicitly state when to use this tool versus alternatives like query_payment_status.
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?
Annotations declare destructiveHint=true; description adds that refunds respect same guardrails as payments and amount is checked before gateway call. Discloses behavioral detail 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, no fluff. First sentence states core purpose and default behavior, second adds important guardrail context. 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?
Covers core refund behavior, optional partial amount, and policy guardrails. No output schema, but for a simple mutation tool with 2 parameters, this is sufficient. Could mention error conditions or idempotency but not critical.
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 good descriptions; description adds value by clarifying that 'omit for a full refund' for amount and references session_id usage via query_payment_status, enhancing understanding.
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 'Refund a paid payment' and specifies the origin (created by create_payment_link). It distinguishes from siblings like cancel_subscription and query_payment_status by focusing on refunding a payment that was already made.
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: full refund by default, partial refund by passing amount. Mentions policy guardrails (x-agentpay-max-amount) that apply. Lacks explicit when-not-to-use or alternatives, but contextual cues are sufficient.
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!