I Turned My Android Phone Into an MCP Server — Now My AI Can Text People

Your AI Just Got a Phone

Last week I asked my AI assistant to text my wife that I was running late. It did. From my phone. No Twilio. No third-party API. Just my actual phone number, sending a real SMS, triggered by a natural language request to GitHub Copilot CLI.

The trick? I turned my Android phone into an MCP server.

MCP — the Model Context Protocol — is the open standard that lets AI assistants connect to external tools and data sources. Think of it as USB-C for AI: one standard plug, infinite peripherals. My phone is now one of those peripherals. Copilot CLI connects to it over WiFi, and suddenly my AI can read my messages, look up contacts, control the flashlight, check battery status, take photos, adjust volume, and more — 18 tools in total.

Here’s how I built it, and how you can too.

The Architecture

The stack is surprisingly simple:

GitHub Copilot CLI  →  HTTP/SSE  →  Node.js MCP Server  →  Termux:API  →  Android

Termux is a terminal emulator for Android that gives you a full Linux environment — apt, node, python, the works — without rooting your device. Termux:API is its companion app that exposes Android hardware and system features as command-line tools. termux-sms-send, termux-flashlight, termux-battery-status — each phone capability becomes a CLI command.

My MCP server is the glue layer. It’s a Node.js app running inside Termux that wraps these CLI commands into proper MCP tool definitions — typed inputs, structured JSON outputs, descriptions that help the AI understand what each tool does and when to use it.

Copilot CLI connects via the Streamable HTTP transport at http://<phone-ip>:3000/mcp. That’s it. No cloud relay, no webhook infrastructure. Your phone and your laptop just need to be on the same WiFi network.

The 18 Tools

Here’s what Copilot CLI can do once connected:

Category	Tools	What They Do
Messaging	`sms_list`, `sms_send`	Read inbox, sent, or all SMS messages. Send texts from your actual number.
Contacts	`contacts_list`	Search your contact list by name or list all contacts.
Device	`battery_status`, `wifi_info`, `volume_set`, `vibrate`, `flashlight`	Check battery/WiFi, adjust volume, vibrate the phone, toggle the flashlight.
Clipboard	`clipboard_get`, `clipboard_set`	Read from or write to the system clipboard.
Notifications	`notification_send`	Push a notification to the phone’s notification shade.
Location	`location_get`	Get current GPS coordinates.
Camera	`camera_take_photo`, `camera_info`	Take a photo and save it, or list available cameras.
Media	`media_player`	Play, pause, or stop audio files.
Communication	`call_phone`, `tts_speak`	Initiate phone calls or speak text aloud through the phone’s speaker.

Every tool has typed parameters and returns structured JSON. When you ask Copilot “read my last 5 texts,” it calls sms_list with { "limit": 5, "type": "inbox" } and gets back sender, body, date, and read status for each message.

How a Tool Works

Each MCP tool wraps a Termux:API command. Here’s the pattern — take the flashlight as an example:

server.tool(
  "flashlight",
  "Toggle the device flashlight on or off",
  { enabled: z.boolean().describe("true = on, false = off") },
  async ({ enabled }) => {
    await execTermux("termux-torch", [enabled ? "on" : "off"]);
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify({
            success: true,
            flashlight: enabled ? "on" : "off",
          }),
        },
      ],
    };
  }
);

The execTermux helper handles spawning the child process, capturing stdout, and handling errors. Every tool follows this same pattern: validate inputs with Zod, call the Termux command, return structured JSON.

SMS sending is a bit more interesting — it resolves contact names to phone numbers automatically:

server.tool(
  "sms_send",
  "Send an SMS text message to a phone number or contact name",
  {
    to: z.string().describe("Phone number or contact name"),
    message: z.string().describe("The message text to send"),
  },
  async ({ to, message }) => {
    let phoneNumber = to;
    // If 'to' doesn't look like a phone number, resolve from contacts
    if (!/^[\d+\-()\s]+$/.test(to)) {
      const contacts = JSON.parse(
        await execTermux("termux-contact-list")
      );
      const match = contacts.find((c) =>
        c.name.toLowerCase().includes(to.toLowerCase())
      );
      if (match) phoneNumber = match.number;
    }
    await execTermux("termux-sms-send", ["-n", phoneNumber, message]);
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify({
            success: true,
            to: phoneNumber,
            message,
          }),
        },
      ],
    };
  }
);

So you can say “text Paula that I’m on my way” and the server figures out Paula’s number from your contacts.

Setting It Up

