MCP and Email: Wiring an Agent Account Into Your AI Stack

Before: giving an AI assistant email access meant writing wrapper functions, defining tool schemas by hand, managing OAuth tokens, and re-doing all of it for every agent runtime you supported. After: one install command registers a full set of email, calendar, and contacts tools in whatever MCP host you're running, and the agent can optionally own the mailbox outright.

That's the shift MCP (Model Context Protocol) brought to agent tooling, and email is one of the clearest places to see it.

The one-command integration

If your agent runs in an MCP-capable host — Claude Code, Claude Desktop, Cursor, Windsurf, VS Code, or the OpenAI Codex CLI — the Nylas CLI registers itself as an MCP server:

nylas mcp install --assistant claude-code

nylas mcp install --assistant cursor

nylas mcp install --all    # installs for all detected assistants

Verify with nylas mcp status. That's the whole integration: your agent now has 16 email, calendar, and contacts tools available natively, with no subprocess calls and no tool schemas to write. The , currently in beta:

nylas agent account create [email protected]

Both patterns use the same grant model, so you can mix them — one agent triaging a shared support@ inbox while sending outreach from its own address. And because an Agent Account is just another grant, the MCP tools, the CLI commands, and every API endpoint work identically against it. Switch the active grant and your whole MCP toolset is now operating the agent's own mailbox.

Context, not just tools

Tools are half the integration; the other half is the agent knowing how to use them. A few things in the stack are built specifically for machine consumption:

• 
  Skills. npx skills add nylas/skills pre-loads your coding agent with current API and CLI context — commands, flags, output shapes — so it runs things correctly on the first try. Works with Claude Code, Cursor, Codex CLI, and 40+ other agents. In Claude Code it's a plugin: /plugin marketplace add nylas/skills.


• 
  Agent-readable docs. llms.txt is a curated sitemap; llms-full.txt is every page in one file for big context windows; and any docs URL returns clean markdown if you send Accept: text/markdown (the response includes an x-markdown-tokens header with the estimated token count).
  

curl https://developer.nylas.com/llms.txt

curl -H "Accept: text/markdown" https://developer.nylas.com/docs/v3/email/

So when the agent needs an API detail the MCP tools don't expose, it can fetch exactly the page it needs without scraping HTML.

Where webhooks fit

MCP tools are pull-based: the agent acts when prompted. For an agent that reacts — replying to inbound mail, processing meeting changes — you add a push channel:

nylas webhook create \

  --url https://youragent.example.com/webhooks/nylas \

  --triggers "message.created,message.updated"

Webhooks fire for connected grants and Agent Accounts alike, so the architecture is: webhook wakes the agent up, MCP tools (or CLI commands) let it act.

If your host doesn't speak MCP

Not every runtime does, and the fallback is graceful: the same CLI that backs the MCP server works as plain subprocess calls. The covers the SDK route if you're building a SaaS product rather than wiring up an assistant — same grant model, different entry point.

If you've already got an MCP host running, the experiment costs five minutes: install the server, ask your agent to list its unread mail, then ask it to draft a reply. Which host are you running — and what's the first email task you'd hand off?