Bird's MCP server, CLI and skills give a coding agent the same email, SMS and verification operations you get from the API. One prompt wires all three into the agent you already use.
> send a test to my own address and tell me if it landed
$ curl -fsSL https://cli.bird.com/install.sh | sh
$ bird auth login
Opening your browser to authorize Bird CLI…
{ "workspace_id": "ws_01k…", "region": "eu1",
"credentials_path": "~/.config/bird/credentials.json" }
$ bird email send \
--from "onboarding@messagebird.dev" \
--to "you@example.com" \
--subject "Ping from your agent"
{ "id": "em_3Nf2c", "status": "accepted" }
# accepted is not delivered, so read it back
$ bird email get em_3Nf2c
{ "status": "delivered", "attempts": 1 }
landed in 1.2s. Want me to set up your own domain next?
My order confirmations stopped landing this morning. What happened?
bird · list messages
41 bounced in the last hour, every one of them from acme-mail.dev.
bird · get domain
Found it: the DKIM record went missing at 04:12. It's published again and the domain just re-verified, so your confirmations are landing.
Connect the client you already have
Same URL every time. What changes is where the config lives, who starts the sign-in, and what the answer looks like once it works.
$ claude mcp add --transport http bird https://mcp.bird.com
The patterns that keep it reliable
An agent-shaped API still needs the right loop around it. These are the failure modes that actually break agent integrations, and they read the same whether you drive the MCP server or the CLI.
- 01
One operation per call
Every tool returns structured JSON whose fields the next step checks. Read each exit condition from the previous step's output rather than inferring it.
- 02
Accepted is not delivered
A send returns 202 with status: accepted, which means Bird took the message. Delivery is asynchronous, so read the message back for the real outcome.
- 03
Branch on the exit code, not the message
2 means fix the input, 3 means the id is wrong so don't retry, 4 means re-authenticate. No string matching.
- 04
Find the sender before sending
A from address needs a verified sending domain. DNS propagation is asynchronous, so verifying right after creating almost always still reads pending.
- 05
Retry safely
--dry-run previews the request, --example prints a valid body, and --idempotency-key makes the retry safe to repeat.
An agent can open its own account. Focus on speed and simplicity.
No browser, no password, no dashboard. Three commands take an agent from nothing to a stored credential, and the MCP server exposes the same flow as the signup, verify_email and create_org tools.
$ bird auth signup --email agent@example.com
{ "status": "pending_verification" }
$ bird auth verify-email --code 481920
{ "status": "verified" }
$ bird org create --name "Acme"
{ "org": "org_5Kd21", "region": "eu1", "credential": "stored" }
# the same three steps are the signup, verify_email
# and create_org tools on the MCP server
Where Bird is already fully integrated and connected
Coding agents install the plugin and get the skills natively. App builders connect the same MCP server from their settings, and the agent mints the app's API key itself.
Claude Code. Plugin ships the skills and declares the MCP server.
Cursor. Plugin brings the skills; the server is one config entry.
Codex. Plugin marketplace, then sign in from the shell.
GitHub Copilot. Reads the Claude-format plugin manifest directly.
Factory Droid. One droid mcp add, and the skills copied in by hand.
Any MCP client. A URL and a browser sign-in is the whole setup.
Point your agent at Bird
Paste one prompt and watch the test email land in your own inbox. Free to start, and the first send takes about two minutes.