Picture two engineers on the same Monday morning, both told: "Make our assistant able to text customers."
The first one opens an SDK, reads a quickstart, writes a wrapper function, writes a second wrapper for inbound messages, adds a webhook server, hand-writes a tool description so the model knows the function exists, tests it, finds the model is passing phone numbers in the wrong format, and rewrites the description. Two days gone.
The second one adds a single server to the assistant's configuration. Then she asks the assistant: "What can you do with messages?" And it tells her.
That difference is the entire story of the Model Context Protocol, and it is a bigger shift for communication than it first appears.
From glue code to discovery
Before MCP, an agent's abilities were whatever its developer wired in. Every new capability meant a new integration: code that calls the API, code that describes the API to the model, code that translates the model's output back into the API. The developer was the matchmaker between a model and every service it touched.
With MCP, the service describes itself. A server announces the tools it offers, what each one does, and what arguments it needs. The agent reads that menu at runtime and decides for itself when a tool is useful.
The whitepaper behind Dial puts it plainly: for agent frameworks using the Model Context Protocol, Dial exposes its interface as tools, with no SDK installation required. The same actions a developer would otherwise code against, such as sending a message, starting a call, sending an email, checking context, are things the agent can find on its own.
> The shift: your code stops being the place where communication is wired in. It becomes the place where you decide what the agent is *allowed* to do.
What changes in practice
Setup time collapses. There is no wrapper to write, no tool schema to hand-maintain, no drift between your description of the API and the API itself. When the server updates, the menu updates.
The agent reads the manual itself. Tool descriptions travel with the tool. A model that has never seen your codebase can still learn what a tool wants and how to ask for it.
Capability follows context. The same assistant can be connected to communication tools in one project and not in another. Giving an agent a phone becomes a configuration choice, not a refactor.
The model chooses the channel. Since the tools are all on one menu, "should I text or email?" becomes a reasoning step instead of an architecture decision made months earlier.
Three scenarios
These are hypothetical, but you can probably recognize them.
The coding assistant that phones home. Imagine a developer, Priya, running a long refactor with an assistant inside her editor. The test suite will take forty minutes. She tells the assistant: "Text me when it finishes, and if it fails, tell me which test." No new code, no integration project. The assistant already has a messaging tool on its menu and uses it.
The scheduling agent with a voice. Imagine Tomas, who runs a small plumbing company. His assistant handles bookings. A customer misses a confirmation, so the assistant decides on its own that a short call is better than a third text. The decision happened at runtime, because both options were on the menu.
The ops agent that escalates. Imagine an agent watching a deployment overnight. When a health check fails twice, it checks who is on call and messages them. When nobody responds, it tries a different channel. The escalation ladder is not hard-coded; it is reasoned.
The part people skip: boundaries
Discovery is wonderful right up until you realize an agent that can find a phone tool can also misuse one. A model with a text-message tool and a vague instruction is a very fast way to annoy customers.
So the interesting engineering question moves. It is no longer "how do I connect the agent to messaging?" It is:
The whitepaper's answer is that those rules belong in the infrastructure layer, enforced before a message leaves, not in the prompt. A prompt that says "never text people who opted out" is a wish. A consent check that blocks the send is a guarantee.
That is the honest framing of MCP for communication: it makes capability easy to grant, which makes policy more important to enforce, not less.
What MCP does not fix
The takeaway
The old question was "can my agent be integrated with a phone?" The new one is "should it be, and under what rules?" MCP turns the first question into a checkbox so that you can spend your time on the second.
Giving Claude a phone used to be a project. Now it is a decision. This is the layer Dial exposes: communication as tools an agent can discover, with the infrastructure holding the guardrails so the model does not have to.