Skip to main content
Glama

Open a secure card payment page for a prepared eSIM plan

create_card_checkout
Idempotent

Create a secure card payment page for an approved eSIM plan and return the link. Payment is only processed when the customer completes it.

Instructions

Open the eSIM platform's secure hosted checkout page for a plan the user prepared for card payment, and return the payment link. THIS CHARGES NOTHING BY ITSELF: it creates a payment page, and the user pays on that page or does not. WHEN: only after the user has been told the plan, the exact amount and the payment method, and has explicitly said yes to paying that amount by card -- "yes, pay by card", "open the payment page", "go ahead". Never call this on your own initiative, and never because the user merely asked to prepare or price a plan. Wanting a quote is not agreeing to pay. FIRST: the user must be signed in, and the plan must already be prepared with prepare_purchase for 'Card'. Read the amount back to them and wait for their answer. If the quote has expired, prepare it again and get their agreement to the new amount -- never start a payment for an amount they have not heard. Pass only the quote reference from your own prepare_purchase result. The plan, the price, the currency and the payment method come from that stored quote, so you cannot supply or change any of them here. NEVER ask the user for a card number, an expiry date, a security code, a cardholder name or any other card detail, and never offer to enter one for them. Card details are entered only on Stripe's own secure hosted page, which the returned link opens in the user's own browser. This server never sees a card. SAFE TO REPEAT: calling this twice for the same prepared quote returns the same payment link and never opens a second page, so the user is never asked to pay twice. AFTER SUCCESS: give the user the link, the plan and the amount, and say plainly that nothing has been charged yet. Then wait -- do not check the payment until they say they have paid or ask you to check, and use check_card_payment_status when they do.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
quote_referenceYesThe quote reference returned by prepare_purchase in this conversation, for the Card quote the user has just explicitly agreed to pay. Never invent, guess or edit one, and never take one from the user -- use the reference from your own prepare_purchase result. If you do not have one, or it has expired, prepare the plan again for card payment and ask the user to confirm the new amount before calling this.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds context beyond annotations: it clarifies that the tool charges nothing by itself, is idempotent (returns same link, no second page), requires user sign-in, and never handles card details. This goes well beyond the idempotentHint annotation and gives a complete picture of side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with clear headings (WHEN, FIRST, NEVER, etc.). Every sentence adds necessary safety or usage information. Slightly verbose, but the complexity and risk of payment tools justify it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all necessary context: prerequisites, step-by-step process, limitations, post-success expectations, and relation to other tools. The output schema handles return structure, and the description explains the semantics of the returned link. Very complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers the single parameter quote_reference well, with concrete instructions. The description reinforces the semantics by emphasizing to use only the reference from prepare_purchase, never inventing or accepting user-supplied references, and explaining the consequences of an expired quote.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it opens a secure hosted checkout page for a prepared eSIM plan and returns the payment link. It distinguishes itself from sibling tools by explicitly referencing prepare_purchase and check_card_payment_status, making its unique role clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit WHEN/FIRST/NEVER guidance. It states to call only after explicit user consent, only with a prepared quote, and to use check_card_payment_status after payment. Also explicitly says never to call on its own initiative or for mere quotes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/samah-jamal-monty/esim-opensource-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server