Skip to main content
Glama
samah-jamal-monty

eSIM MCP Server

by samah-jamal-monty
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Buy a prepared eSIM plan with the user's wallet

confirm_purchase
DestructiveIdempotent

Finalize an eSIM plan purchase from a prepared quote, debiting the user's wallet. Use only after explicit user approval of the amount.

Instructions

Buy the plan in a quote you prepared earlier, paying from the user's eSIM wallet. THIS SPENDS REAL MONEY: it creates an order at the eSIM platform and debits the wallet balance. It cannot be undone from here, and there is no refund tool. WHEN: only after the user has been told the plan, the exact amount and the payment method, and has explicitly said yes to that amount -- "yes, buy it", "confirm", "go ahead". Never call this on your own initiative, never to "check" something, and never because the user merely asked to prepare or price a plan. Wanting a quote is not agreeing to be charged. FIRST: prepare the plan with prepare_purchase, read the amount back to the user, and wait for their answer. If the quote has expired, prepare it again and get their agreement to the new amount -- never confirm 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. Wallet only in this version. A quote prepared for card payment cannot be bought. SAFE TO REPEAT: calling this twice with the same quote reference returns the stored result of the first purchase and never buys the plan twice. AFTER SUCCESS: tell the user plainly that the plan was bought and paid for from their wallet, with the plan name and the amount. IF THE RESULT IS UNCLEAR: if the outcome is reported as unknown or as needing support, never say the purchase succeeded and never say it failed. Do not prepare a new quote for the same plan and do not try to buy it again -- say the platform is confirming it, and offer to check the same purchase again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
quote_referenceYesThe quote reference returned by prepare_purchase in this conversation, for the plan the user has just explicitly agreed to buy. 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 and ask the user to confirm the new amount before calling this.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Tool Definition Quality

A5/5.0
Behavior5/5

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

The description goes beyond annotations by stating that it 'SPENDS REAL MONEY', debits the wallet, and cannot be undone. It also discloses idempotent repeat behavior, unclear-result handling, and post-success actions. 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.

Conciseness5/5

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

The description is long but every sentence adds value, with clear headings for WHEN, FIRST, SAFE TO REPEAT, AFTER SUCCESS, and IF RESULT IS UNCLEAR. It is well-structured and free of fluff.

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?

For a high-stakes purchase tool, the description covers all necessary context: prerequisites, execution, idempotency, post-success reporting, and failure uncertainty. The presence of an output schema means return values need not be described, so this is fully 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?

Schema coverage is 100%, but the description adds crucial context: the quote_reference must come from the agent's own prepare_purchase result, must not be invented or user-supplied, and expired quotes require re-preparation. This significantly constrains the parameter beyond the schema.

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 the tool's function: buying a previously prepared eSIM plan using the wallet. The verb 'buy' plus the resource (prepared plan) and payment method (wallet) make it distinct from siblings like prepare_purchase and create_card_checkout.

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?

The 'WHEN' and 'FIRST' sections provide explicit conditions for use: only after user confirmation of a specific amount, and after prepare_purchase has been called. It also lists exclusions (never on own initiative, never for checking) and differentiates from card payment.

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