Your MCP setup probably has filesystem, Slack, GitHub, maybe a database connector. Common stack. Common gap: no email.
That gap is more important than most teams realise. Here is the case for fixing it.
The world the agent lives in
Imagine the agent's day from its perspective. It opens a ticket. The ticket references a customer. The customer's prior emails are in your inbox. The fix the agent ships triggers a notification email to that customer. A reply lands a few hours later. Without an inbox, the agent only sees the ticket — which is half the conversation.
Email is the universal envelope. Slack and GitHub are walled gardens. Email crosses every boundary your agent's work eventually crosses: customers, partners, vendors, regulators, internal teams that are not on Slack.
The four flows MCP-without-email cannot handle
| Flow | What goes wrong |
|---|---|
| Account verification | Service emails an OTP, agent has no inbox, signup stalls |
| Customer context | Past correspondence with the customer is in email, agent operates blind |
| Async hand-off | Agent emails a vendor, vendor replies a day later, agent never sees it |
| Compliance evidence | Audit asks "what did the agent communicate", email is the record |
I hit the first one trying to give Cursor a Stripe API key. Stripe sent a confirmation email, Cursor had no way to read it, signup hung.
What "agent has email" actually means
Three capabilities, in order of value:
- Read the inbox — list, search, get message bodies, parse attachments
- Send mail — transactional sends from a real address
- React in real time — subscribe to inbound events and run a handler
A complete MCP setup gives the agent all three. The Nylas MCP server, installed via nylas mcp install, exposes them as tools the agent can call.
The setup, end-to-end
# Install the CLI
brew install nylas/nylas-cli/nylas
# Auth with API key (no OAuth flow for the install)
nylas auth config --api-key YOUR_KEY
# Provision a managed inbox the agent owns
nylas agent account create coder@yourapp.nylas.email
# Install the MCP server config into Claude Desktop / Cursor / Codex
nylas mcp install
The last command writes the right mcp.servers block into the AI tool's config. Restart the tool and the agent has nylas-email, nylas-calendar, nylas-contacts available as MCP tools.
What changes for the agent
After install, the agent can do things like:
You: Find the last 3 emails from acme-corp@customer.com and summarise their concerns.
Agent: [calls nylas-email tool: list with filter from=acme-corp@customer.com limit=3]
[reads bodies]
Three messages from Jamie at Acme over the past week:
1. Apr 28 — initial bug report about CSV export missing rows
2. Apr 30 — follow-up after our reply, requesting RCA
3. May 2 — escalation noting it is now blocking their finance close
The thread is unresolved. Suggest replying with...
That conversation is impossible without inbox access.
The MCP-purist objection
"MCP is supposed to be small composable tools. Email is too big."
The Nylas MCP server is composable: each method is its own tool — list, get, send, mark_read, mark_starred, search, attachments_list. The agent does not get a giant "do email things" black box. It gets ~12 small tools that compose like the filesystem ones.
Security without ceremony
Three controls keep the agent honest:
-
Scoped grant: the agent uses an agent-account grant (
provider=nylas), separate from your personal Gmail. Compromise of the agent inbox does not touch your personal mail. -
Outbound rules:
nylas agent rule create --trigger outboundlets you cap who the agent can send to (e.g., only internal domains until you trust it). -
Audit log:
nylas audit logs enablerecords every CLI invocation with timestamp, command, and exit code.nylas audit exportproduces JSON or CSV for compliance.
The audit trail in particular is a feature most MCP setups skip. When the agent sends mail on your behalf, you want a record.
Why not Gmail MCP
There are MCP servers that wrap Gmail directly. They work. Three reasons I prefer the agent-account model:
- Identity separation — the agent has its own address, not yours. Replies stay attributable.
- Multi-provider — the same agent can read a Gmail inbox, an Outlook inbox, and an IMAP inbox without switching tools.
-
No OAuth churn —
provider=nylasagent accounts skip the OAuth refresh dance.
If you only ever touch Gmail and you are happy with the agent posting from your personal account, a Gmail MCP server is fine. If you want the agent to be an entity in its own right, give it its own inbox.
What to install today
- Install the Nylas CLI
- Provision an agent account (one command)
- Run
nylas mcp install - Restart your AI tool
- Watch the agent stop asking you to copy-paste verification links
That is the smallest possible upgrade with the largest workflow shift. If you skip it, your agent stays half-blind.
Next steps
- AI agent email MCP — full MCP install walkthrough
- Why AI agents need email — the longer argument
- Give your AI coding agent an email address — Claude Code, Cursor, Codex setup
- Full command reference