Prerequisites

An Android phone with Termux and Termux:API installed (both from F-Droid — don’t mix with Play Store versions)
Install the Termux:API bridge package and Node.js: pkg install termux-api nodejs-lts
Grant Termux:API the permissions it needs (SMS, contacts, location, camera, phone)

Install and Run

# Clone the repo
git clone https://github.com/htekdev/phone-mcp-server.git
cd phone-mcp-server

# Install dependencies
npm install

# Start the server
node server.js

The server starts on port 3000 and logs your phone’s IP address. You’ll see something like:

📱 Phone MCP Server running on http://192.168.1.42:3000/mcp

Connect Copilot CLI

Add the server to your MCP configuration. On your laptop, edit your MCP config file:

{
  "mcpServers": {
    "phone": {
      "url": "http://192.168.1.42:3000/mcp"
    }
  }
}

Replace the IP with your phone’s actual address. Start a new Copilot CLI session and the 18 phone tools show up automatically. Ask it “what’s my battery level?” and watch the magic happen.

Real Use Cases

This isn’t a toy project. Here’s how I actually use it:

Quick messaging from the terminal. I’m deep in a coding session and need to reply to a text. Instead of picking up my phone: “Hey Copilot, text Mom that we’ll be there at 6.” Done. Hands never leave the keyboard.

Reading messages in context. “Show me my unread messages” during a planning session. Copilot reads them, I can respond to any of them conversationally.

Phone as a notification endpoint. My Copilot Home Assistant already sends Telegram notifications. Now agents can also push Android notifications directly or speak alerts through the phone’s speaker using TTS.

Location-aware workflows. An agent can check my GPS location before making decisions — “Am I at the office or at home?” informs which routine to run.

Quick captures. “Take a photo with the rear camera” from my laptop. The phone snaps a photo and saves it — useful for documenting hardware setups or whiteboard diagrams without unlocking the phone.

What It Can’t Do (Yet)

I believe in being honest about limitations:

Most RCS messages are invisible. Android’s modern messaging protocol (RCS/Google Messages chat features) generally doesn’t expose messages through the standard content://sms content provider that Termux:API reads. You’ll reliably see traditional SMS and MMS, but RCS threads are typically inaccessible. Behavior can vary by device and messaging app, but this is a platform limitation, not a bug in the server.

WiFi-only connectivity. Your phone and laptop need to be on the same network. For remote access, you’d need to set up something like ngrok to tunnel the MCP endpoint — that’s on the roadmap but not included yet.

No incoming message listener. The server can read and send messages, but it doesn’t get push notifications when a new SMS arrives. A future version could use Android’s notification listener service to enable reactive workflows — imagine your AI automatically reading and summarizing new messages as they arrive.

No authentication. The MCP endpoint is open on your local network. This is fine for a home WiFi setup where you trust the network, but don’t expose port 3000 to the public internet without adding auth. The WiFi-only design is a deliberate security boundary.

What’s Next

The foundation is solid — adding new tools is just wrapping another Termux:API command. Some ideas I’m exploring:

ngrok integration for remote access outside your WiFi network
Notification listener to bridge RCS and app notifications into the MCP context
Scheduled routines — “every morning, read me my unread messages” via cron-style agents
Multi-device mesh — combine this with the agent mesh to let phone tools flow across Copilot sessions
Sensor access — accelerometer, gyroscope, ambient light — for context-aware AI behaviors

The broader point: MCP turns anything with an API into an AI-accessible tool. Your phone is just the most personal computer you own. Giving your AI assistant access to it — with you in control — is the natural next step.

The Bottom Line

We’re at an inflection point where AI assistants stop being chat windows and start being actual assistants. Sending a text, checking your battery, reading your messages — these are the mundane tasks that real assistants handle. The Model Context Protocol makes it possible with an open standard, and Termux makes your Android phone the perfect hardware platform.

The entire server is open source: htekdev/phone-mcp-server. Clone it, run it, extend it. If you build a cool tool on top of it, open a PR — I want to see what you build.

If you’re into this kind of thing, check out how I’ve been extending Copilot CLI with custom tools, bridging it to Telegram for mobile access, and building an entire home assistant platform on top of it. The phone MCP server is just the latest piece of a much bigger puzzle.

Resources

phone-mcp-server on GitHub — full source code
Model Context Protocol (MCP) introduction — the open standard
Termux — Linux terminal for Android
Termux:API wiki — all available device APIs
MCP servers in Copilot CLI — configuration docs
Zod — TypeScript-first schema validation