Blog · AI · MCP · automation
Testing eSIMs from Claude and Cursor with MCP
How the Model Context Protocol lets telecom QA teams read eSIM test results, analyze failures and run flows from Claude or Cursor, within set permissions.
By SimCheck.ai team · Updated · 5 min read
The Model Context Protocol (MCP) lets an AI assistant such as Claude Desktop or Cursor call tools in other systems. Connected to an eSIM testing platform, it means a QA engineer can ask in plain English which roaming tests failed overnight, what the failures have in common and whether to re-run them, and get answers grounded in real test runs, within permissions the organization sets. This post explains why that matters for telecom QA, what an assistant can and can’t do, and the guardrails worth putting in place first.
Why natural language matters for telecom QA
Telecom test data is unusually wide. A single eSIM test run carries a profile, a home operator, a visited PLMN, a radio technology, a band, signal levels, an APN, a location, timings and, when something breaks, a reject cause. The questions people ask of that data are rarely the ones a dashboard was built for:
- “Did anything change for our European roaming profiles since the partner’s maintenance window?”
- “Are the failures at this site all on one modem model?”
- “Which destinations got slower this month?”
Answering them usually means filters, exports and a spreadsheet. The people asking are often not test engineers at all: roaming managers, support leads and product owners need the answer but don’t know where to click. And the engineers who do know are working in an editor or an AI chat window, not in the test console.
Natural language closes that gap. MCP makes it practical, because the assistant queries the system of record directly instead of guessing from whatever someone pasted into the chat.
MCP in one paragraph
Anthropic introduced MCP in November 2024 as an open protocol for connecting AI applications to external tools and data. A system exposes an MCP server that describes the tools it offers; an MCP client such as Claude Desktop or Cursor connects to it with a key; and the model decides which tools to call to answer your request. The model never gets more access than the key allows.
What an assistant can do with an eSIM testing platform
In SimCheck.ai, the same capabilities are available through the built-in AI assistant in the console and through MCP keys for external clients. They fall into three groups:
- Read. List locations, flows and schedules; look up test results and history; query networks, reports and eSIM inventory.
- Analyze. Review recent failures and point at likely causes, such as a cluster of failures on one visited operator or one modem model.
- Act. Run Quick Tests and flows and create schedules, if the key’s permission level allows it.
Tests an assistant starts are ordinary runs on real modems with real eSIM profiles on live networks. They appear in the same history, with the same logs, decoded signaling and packet captures, as runs started by hand.
Permission levels: least privilege by default
Each MCP key carries exactly one permission level:
| Level | What the assistant can do | Typical holder |
|---|---|---|
| Read Only | Read flows, results and history, locations, networks, reports and eSIM inventory. Cannot start a test. | Support, analysts, anyone exploring results |
| Execute Flows | Everything in Read Only, plus run tests and flows and create schedules. | QA engineers who re-run and schedule checks |
| Full Access | Every operation the integration offers, including managing schedules and configuration. | A small number of platform owners |
Keys can expire after 30 days, 90 days or a year, or never. Only owners and admins can create or revoke them, each key’s last use is visible, and revoking a key cuts off any assistant using it on its next request. MCP keys are separate from API keys, so withdrawing an assistant’s access never breaks your CI scripts.
Inside the console, the built-in assistant adds one more control: it asks for your approval before starting a test, creating a schedule or making any other change. Read-only questions are answered directly.
Example prompts
Start by confirming the connection, then work up from reading to acting:
- “List my SimCheck locations.”
- “Show me every failed test in the last 24 hours, grouped by visited operator.”
- “Look at the most recent failed data test in my roaming group and summarize what went wrong.”
- “Compare success rate by modem model for this week.”
- “Re-run the network connection check on that profile group at the same location, forced to LTE.” (Execute Flows)
- “Schedule the data performance flow every six hours on my roaming cluster.” (Execute Flows)
The first four work with a Read Only key. The last two need Execute Flows, and both start real tests.
Guardrails worth setting up first
Give every person and tool its own key. Shared keys make “last used” meaningless and make revocation painful. Name each key after the tool or person it belongs to.
Choose the lowest level that does the job. Most people only need Read Only. Grant Execute Flows to those who would start the same tests in the console anyway, and keep Full Access rare.
Prefer an expiry date. A 90-day key that has to be renewed is easier to reason about than a key nobody remembers issuing.
Remember that runs cost what they cost. Tests started through MCP use your organization’s tokens exactly like tests started in the console. Tests on your own edge devices don’t consume tokens, which makes them a sensible target for assistant-driven experiments.
Treat analysis as a hypothesis. A language model can summarize a hundred runs faster than a person, and it can still be wrong. Before escalating to a roaming partner, open the run and check the evidence: the decoded signaling, the reject cause and the packet capture. The assistant’s job is to get you to the right run quickly, not to replace it.
Getting started
Setup takes a few minutes. In Settings › AI Integration, an owner or admin creates an MCP key, picks its permission level and copies the key, which is shown once. Paste it into the snippet for your client (claude_desktop_config.json for Claude Desktop, .cursor/mcp.json for Cursor), restart the client and ask it to list your SimCheck locations. A Custom HTTP option covers other MCP clients and your own integrations.
From there, the AI assistant page describes what the assistant can do in the console and over MCP, and the eSIM testing use case shows the tests it can run. Used well, it makes your test history something the whole team can question, not just the person who built the dashboards.