MCP for AI agents

MCP: the USB-C of AI agents

The Model Context Protocol (MCP) is an open standard — originally from Anthropic, now community-driven — for connecting AI agents to tools and data. Before MCP, every agent-to-service integration was bespoke: custom plugins per assistant, per service, maintained forever. MCP standardizes the handshake: a host (Claude, ChatGPT, your agent) runs an MCP client that talks to MCP servers, each exposing tools (things the agent can do), resources (data it can read), and prompts (reusable workflows).

The analogy that stuck: MCP is USB-C for AI. One connector shape; any device, any accessory. An agent that speaks MCP can use any MCP server — and any MCP server works with any MCP-compatible agent. esimgomobile ships an MCP server exposing the whole platform, so agents can buy connectivity, manage numbers, and run Tele Agent as naturally as calling a function.

The agent loop: ask, tool-call, answer

Watch the loop: the user states intent in natural language. The agent — which has discovered our server's tools at session start — decides browse_plans fits, calls it with {country: "JP"}, and gets structured results. It presents options conversationally, then calls checkout_plan when the user picks. The tool result (a payment URL) becomes the agent's answer.

Three properties make this powerful: discovery (the agent learns available tools and their schemas live — no hardcoded integration), composition (multi-step tasks chain tools: browse → checkout → fetch QR → check balance), and grounding (every answer traces to a real tool result, not the model's imagination).

The platform as agent tools

Each tool mirrors a REST endpoint from the API guide: browse_plans → GET /api/catalog, checkout_plan → POST /api/checkout, purchase_number → POST /api/numbers/purchase, configure_tele_agent → POST /api/teleagent/signup, check_balance → GET /api/balance, get_call_summary → call records. Tools carry JSON schemas, so the agent knows exactly what arguments each takes and what it returns — typed, validated, documented in-band.

The design principle: tools are verbs at the right altitude. Not "POST to /api/checkout" (too low — the agent shouldn't know HTTP), not "run my business" (too high — unauditable). checkout_plan(plan_id) is the right size: one meaningful action, with a result the agent can explain.

Connecting a client: anatomy of a server config

MCP clients (Claude Desktop, Claude Code, and others) connect to servers via a JSON config: a name, a command to launch the server, and environment for secrets. The shape is standard — here's the pattern with our server:

// MCP client config — illustrative; package name publishes at launch
{
  "mcpServers": {
    "esimgomobile": {
      "command": "npx",
      "args": ["-y", "@esimgomobile/mcp-server"],
      "env": { "ESIM_API_KEY": "${ESIM_API_KEY}" }
    }
  }
}

The API key rides in the environment — never in a prompt, never in a chat log. The server authenticates to the platform with it; the agent never sees it. When the session starts, the client lists the server's tools, and the agent can immediately answer "get me data for Tokyo."

One server, every agent. The same server works in our ChatGPT app, in Claude, and in any MCP-compatible client — build the integration once, and every agent ecosystem gets it:

Build your own: a minimal MCP server

You can also build MCP servers yourself — for your own tools, or to wrap the esimgomobile API with your business logic. The official Python SDK makes a server a few dozen lines:

# Python — minimal MCP server wrapping the esimgomobile API (launching)
import os, requests
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("esimgomobile")
API = "https://esimgomobile.com"
H = {"Authorization": f"Bearer {os.environ['ESIM_API_KEY']}"}

@mcp.tool()
def browse_plans(country: str) -> list:
    """List live eSIM plans for a country code (e.g. 'JP')."""
    r = requests.get(f"{API}/api/catalog", headers=H, params={"country": country})
    r.raise_for_status()
    return r.json()

@mcp.tool()
def check_balance(profile_id: str) -> dict:
    """Live remaining data for an eSIM line."""
    r = requests.get(f"{API}/api/balance", headers=H, params={"profile_id": profile_id})
    r.raise_for_status()
    return r.json()

if __name__ == "__main__":
    mcp.run()  # stdio transport — the client launches this

The docstrings aren't comments — they become the tool descriptions the agent reads when deciding what to call. Write them like you'd brief a smart contractor: what it does, what the arguments mean, what comes back. Good descriptions are the difference between an agent that uses your tools well and one that guesses.

Agents are powerful. Guardrails stay on.

Scoped keys. Issue keys limited to the tools each agent needs — a support agent gets check_balance, not checkout_plan. Least privilege applies to agents exactly as it does to humans.

Human approval for money. Purchases pause for confirmation. The agent prepares the checkout; a human approves it. This single rule eliminates the entire category of "the agent bought what?!" incidents.

Audit everything. Every tool call — arguments, result, timestamp, which agent — goes in the log. When something surprising happens, the log is how you reconstruct it in minutes instead of days.

Deny lists and rate limits. Block tools or destinations per policy, and cap how fast an agent can act. Agents don't get tired, which means they don't naturally slow down either.

Secret hygiene. Keys live in environment variables and secret stores. They never appear in prompts, tool descriptions, or chat transcripts — because all three get logged somewhere.

Before you ask.