The HOAM eSIM MCP Server
HOAM's live catalogue is available to AI assistants over the Model Context Protocol. An assistant with the connector attached can price a plan for the countries someone is actually visiting, name the carrier networks they'll roam onto, and hand back a link to buy it — reading from the same catalogue that prices this website, at the moment it's asked.
Two endpoints, no account, no API key:
https://mcp.hoamesim.com/mcp → Claude
https://mcp.hoamesim.com/mcp/chatgpt → ChatGPT
These are endpoints, not web pages. Opening one in a browser returns a bare error, because they answer JSON-RPC over POST and nothing else — they belong in an assistant's connector field, not the address bar. If you want to confirm the server is up, https://mcp.hoamesim.com/healthz is the one address that will answer a browser.
Setup takes about a minute in either. Claude → · ChatGPT →
What MCP is, briefly
The Model Context Protocol is an open standard for connecting an AI assistant to a live source of data or actions. If you've seen the USB-C comparison, that's the idea: a service implements the protocol once, and any assistant that speaks it can use the service without a bespoke integration on either side.
It went from an open-source experiment to a de-facto standard in about a year, and the major assistant vendors now support it. For a business, the practical consequence is that you expose your data once rather than negotiating a separate integration per assistant.
Why a travel catalogue belongs behind one
Because the alternative is a model guessing, and travel data is exactly the kind that punishes guessing.
Ask an assistant about eSIM prices without a connector and you get an answer assembled from training data. We have watched that go wrong in a specific, instructive way: asked about Portugal, a model produced a price in euros for a data size we don't sell. Fluent, plausible, wrong in two dimensions at once, and attributed to us.
Catalogue data has three properties that make this inevitable without a live lookup:
- It changes. Prices move; a number learned during training is a number from the past.
- It's non-uniform. Every destination sells a different set of data sizes. There is no general rule to fall back on.
- It's combinatorial. A plan for four countries isn't four plans, and the price isn't the sum.
None of that is knowable from the outside. All of it is one call away.
What the server exposes
Five read-only tools. No tool writes anything, and there is no tool that can be made to.
| Tool | What it returns |
|---|---|
list_destinations | Every country and multi-country bundle in the catalogue, filterable by name or alias |
get_plans | Prices for a selection of up to ten destinations, every data size available for it, and a checkout link per size |
get_destination_info | The carrier networks the eSIM roams onto, neighbouring destinations travellers add, and published local events |
suggest_destinations | Destinations commonly combined with the ones given, best match first |
search_help | HOAM's own help centre — validity, hotspot sharing, unused data, device support, installing, topping up, payment |
Every tool declares itself read-only in its annotations, so a host can treat it as safe to call without prompting the user each time. get_plans also returns an interactive plan card in hosts that render them, so the traveller picks a data size from the real list rather than from a model's summary of it.
The rules the data follows
Worth knowing whether you're using the connector or building against it, because they surprise people:
For several destinations, the price is the highest of them — not the sum. Adding a country to a selection barely moves it. This is why naming the countries someone is actually visiting beats reaching for a regional bundle, and it's the opposite of how most eSIM catalogues price.
The data sizes offered are the intersection. Only sizes that every destination in the selection supports are on offer, so a pair can have fewer options than either country alone.
One eSIM, many plans. A HOAM eSIM is installed once and kept; every later trip is a new plan on the same eSIM. It's per device, not per trip — four travellers need four eSIMs, each reusable indefinitely. Most eSIM sellers work the other way round, which is precisely why a model reasoning from general knowledge gets it wrong.
Plans run 30 days.
Security and what it can't reach
The interesting question about any MCP server is what it's able to do on your behalf. Here, deliberately, almost nothing:
- It reads public catalogue data only — the same information a visitor can see on this website.
- It writes nothing. No account changes, no orders, no cancellations. There is no write path to authorise.
- It takes no payment. It returns a checkout link; the transaction happens in the browser on hoamesim.com, under the usual card handling.
- It needs no credentials, so there is nothing to leak. No sign-in, no API key, no OAuth grant.
- It receives only the query. The destinations and trip length it was asked about, not the surrounding conversation.
- It's bounded. Ten destinations per call, and rate-limited per client.
A separate authenticated endpoint exists for HOAM's own in-app assistant. The two public endpoints above have no access to it.
Where this is going
Through 2026 the travel industry has been wiring itself up to assistants at pace — global distribution systems, hotel platforms and, most visibly, corporate travel and expense providers, several of whom now let a business traveller search and book inside a chat window.
Connectivity has been the quiet gap in that picture. Booking a flight through an assistant is useful; landing without working data is still how the trip goes wrong. An eSIM catalogue is a small, well-shaped thing to expose — a read, a price, a link — and it belongs in the same conversation as the itinerary rather than in a browser tab opened at the airport.
Get it working
- Adding the connector to Claude → — the
/mcpendpoint, plus the prompts worth trying - Adding the app to ChatGPT → — the
/mcp/chatgptendpoint and its own setup
Both are free, and neither needs a HOAM account to try.
Frequently asked questions
What is the Model Context Protocol?
An open standard for connecting an AI assistant to a live source of data or actions. A service implements it once and any assistant that speaks the protocol can use it, with no bespoke integration on either side. Most major assistant vendors now support it.
Which endpoint should I use?
https://mcp.hoamesim.com/mcp for Claude and https://mcp.hoamesim.com/mcp/chatgpt for ChatGPT. Both read the same catalogue and return the same prices; they are served separately so each host receives output shaped for how it presents things.
Can the server place an order or change my account?
No. All five tools are read-only and declare themselves as such in their annotations. There is no write path at all — no orders, no account changes, no cancellations. It returns a checkout link and the purchase happens in your browser.
Does it need an API key or a sign-in?
No. The public endpoints serve catalogue information that is already visible on this website, so there is nothing to authenticate and no credential to store. A separate authenticated endpoint exists for HOAM's own in-app assistant, and the public ones cannot reach it.
What does the server actually receive from my conversation?
Only the query it is called with — for example the destinations and the number of days. It has no access to the rest of the conversation, your files, or anything else in the assistant.
Why is a four-country plan not four times the price of one?
Because the price of a selection is the highest of the destinations in it, not the sum. The available data sizes are the intersection of what each destination supports, so a wider selection can also offer fewer sizes than a single country would.
