Giving an AI agent access to a user’s inbox and calendar usually means building two things. There’s the provider integration work, Gmail’s API, Microsoft Graph, IMAP for everyone else, each with its own auth model, pagination, and sync edge cases. Then there’s a layer on top of that to expose all of it to the agent as tools it can call.
The first part is the one that doesn’t end. We’ve maintained provider integrations at Nylas for years, so the failure modes are familiar: a provider quietly changes how it paginates, a token expires in a way the docs didn’t mention, Yahoo drops a connection 30 seconds after login. Each one starts as an agent returning the wrong answer and ends as a support ticket in your product.
The Nylas MCP server collapses both layers into one. It gives any MCP-compatible client a set of typed tools for email, calendar, contacts, and Notetaker, backed by the Nylas platform. Your agent asks to list messages, check availability, or create an event, and the server makes the underlying API calls. There’s no SDK to wire up and no per-provider code for you to own.
The 36 tools your agent gets
Once it’s connected, your agent has 36 tools. They cover the operations an agent needs to work against a real inbox and calendar, grouped roughly by job:
Read and search: list_messages, list_threads, gett_messages (full body included), list_events, get_event, list_contacts, get_contact
Draft and send: create_draft, update_draft, send_draft, send_message, plus the two confirmation tools we’ll get to below
Schedule: availability across one or more accounts, create_event, update_event, list_calendars
Capture meetings: schedule_notetaker and send_notetaker, with standalone variants, for pulling transcripts and media
You don’t hand-write a function-calling schema for any of this. The agent reads the tool definitions itself, picks what it needs, and chains the calls.
How a single request actually runs
Take a prompt as plain as “what’s on my calendar today.” It doesn’t resolve in one call. Watching the agent work through it, you’ll see something like:
current_time to anchor the right timezone
get_grant to resolve which account it’s acting on
list_calendars to find the primary calendar
list_events with the time window it just calculated
Four typed calls, none of which you wrote glue code for. The MCP Preview page in the Dashboard renders each call as it happens, so you can watch the agent reason through the steps instead of guessing what it did. If you’ve ever debugged an agent that silently called the wrong endpoint and returned a confident wrong answer, that trace is what you reach for first.
Preventing prompt injection
The two tools that carry the most risk are the two that send, so the server doesn’t let an agent send in a single step. send_message and send_draft each require a preceding call to confirm_send_message or confirm_send_draft, which generates a confirmation hash the send tool needs before it will go through.
This is deliberate, and it’s there because of how agents actually fail. A misread instruction, an ambiguous prompt, or hostile content sitting in an email body can all push an agent toward an action the user never asked for. Prompt injection is a real risk here: a message or calendar invite can carry hidden instructions that try to get your agent to send mail or leak credentials. The two-step send means a misfire stops at the confirmation step instead of landing in a customer’s inbox.
You don’t build any of this. It’s how the server behaves by default, which is the behavior you want for anything running near a production mailbox.
One connection, every provider
The reason the agent works the same way whether the account is Gmail, Microsoft 365, or IMAP is that Nylas already normalizes those providers into one data model. The MCP server inherits that. The agent calls list_messages once and gets consistent behavior, instead of branching on provider-specific quirks the way a direct integration has to. (If you want the long version of why those quirks are painful, we wrote about the intricacies of IMAP separately.)
It inherits Nylas auth too. The server uses the same API key and grant IDs as direct API calls, so an already-connected account works through MCP with no separate credential flow.
Connect in less than two minutes
If you have the Nylas CLI installed, one command registers a local Nylas MCP server with your agent:
nylas mcp install --assistant claude-code
Swap the flag for cursor, windsurf, vscode, or codex, or use –all. Then check that it’s live:
nylas mcp status
Want to use our hosted MCP server? Add the server config to your client’s config file by hand and pass your Nylas API key as a Bearer token. The server URL depends on your data residency region: https://mcp.us.nylas.com for US, https://mcp.eu.nylas.com for EU.
Read our docs to learn more about setup and customization.
When it’s still worth building yourself
Some teams will read all of the above and still want to build the integration layer themselves, and for a few that’s the right call. But if the communications layer isn’t the part of your product that differentiates you, it’s hard to justify the time. It’s usually the part that takes the longest to get right and breaks most often once real provider behavior shows up in production.
If you’re building an agent to triage a support inbox, coordinate interviews across calendars, or draft follow-ups after a sales call, the faster path is to skip the plumbing and spend that time on the agent logic that’s actually yours. Connect an account in the Nylas Dashboard, open the MCP Preview page, and run a prompt against your own inbox and calendar. Watching the tool calls go by is the quickest way to understand what an agent can do once it has real context to work with, and then set up the server directly with your agent to turbocharge what your agent can do.
Email and Contacts API 
Calendar API & Scheduler 
Notetaker API 
Agent Accounts 
Sales & CRM 
Recruiting & ATS 
Healthcare
Financial
Legal
Real Estate
Education
Field Services
Docs
SDKs
Guides
Integrations
API status
Changelog
Support
Enterprise
