AI agents need email — your MCP setup is incomplete without it

#aiagents #mcp #ai #productivity

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 outbound lets you cap who the agent can send to (e.g., only internal domains until you trust it).
Audit log: nylas audit logs enable records every CLI invocation with timestamp, command, and exit code. nylas audit export produces 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=nylas agent 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.