PhoneGate

A rooted Samsung Galaxy A14 turned into a controllable GSM gateway, with a browser panel and an MCP server on top.

PhoneGate turns a rooted phone into a gateway to the mobile network. The server side shows the state of the line in a browser, receives the audio of a call, recognises speech, synthesises a reply and feeds it back into the phone's cellular uplink.

It exists so that software, and AI clients in particular, can use a real phone number: answer a call, listen, speak, send and read SMS.

Architecture

Browser ── authenticated /ws ──► FastAPI Web Studio
                                      ▲
                                      │ authenticated /ws/device
                                      │
                              Rust daemon on the phone
                           ┌──────────┼──────────┐
                      telephony   RX/TX audio   SMS/telemetry

AI client ── MCP ──► PhoneGate MCP ── Bearer REST ──► Web Studio

There are three parts:

• The daemon is a Rust program that runs on the phone. It watches telephony state, captures downlink audio, plays synthesised speech into the uplink, and reports SMS and telemetry.
• Web Studio is a FastAPI application on the VPS. It owns the call state, the speech pipeline, the browser panel and the REST API.
• The MCP server exposes typed tools to AI clients. It never talks to the phone directly; every operation goes through the Web Studio API.

Zero-ADB by default

The daemon connects out to the server over WebSocket, so the phone needs no inbound port and no USB cable. ADB over the tailnet remains as a fallback transport for first install, starting the daemon without it, and service work.

After the first bootstrap, new daemon versions are installed through a signed over-the-air update. A Magisk late_start hook starts the daemon after Android finishes booting and refuses to start a second copy.

What a call looks like

1. The phone receives a GSM call; the daemon reports ringing with the caller number.
2. Web Studio records the call with a stable id, a direction and an origin (see call provenance).
3. After answering, the media pipeline streams the caller's voice to the server and turns it into text.
4. A client, a person in the browser or an MCP tool, decides what to say. The server synthesises it and plays it into the call.
5. The call ends, and the full lifecycle is published as events.

Related pages

• Media pipeline: how voice becomes text and text becomes voice.
• Security model: the separate secrets, the edge rules and signed updates.
• MCP tools: everything an AI client can do with the phone.