Outlook MCP Server for AI Agents

Command references used in this guide: nylas auth login for Microsoft account connection, nylas email search and nylas email list for Outlook mail reads, nylas calendar events list for schedule context, nylas mcp install for local agents, and the full command reference for every flag.

What is an Outlook MCP server?

An Outlook MCP server is a tool layer that lets an AI agent search, read, and sometimes act on Outlook or Microsoft 365 data through Model Context Protocol. In practice, 3 patterns exist in 2026: hosted assistant connectors, custom Graph API servers, and local CLI MCP.

Microsoft Graph is the underlying API for many Outlook integrations. Microsoft's Outlook mail API overview says Graph can access primary mailboxes and shared mailboxes in Exchange Online, and it supports mail, calendar, and contacts stored in Microsoft 365. Hosted assistants now expose some of that through pre-built connectors. Anthropic's Microsoft 365 connector, for example, can access Outlook email threads and Teams calendar information, but it requires a Microsoft Entra tenant tied to a business plan. See Microsoft's Outlook mail API overview and Anthropic's Microsoft 365 connector guide.

When should you use a hosted Microsoft 365 connector?

Use a hosted Microsoft 365 connector when the agent stays inside one assistant product and your organization can approve the connector centrally. This path is best for business tenants where the admin can review permissions once and users can connect through OAuth.

Hosted connectors reduce setup for end users, but they usually have tenant and plan constraints. Anthropic's guide states that its Microsoft 365 connector is available on all Claude plans, but also says personal Microsoft accounts such as @outlook.com and @hotmail.com cannot be used because the connector requires an Entra tenant. Its security guide says the connector is read-only and that email access can be blocked by revoking Mail.Read in Entra. That is a good fit for enterprise search, not for every developer building an agent in a local IDE.

When should you build Graph API tools yourself?

Build Graph API tools yourself when your application already owns the Microsoft 365 auth flow, tenancy model, and retry policy. A custom tool server can expose exactly 4 or 5 operations the agent needs instead of letting it roam across an entire mailbox.

The cost is operational. Microsoft Graph throttling is not one number: Microsoft documents global limits and service-specific limits, and any request can be evaluated against multiple buckets. The Microsoft Graph service-specific throttling limits page lists a global example of 130,000 requests per 10 seconds per app across all tenants, then separate limits for services and request types. A reliable Outlook agent server must respect 429 Too Many Requests, parse Retry-After when present, and reduce the data shape with filtering rather than fetching every message body.

When should you use local CLI MCP for Outlook?

Use local CLI MCP when the agent runs in a developer tool and needs Outlook email or calendar access without a custom Graph integration. CLI 3.1.10 can connect Microsoft accounts with nylas auth login --provider microsoft and install MCP config for 5 local assistant targets.

This path is useful for Claude Code, Cursor, Windsurf, VS Code, and other local agent workflows where the developer wants repeatable terminal checks. First connect the Outlook account, then run read-only commands before installing MCP. That gives you 2 layers of evidence: the CLI can access the account, and the agent client can discover the MCP server.

nylas auth login --provider microsoft
nylas email search "project update" --limit 10 --json
nylas calendar events list --days 7 --json

nylas mcp install --assistant cursor
nylas mcp status

The same commands are documented at nylas auth login, nylas email search, and nylas calendar events list.

How do shared mailboxes change 3 checks?

Shared mailboxes change 3 checks for an Outlook agent: which identity owns the grant, which mailbox the agent can search, and which mailbox is allowed to send. A tool that works against a user's primary mailbox can fail or overreach when the target is a shared support mailbox.

Review shared-mailbox behavior before the agent sees production mail. In Microsoft 365, shared mailboxes often have delegated access, retention policy, and send-as rules that differ from a user's mailbox. The agent should not guess the target based on a display name. Make the mailbox or grant explicit, and test read access with a 10-message search before you test draft or send paths.

If the agent handles a queue such as support@ or billing@, record whether it is reading the queue mailbox, a user's copy of the queue, or a forwarded folder. Those are 3 different audit stories. The command output should make the active grant and account clear enough for a reviewer to trace later.

Why start with 2 read paths before send?

Start with 2 read paths before enabling Outlook sends: search summaries and read-by-ID. Search gives the agent a narrow candidate set. Read-by-ID forces the user or workflow to choose the exact message before the assistant sees the full body.

This pattern avoids the common mistake of giving an agent a broad mailbox export just because the final task is "reply to the latest customer." The agent usually needs fewer than 20 snippets to pick the thread and 1 full message to prepare a useful response. Calendar context can be added with a 7-day event list when the reply involves scheduling, but it should remain a separate tool call.

Once those 2 read paths are stable, decide whether the send action belongs in the assistant at all. Some teams keep Outlook agents draft-only for the first 30 days, then enable send after reviewing transcripts, recipient errors, and user confirmation behavior.

The rollout metric is not "how many Graph endpoints did we expose?" A better metric is "how many resolved tasks required send?" If 90% of the first 100 agent tasks are search, summarize, and calendar lookup, keep send behind a separate approval path. Tool access should follow measured user need, not the size of the provider API.

What Outlook data does the agent actually need?

An Outlook agent usually needs fewer than 6 tool families: list messages, search messages, read a selected message, send or draft a reply, list calendar events, and search contacts. Exposing more tools before the workflow proves the need increases review work and risk.

Start read-only. Search for the relevant thread, read the 1 or 2 messages the user approves, and list the next 7 days of calendar events only when scheduling context is required. Microsoft Graph supports categories, folders, importance, flags, shared mailboxes, and MIME access, but an agent rarely needs all of them on day 1. If a send action becomes necessary, keep it as a separate command with confirmation rather than hiding it inside the same tool that reads mail.

How do Outlook MCP options compare?

Compare Outlook MCP options across tenant fit, provider coverage, and write control. Hosted connectors are easiest inside a supported assistant. Graph tools give the most Microsoft-specific control. Local CLI MCP is quickest for developer agents and multi-provider workflows.

If you sell to customers with both Microsoft 365 and Gmail, avoid building an Outlook-only agent contract too early. The CLI command shape stays the same across major providers, which keeps prompts, scripts, and audits smaller.

How do you review Outlook agent security?

Review Outlook agent security by separating identity, permissions, and action boundaries. A Microsoft 365 connector uses delegated permissions and Entra controls. A local CLI workflow uses the connected grant, local config files, and the assistant's MCP or command permission model.

For local workflows, run nylas auth whoami --json before every demo and keep nylas mcp status output in setup notes. For hosted connectors, confirm whether the connector is read-only, whether users can access other users' mail, and who can revoke access. Anthropic's Microsoft 365 connector security guide says user-level permissions apply and that users cannot access other users' private files or emails. Your own Graph tools should document the same boundary in code comments and runbooks.

nylas auth whoami --json
nylas auth list --json
nylas mcp status

Next steps

• List Outlook emails from terminal - verify Outlook reads before connecting an agent
• Manage Outlook calendar from the CLI - test event listing and scheduling commands
• Give AI agents email access via MCP - configure local MCP for supported assistants
• Email APIs for AI agents compared - compare Graph, Gmail API, IMAP, and CLI paths
• Full command reference - exact syntax for auth, email, calendar, MCP, and webhooks