Send Texts From Claude Desktop Using a Local MCP Bridge

Someone reads that Claude can "text people" and goes looking for a toggle in Claude Desktop's settings, only to find nothing resembling a messaging feature. That's because the capability doesn't live in the app itself. It lives in a small local process you add through MCP, pointed at a maintained text platform that actually owns a phone line. We set this connection up often enough that we wrote down the exact file, the exact JSON shape, and the test we run before calling it done.

Two things have to exist before editing anything in Claude Desktop. The first is a Beam connection token with the right permissions. Open Beam Settings, then Developer access, then MCP & API, name the connection, and leave read and train selected while adding sending only if you intend to use it right away. Copy the token the moment it appears. It is shown once and expires after 90 days, so paste it somewhere private immediately rather than planning to come back for it later.

The second is Node.js 20 or newer on the machine running Claude Desktop, since Beam's bridge is a small script that runs locally and needs Node to execute. Confirm it with node --version in a terminal before you go any further. Then download Beam's stdio bridge script and save it somewhere you control, such as a dedicated folder outside your Downloads directory so it doesn't get cleaned up by accident. Note the full, absolute path to that file. You'll need it in the next step, and a relative path is one of the most common reasons this setup silently fails to connect.

Desktop apps that support MCP tend to need the stdio path specifically, because they are not running inside a terminal where an environment variable and a single command line are enough. If you later also use Claude Code for the same Beam workspace, that client uses the bearer header path instead and does not need this bridge script at all; our Claude Code setup guide covers that command.

A server showing up in Manage connectors proves the process started and Claude Desktop can see its tools. It does not prove the token points at the workspace you meant, and it does not prove a message will reach a real phone. Those are two separate checks, and skipping the second one is how a demo looks finished while the actual business line is still untouched.

Start with the workspace check from step seven above and read back the result instead of assuming it matches. A connection token belongs to one workspace; it cannot switch to another one if you picked the wrong name during setup. Once that is confirmed, send a real message rather than asking Claude to describe what it would send, and watch for the message's recorded status in Beam. An accepted or queued result is not the same as a message that reached a phone, so check the actual status before telling anyone this is ready.

Most failures trace back to one of three places. A wrong or relative path in args is the most common: Claude Desktop will try to run the command and simply get nothing back, so the connector either never appears or appears with no tools. A missing or expired token is the second: the bridge starts fine, but every call to Beam fails, and the fix is generating a fresh token in Beam and updating the env value. The third is forgetting to fully quit Claude Desktop after editing the file, since the running app does not reread its configuration on its own.

If none of those explain it, check the logs. Claude Desktop writes connector output to ~/Library/Logs/Claude on macOS and %APPDATA%\Claude\logs on Windows, with a file named for your server that holds whatever the bridge script printed before failing (modelcontextprotocol.io: connect to local MCP servers). That log usually names the exact problem rather than leaving you to guess between the three causes above.

Screenshot: the Claude Desktop Settings window with the Developer tab selected, the Edit Config button highlighted, next to a second panel showing the saved claude_desktop_config.json with a single "beam" entry under mcpServers, its args and env fields visible.

Connecting Claude Desktop to Beam changes how a message gets written and sent, not the rules about who you are allowed to contact. Beam's iMessage and RCS channels avoid the carrier A2P 10DLC registration process, while SMS fallback, used when a recipient's device or carrier does not support RCS, stays subject to the applicable carrier A2P requirements. Whatever your business already does for consent and opt out requests still applies once Claude is the one drafting the reply. Treat an AI generated message the same way you would treat one a person typed, and keep a human able to step in when a contact asks to stop.

Beam is an independent messaging platform, not an Anthropic or Apple product, and this bridge is one of two documented ways to connect an AI client; see our overview of Claude and iMessage through Beam for the bearer header path and the fuller tool catalog. For the full permission model, rate limits and every tool the bridge can call once connected, our iMessage MCP server guide goes deeper than the single connection covered above. Beam's own iMessage API documentation is the right next stop if you later want a server side integration instead of a desktop client.