Model Context Protocol is a standard way for an AI client to discover and call tools. Instead of a model writing HTTP requests into a prompt and hoping, the client asks a server what it can do, gets back a list of tools with input schemas, and calls them like functions.
For a messaging platform that changes the shape of the work. An agent that can call email_send does not need an API key pasted into a conversation, does not need to be taught the request body, and cannot get the base URL wrong.
What does Bird's MCP server let an agent do?
More than send. The toolset spans every channel Bird runs plus the setup around them, which is the part people do not expect: an agent can get a channel ready, not just use one.
Sending and reading covers email, SMS and WhatsApp with the same shape, a send, a batch send, a read and an event list, plus a full WhatsApp template authoring surface. Verify has three tools that mirror its three public operations: start a verification, check a code, advance to the next channel.
Getting ready to send is the interesting half. There are tools to add a sending domain and return the DNS records to publish, re-check them once you have, claim an SMS sender and report what a country demands of it, register US A2P traffic through the 10DLC brand and campaign tools, search and buy a number, and ask whether WhatsApp will accept a number before you order it. There are also tools that report the organization requirements gating any of that, so an agent can find out why it cannot buy a number rather than failing at the attempt.
One gap is worth knowing because it is deliberate: no MCP tool places a voice call. Voice tools read calls back and mint the credential a SIP client authenticates with; placing a test call is a CLI command.
How do I connect one?
Two ways, and most people want the first.
Hosted, at mcp.bird.com. A URL and a browser sign-in. Nothing to install, no CLI, no API key. Supported clients include Claude Code, Cursor, VS Code, Codex, Claude Desktop and ChatGPT.
Local, over stdio. bird mcp runs the same tools on your machine inside the CLI, which suits offline use, shell agents, or wanting the process to be yours.
Both serve the identical curated toolset. They differ only in where the process runs and how it authenticates, so the choice is operational rather than a difference in capability.
Note what the hosted path means for credentials: you sign in as a person and the tool acts with a subset of your own permissions, rather than holding a workspace key. That is the same delegated model the CLI uses, and it is why an agent connected this way cannot outlive your access or exceed it.
What stops an agent doing damage?
Two things, plus one common assumption that is not one of them. All three are worth knowing before you point a model at your production workspace.
The surface is curated. It is not a generated wrapper around every operation; each tool is scoped to a task an agent actually performs. So the blast radius is smaller than the API's by design.
Destructive tools are annotated, so a host can ask before running them. Removing an email suppression is the clearest example: it is marked destructive because removing one without a reason damages sender reputation, which is exactly the kind of harm a confident model would do quietly.
Publishing is not gated. It is tempting to read the draft-then-submit shape of email templates as a review step, and it is not one. The agent holds both calls, and a submit makes that version the live one used by sends, so "let the model draft it" does not stop short of "let the model publish it". The annotations do not slow that down either: replacing the fields of a resource is not classed as destructive, so a host has nothing to ask about. What protects you here is your host's confirmation policy, not something Bird withholds. WhatsApp is the case people have in mind, and only because a submit there sends the version to Meta for review.
The bound that does hold everywhere is the credential above: a tool acts with a subset of your own permissions, so an agent cannot do anything you could not do yourself.
MCP or the CLI?
Same surface, same auth model, different callers.
For a shell-capable agent, the CLI is leaner: JSON output, semantic exit codes, and far fewer tokens per operation, which matters when the model pays for every character it reads. MCP is for hosts that call tools rather than run shells, and the hosted endpoint reaches the ones that cannot execute a binary at all.
You do not have to choose in advance. The hosted URL needs no install, and bird mcp is already present once the CLI is.
One habit worth forming: read the tool inventory from your client rather than from any page, including this one. Your client lists the live names, descriptions and input schemas, and that listing is authoritative. A tool count written into a document is stale the next time the surface grows.
MCP server has the per-client connection snippets and the full tool listing by area, and the CLI for agents covers the other caller.