Language models can only act on the outside world through integrations. Before MCP, every AI application integrated every external system pairwise: one custom connector per assistant per service. The Model Context Protocol, introduced by Anthropic in November 2024 and published as an open specification with open-source SDKs, replaces that N-by-M problem with a single protocol. An application that speaks MCP as a client can use any MCP server; a service that ships an MCP server is reachable from any MCP-capable assistant. Major AI vendors beyond Anthropic announced client support during 2025, which is what turned MCP from one company's interface into the de facto standard for agent-to-tool connections.
For communications specifically, MCP matters because it is how general-purpose AI assistants reach a phone system without a bespoke plugin. A CPaaS or business phone platform that exposes an MCP server makes calling, texting, and number management available to any agent the customer already uses.
Architecture: hosts, clients, and servers
- Host
- The AI application the user interacts with: a chat assistant, an IDE, a desktop agent. The host manages permissions and runs one or more clients.
- Client
- A protocol endpoint inside the host. Each client maintains a one-to-one session with one server.
- Server
- The program that wraps an external system and exposes it in MCP terms. A server can run locally alongside the host or remotely as a web service.
Messages are JSON-RPC 2.0. Two transports are specified: stdio for servers launched as local subprocesses, and streamable HTTP for remote servers, with OAuth-based authorization defined for the HTTP transport. Specification revisions are date-versioned, and sessions negotiate a protocol version at initialization.
What a server exposes
| Primitive | Controlled by | What it is |
|---|---|---|
| Tools | The model | Callable functions with typed input schemas: place a call, send a message, search contacts. The model decides when to invoke them; the host enforces user approval. |
| Resources | The application | Readable data identified by URI: a call log, a recording transcript, a number inventory. Context the host can attach to a conversation. |
| Prompts | The user | Reusable, parameterized instruction templates the server offers, surfaced as commands in the host UI. |
MCP applied to a phone system
A phone platform's MCP server maps telephony operations onto those primitives. The result is that an assistant can carry out multi-step communications work conversationally: find the right contact, place or answer the leg, send the follow-up text, and log the outcome, using the same APIs a developer would call, but discovered and invoked by the model at run time.
- Calling tools: place an outbound call from a chosen number, transfer, hang up, start or stop recording, play audio, send DTMF into a menu.
- Messaging tools: send SMS or MMS, list threads, read and search message history subject to the account's 10DLC registration.
- Number and account tools: search available numbers, order a DID, configure forwarding or voicemail, read usage.
- Resources: call logs, transcripts, contact lists, and configuration exposed as readable context rather than actions.
The distinction from an AI receptionist is direction and medium. An AI receptionist is the party on a live audio call, running a speech pipeline in real time. An MCP integration is a control channel: the agent operates the phone system through structured tool calls, and the audio legs themselves are handled by the platform. The two compose: an assistant can use MCP tools to configure, dispatch, or review the calls that a voice agent handles.
MCP compared with the alternatives
| Approach | Integration work | Discovery | Where it fits |
|---|---|---|---|
| REST API + SDK | Custom code per application | Human reads the docs | Deterministic software, CPaaS-style builds, production call flows |
| Proprietary plugins / function schemas | One implementation per AI vendor | Per-vendor registry | Single-assistant products, closed ecosystems |
| MCP | One server, reused by every MCP client | Client lists tools and schemas at run time | Agent access across assistants without per-vendor connectors |
Security and abuse considerations
Giving a language model the ability to place calls and send texts concentrates real-world risk in the tool layer, and telephony tools deserve the strict end of every MCP safeguard. The protocol's authorization model and host-side approval prompts exist precisely because a tool call is an action, not a retrieval.
- Least privilege: scope tokens to the numbers and operations the agent needs. An agent that drafts texts does not need number-porting rights.
- Human-in-the-loop: hosts surface tool calls for approval; keep approval on for actions that dial, text, or spend, and reserve auto-approval for reads.
- Prompt injection: text the model reads (an inbound SMS, a transcript, a contact note) can contain instructions that try to trigger tool calls. Treat message content as data, and gate outbound actions on user confirmation.
- Regulatory exposure: an agent that initiates calls or texts inherits TCPA consent duties and, for texting at scale, 10DLC campaign rules. Automation does not change whose consent is required; it changes how easy it is to violate at volume.
- Auditability: log tool invocations with the initiating conversation, so a disputed call or message can be traced to the instruction that produced it.