What Mono eSIM MCP does
Mono eSIM MCP gives AI agents an MCP interface for finding and evaluating travel data eSIMs. Agents can list countries and regions, search by destination or city, filter by data allowance, validity, budget, or unlimited-data requirements, and compare a shortlist of two to ten plan IDs. Plan details include price in EUR, coverage, data allowance, validity, availability, and purchase terms.
The server also checks probable eSIM support for phone models and returns matching models and compatibility caveats. It can retrieve purchase terms in English, German, Russian, or Ukrainian, including delivery, validity, refund or withdrawal conditions, and payment information.
How it works
A typical selection flow starts with list_destinations when the location needs discovery, followed by search_plans. The agent can validate a candidate with get_plan, compare selected plan IDs with compare_plans, and check the customer's phone with check_device. Compatibility results can be unknown, so customers should confirm the device EID and carrier-unlock status, particularly for regional variants.
Before checkout, get_terms retrieves the terms to show the customer. prepare_order then creates a signed quote with a 30-minute price lock; it does not create an order, charge a payment method, or issue an eSIM. For a customer-paid flow, create_checkout requires explicit confirmation of the displayed plan and price, accepted terms, and the customer's email. It returns a Stripe Checkout URL, and fulfilment starts only after payment is verified.
Alternative payment flows use payment_capabilities first. The purchase tool requires an explicitly selected buyer mode and payment method. A completed order can be checked with get_order, which requires both the order ID and private order token. After delivery, that response may contain an LPA activation code, QR or installation links, and usage data; these values should be handled as secrets.
Setup and configuration
register_machine creates an offline-sandbox machine identity with a zero-EUR test wallet and returns a one-time mak_test_ API key. The key must be stored securely because it cannot be retrieved again. This identity is used before wallet operations or sandbox purchases and does not create a live payment account.
Sandbox operators can inspect balances and ledger entries with get_wallet, set per-purchase and per-UTC-day limits with set_wallet_limits, and create a Stripe test Checkout funding session with fund_wallet. Funding changes the balance only after a verified test payment. revoke_machine permanently disables the machine's current API key while retaining transaction and ledger history.
Saved-card authorization requires reading card_payment_terms first. create_card_authorization creates an offline-sandbox Stripe SetupIntent after consent; Stripe.js completes it, and sync_card_authorization reconciles the result. These tools do not charge a card. sync_card_payment handles reconciliation for an eligible saved-card order, including a possible Stripe.js or 3-D Secure action.
Tools and capabilities
- Discover destinations and search plans by location, data, validity, price, or unlimited-data status.
- Retrieve, validate, and compare current plan offers without reserving inventory.
- Check probable phone eSIM compatibility and expose model-match caveats.
- Present localized terms and prepare time-limited signed quotes.
- Create customer-paid Stripe Checkout sessions or use enabled sandbox payment methods.
- Manage sandbox machines, EUR-cent wallets, spending limits, test funding, and saved-card permissions.
- Inspect order fulfilment and retrieve activation details after verified delivery.
Limitations and notes
Search results, comparisons, destination listings, and quotes do not reserve inventory. A withdrawn or missing plan should be searched again rather than treated as a cached offer. Payment capability listings can include planned methods, so agents must not assume that a listed method can charge or silently fall back to human Stripe Checkout.
Purchases are in testing, and the sandbox wallet accepts no real money. Reuse the same idempotency key when retrying relevant authorization, funding, checkout, or purchase operations. Never send card PAN or CVC to the server, and do not infer payment success before verification. Revoking a saved-card authorization blocks new purchases but may not stop already reserved or in-flight payments from settling.