AI Agents on Mobile Infrastructure: MCP, Proxies and SMS

An AI agent that touches the real web needs three things a language model does not come with: a network identity that platforms accept, a phone number that passes verification, and a way to get both on demand from inside its own tool calls. Most agent stacks ship without any of the three, run from cloud IPs with VoIP numbers, and stall on the first Cloudflare challenge or "we can't verify this number" screen.

This is the explainer for that layer: why cloud infrastructure fails agents, what the Model Context Protocol (MCP) changes, how a mobile-backed MCP server is structured, and how sessions, rotation and verification behave when dozens of agents share the setup. For a worked example on top of it, see how to build a web scraping AI agent.

Why agent deployments fail on cloud infrastructure

An agent framework, a good model and a working tool loop are the visible parts. The failures show up one layer down:

• The IP is a datacenter IP. Agents typically run where the code runs, on AWS, GCP, Hetzner or a VPS. Those ranges are catalogued as hosting ASNs (DataDome on datacenter proxies), and multi-signal bot scoring starts them at a disadvantage before the first request. A Claude Desktop agent fetching through a datacenter proxy typically draws a block from a Cloudflare-protected retail site within a few dozen requests, and because the agent cannot tell a rate limit from an error it keeps retrying until the workflow stalls.
• Rotation breaks the task. Rotating residential pools change the IP mid-session. Anything that holds state (a login, a cart, a multi-step form, a search with pagination) breaks when the IP changes, and the agent's usual response is to start over, which looks even more automated.
• The connection contradicts the story. A browser profile claiming iPhone Safari on top of a Linux server's TCP stack is a detectable mismatch (see how platforms detect proxies). Cloud infrastructure cannot produce a mobile TCP signature.
• The phone number is VoIP. Signup and re-verification flows check the number's line type before sending the code. Twilio, Google Voice and TextNow ranges are classified VOIP, so the agent waits for a code that is never sent (how non-VoIP detection works).
• A human is still in the loop. When verification does happen, someone forwards the SMS or clicks the QR prompt. That is not autonomy, and it does not scale beyond a handful of workflows.

The AI agent market keeps growing regardless (Grand View Research projects roughly $183 billion by 2033), so the gap is not demand for agents. It is that agents are being deployed on infrastructure built for API calls between servers, and asked to behave like people using phones.

What "human-like connectivity" actually means

The requirement is narrower than it sounds. Platforms do not check whether a request comes from a person; they check whether the request's signals are internally consistent with a real device on a real network:

Mobile carrier IPs sit at the trusted end of the ASN spectrum because thousands of real subscribers share each public address behind carrier-grade NAT; a platform cannot blanket-block the range without blocking its own customers. That is the property agents inherit when their traffic exits from a mobile line, and it is the reason mobile proxies rather than residential pools are the fit for agent work (the three proxy types compared).

What MCP changes

The Model Context Protocol is a small, open standard (JSON-RPC 2.0 over stdio or HTTP) for exposing tools, resources and prompts to a model. An MCP client (Claude Desktop, Claude Code, Cursor, or your own runtime) connects to one or more MCP servers, asks each for its tool list, and the model decides at runtime which tools to call. Three properties matter for infrastructure:

• Dynamic tool discovery. The agent does not need the proxy or SMS API baked into its code. It sees tools such as purchase_proxy, rent_number and get_rental in the tool list and uses them when the task calls for it. Swap the server, and the agent picks up new capabilities without a code change; this is what makes quickly assembled ("vibecoded") agents survivable in production, because the fragile integration code lives in the server, not the agent.
• Provisioning inside the task. The agent hits an SMS wall mid-task, calls a tool to get a carrier number, submits it, polls another tool for the code, and continues. No human relay.
• Policy lives in the server. Rotation rules, carrier preferences and session affinity are defined once at the MCP layer; agents inherit them by declaring what they are doing rather than how to route.

VoidMob publishes an open-source MCP server, @voidmob/mcp, that exposes mobile proxies, US non-VoIP SMS, private dedicated numbers and eSIM data plans as tools. Installing it in a client is one line:

{
"mcpServers": {
  "voidmob": {
    "command": "npx",
    "args": ["-y", "@voidmob/mcp"],
    "env": { "VOIDMOB_API_KEY": "vmk_live_..." }
  }
}
}

In Claude Code the equivalent is claude mcp add voidmob -- env VOIDMOB_API_KEY=vmk_live_... npx -y @voidmob/mcp. Set VOIDMOB_SANDBOX=1 instead of a key to exercise the tools against mock data first; the tool list and what each tool does is on the MCP page linked above.

Architecture: agent, MCP server, mobile layer

