A reseller opens Claude, asks which of their Turkey eSIMs are low on data, and gets a table back: plan, remaining data, install link. Nobody built an integration to make that happen. They pasted the Zesimo connection URL into the app once and approved access. That is what an agent-native account looks like, and as of this week, yours is one.
Here is what changed. Your Zesimo reseller account is now something an AI assistant can connect to directly and read, over an open protocol, using the tools you already have open. Your catalog, your prices, your wallet, your orders, and your live eSIMs are all readable by the assistant on your side of the login. You build nothing. You approve a connection, and the account answers.
What agent-native means here
Three things shipped, and they work together.
The first is a server. Zesimo now runs a Model Context Protocol (MCP) server at a single URL. MCP is the open standard for letting an assistant call an external service's tools, and a range of clients now speak it. Any of them (Claude, ChatGPT, Cursor, and more than a dozen others listed on your Connect page) can point at that URL and use Zesimo as a tool.
The second is authentication the client handles for itself. The server is an OAuth 2.1 provider. Connect a hosted client and it sends you through your normal portal login, you approve one scope, and the client holds a token from then on. The consent screen names the scope in plain words: "Read-only access to your Zesimo catalog, wallet, orders, and eSIMs." Access tokens last an hour, refresh tokens thirty days, and suspending an account revokes them everywhere. There is no key to copy into a config file unless you want one. The older API-key path still works for scripts.
The third is a skill. The zesimo-esim Agent Skill is a single portable file, published at a public address. It teaches any capable agent the whole reseller workflow: the endpoints, the authentication, the idempotency rule that stops a retried order from charging twice, the field shapes, and the white-label rules. An agent that can read a URL picks it up without you pasting documentation into a prompt.
Underneath those three sit the discovery files, the machine-readable signposts that tell an agent where the server is and how to authenticate before a person is involved.
What an assistant can do once connected
Read, precisely. The MCP server exposes ten tools, and every one of them is a read:
- Browse and inspect packages, and check coverage and your price for any country.
- Read your wallet balance and its full transaction ledger.
- List and open your orders.
- List your eSIMs with their status, remaining data, and hosted install link.
So the questions it answers are the ones you would otherwise open four portal tabs for. What is my price for a 10 GB Japan plan. How much is left in my wallet. Did that order provision. Which of my active eSIMs are under 100 MB. Each maps to a tool, and the answer comes back in the same shape the REST API returns, because the tools call the same code the API does.
One detail earns its own line. Every eSIM the assistant reads carries an install_url: a hosted, branded install page with a QR code and tap-to-install links, ready to hand to the end customer. The assistant fetches it. You forward it.
Read by default, write on purpose
The connection is deliberately read-only. An assistant on it can see everything about your account and change nothing. Placing an order, topping up an eSIM, cancelling, and adding wallet funds all stay on the REST API, behind an explicit call your own systems make.
That is a design choice, not a limitation we forgot to remove. An agent that can spend your wallet needs guardrails you control. The cleanest guardrail is to keep spending out of an ambient chat connection and inside your own code, where you can log it, gate it, and reverse it.
Reading is safe to make effortless. Writing should stay deliberate.
For the agents that do write, the same skill covers it. An agent running in a terminal or an editor, holding the zesimo-esim skill and an API key, can run the full loop. It checks coverage, places an order that a retry cannot duplicate, and returns the QR code or the install link. The read tools and the write API are two doors into one account, and the skill knows both.
How to connect it
Open the portal, go to Connect, and pick your client. Each one gets a one-line install or a single URL, a download of the skill, and an integrity digest if you want to verify it. Approve the OAuth screen once, and the assistant is talking to your account.
If you are not a Zesimo reseller yet, apply for access. The application takes about five minutes, and everything above is waiting on the other side of it.
The integration you were sizing up, the one with the ticket and the sprint and the maintenance behind it, is already built. It is a URL and a login. Paste it into the tool you already had open.
The Zesimo team