If you are building your own server rather than using a published one, the shape is the same. The agent talks MCP; the server talks to the mobile layer; every web request the agent makes carries a session identifier so the server can keep it on one IP:

1
# Minimal MCP server that fetches URLs through a mobile proxy with sticky sessions
2
from mcp.server import Server
3
from mcp.types import Tool, TextContent
4
import httpx
5

6
app = Server("mobile-web-access")
7
# Sticky sessions are pinned at the proxy layer, usually by a session token in the
8
# proxy username (provider-specific) or by a dedicated per-session endpoint/port.
9
PROXY_HOST, PROXY_PORT, PROXY_USER, PROXY_PASS = "mobile-proxy-endpoint", 8080, "user", "pass"
10

11
def proxy_for(session_id: str) -> str:
12
  return f"http://{PROXY_USER}-session-{session_id}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
13

14
@app.list_tools()
15
async def list_tools():
16
  return [Tool(
17
      name="fetch_url",
18
      description="Fetch web content via a mobile carrier IP, keeping the same IP per session_id",
19
      inputSchema={"type": "object",
20
                   "properties": {"url": {"type": "string"}, "session_id": {"type": "string"}},
21
                   "required": ["url", "session_id"]},
22
  )]
23

24
@app.call_tool()
25
async def call_tool(name: str, arguments: dict):
26
  if name == "fetch_url":
27
      # httpx >= 0.26 uses proxy=; older versions use proxies=
28
      async with httpx.AsyncClient(proxy=proxy_for(arguments["session_id"]), timeout=30) as client:
29
          r = await client.get(arguments["url"])
30
          return [TextContent(type="text", text=r.text)]

The three layers, and what each owns:

1. Agent runtime decides what to do and which tool to call. It should not know proxy credentials or rotation rules.
2. MCP server owns identities (which IP, number and fingerprint belong to which agent), session affinity, rotation policy, and health signals. It is the control plane.
3. Mobile layer is the carrier hardware: dedicated 4G/5G proxies, carrier phone numbers, eSIM data plans. It is where the trust actually comes from; the server just allocates it.

Sessions, rotation and health for a fleet of agents

The rules that keep a fleet stable are the same rules that keep one agent stable, applied consistently:

• Sticky by default, rotate on policy. Tag every request with a session ID and keep the IP fixed until the agent signals completion or the policy times out. Rotate on signals (a 403, a CAPTCHA, a login prompt on a page that should be public), not on a timer. A useful policy reads like: "for e-commerce monitoring, hold the session up to N requests, rotate on 4xx except 429, and retire an IP that draws two challenges in ten minutes." Agents declare the use case; the server applies the policy and can version it so agents can pin stable behaviour.
• Health from inline signals, not pings. A 60-second ping tells you the proxy is up, not that the IP is clean. Feed every agent response (status, latency, challenge present) back into the server's view of that IP; a soft ban that a liveness poll would surface a minute later shows up in seconds. Aggregated across agents, a cluster of challenges from one carrier range is enough to move the others off it pre-emptively.
• One identity per agent. Each agent gets its own IP, its own number and its own consistent fingerprint. The whole point of dedicated mobile lines is that no other tenant's behaviour leaks into your agent's reputation; sharing a pool between your own agents recreates the problem you paid to avoid.
• Match the layers. The number's country, the IP's country and the browser or client fingerprint should agree. An agent verifying a US account should exit from a US carrier IP with a US number; a UK task from a UK line. eSIM-backed proxies make the geographic side of this a provisioning call rather than a hardware project.
• Tier the inventory. Long-running, high-value agents justify a dedicated line; one-off lookups can use a shared pool. The MCP server is the natural place to make that allocation, because it sees every agent's SLA ("under 150 ms, over 95% success") and the current inventory.

Verification inside the agent loop

Phone verification is where most autonomous flows still stop for a human. Inside an MCP loop it becomes three tool calls: get a number for the target platform, submit it, poll for the code. Two things decide whether that works: the number must be a real carrier line (platforms check line type via lookups such as Twilio Lookup and reject VoIP before the code is sent), and the request that submits the number should come from the same carrier region as the number. VoidMob's SMS numbers are carrier lines for that reason. Details, including how one-time codes, rentals and dedicated monthly numbers differ for agents that need to re-verify the same account for months, are in phone numbers for AI agents, the device layer for agents and building agents with SMS 2FA.

Common failures and what they mean

Where this leaves you

Agents fail on the network layer far more often than on the model layer, and the fix is boring: exit from mobile carrier IPs, verify with carrier numbers, keep one identity per agent, and put the allocation and rotation logic in an MCP server so every agent inherits it. The tooling for that exists and installs in a line; the discipline is in how sessions and identities are managed once it is running.

FAQ