MCP Server for Gmail: The Options, Ranked

An MCP server for Gmail gives your AI client — Claude Desktop, Cursor, or anything that speaks MCP — typed tools to search, read, draft, and send email from your account. There is no single official Gmail server from Google, so the real choice is between a community stdio server you run locally, a provider-agnostic IMAP/SMTP server, or a hosted remote endpoint that also covers calendar and contacts.

This is a straight comparison of the options that actually work today, with the config for each. If you're new to the protocol, what an MCP server is covers the basics; if you just want the fastest path to sending mail, skip to the config for GongRzhe's Gmail server.

The fastest option: GongRzhe's Gmail MCP server

For most people the answer is the Gmail MCP Server by GongRzhe — a community, MIT-licensed Node server that runs locally over stdio and handles OAuth for you. It's the most-installed Gmail option (~1.1k GitHub stars) because the auth story is genuinely one command: you run auth, a browser opens, you sign in once, and the token is cached.

It exposes the full operational surface of Gmail, not just send/receive: send_email (with HTML and attachments), draft_email, search_emails using native Gmail operators like from:alice has:attachment newer_than:7d, plus label CRUD, filter creation, and batch modify/delete across hundreds of messages. That's real inbox triage, not a toy.

The minimal config, once your OAuth keys are in place:

{
  "mcpServers": {
    "gmail": {
      "command": "npx",
      "args": ["-y", "@gongrzhe/server-gmail-autoauth-mcp"]
    }
  }
}

Two caveats a senior engineer would flag before you commit. First, it stores your access and refresh tokens in plaintext under ~/.gmail-mcp/ — anything that can read your home directory can read your mailbox, so protect that folder. Second, the upstream repo was archived (read-only) in March 2026; the npm package still works, but if you need ongoing security fixes, evaluate a maintained fork.

When to pick a provider-agnostic IMAP/SMTP server instead

Choose an IMAP/SMTP server when you want one config that works across Gmail, Outlook, Yahoo, and iCloud — or when you'd rather use a Gmail App Password than set up a Google Cloud OAuth client. The Email MCP Server by ai-zerolab is the clean pick here: a Python server, stdio transport, provider-agnostic because it talks plain IMAP and SMTP.

It's deliberately smaller — four tools (get_emails_content, send_email, download_attachment, save_to_mailbox) rather than GongRzhe's two dozen. You get read, search, send, and attachment handling; you don't get Gmail-native labels or filters, because IMAP has no concept of them. That's the trade: portability over Gmail-specific features.

{
  "mcpServers": {
    "email": {
      "command": "uvx",
      "args": ["mcp-email-server@latest", "stdio"]
    }
  }
}

On Gmail specifically, IMAP/SMTP means you'll authenticate with an App Password (2FA must be on) rather than OAuth. Some people prefer that — no OAuth consent screen, no token cache — but an App Password is a long-lived credential, so store it as carefully as any secret.

The hosted route: Nylas remote MCP for email plus calendar

Reach for a remote server when you don't want a local process at all, or when "Gmail" is really "email, calendar, and contacts." The Nylas MCP Server is the notable one: an official, hosted, remote endpoint over streamable HTTP that covers Gmail, Outlook, Exchange, Yahoo, iCloud, and any IMAP provider behind a single Nylas auth flow.

Because it's remote, there's nothing to install — you point your client at a URL with a Bearer token:

{
  "mcpServers": {
    "nylas": {
      "url": "https://mcp.us.nylas.com",
      "headers": { "Authorization": "Bearer <your-nylas-api-key>" }
    }
  }
}

The trade-off is that your email now flows through a third party and you're on Nylas's pricing and rate limits, not a free local script. It earns that when you need cross-account calendar tools (create_event, availability, list_calendars) alongside mail, or when you're building for users who can't be asked to configure a Google Cloud project. For the fuller picture on this choice, see local vs remote MCP. Membrane's MCP server is a similar HTTP-based integration-hub option if you're already using Membrane to connect SaaS apps.

What to skip: don't reach for a general ingestion server like Graphlit if your goal is sending email. Graphlit ingests and runs RAG over Gmail (and Slack, Drive, GitHub) for search and Q&A — it's a knowledge layer, not an outbound-mail tool. Right tool, wrong job for this task.

Side-by-side: which Gmail MCP server to use

The short version: local + Gmail-only + free → GongRzhe; portable across providers → zerolab; hosted + calendar too → Nylas. Here's the honest breakdown.

Server	Transport	Auth	Best for	Watch out for
GongRzhe Gmail	stdio (local)	Google OAuth	Full Gmail control: labels, filters, batch ops	Plaintext token cache; repo archived Mar 2026
zerolab Email	stdio (local)	IMAP/SMTP (App Password)	One config across Gmail/Outlook/iCloud	Only 4 tools; no Gmail labels/filters
Nylas	HTTP (remote)	Bearer API key	Email + calendar + contacts, no install	Third-party routing; paid tiers
Membrane	HTTP (remote)	Connected accounts	Already using Membrane's integration hub	Adds a hub dependency

One fact that shapes the pick regardless: about 90% of MCP servers run locally over stdio, so the two local options above are the well-trodden path, and the remote ones are the exception you choose deliberately. For a broader shortlist beyond email, the best MCP servers roundup and the capabilities breakdown are the next stops.

Wiring it up and keeping your tool budget sane

Adding any of these is the same three steps: put the config block in your client's MCP settings, provide the credential, restart the client, and confirm with a search_emails (or list_messages) call. The how to add an MCP server guide has the exact file location per client, and the config generator emits a correct block if you'd rather not hand-write JSON.

Budget matters more than it looks. Coding clients like Cursor start degrading around 40 active tools — past that, the model picks the wrong tool. GongRzhe's Gmail server alone is roughly two dozen tools, so if you also run GitHub, a database, and a browser server, you're near the ceiling. Enable Gmail only in the client where you actually do email, and turn it off elsewhere.

Security is the other non-negotiable. Every one of these can read and send mail as you, so treat the credential like a password: keep the token directory locked down for the local servers, and rotate the API key for the remote ones. If a server won't connect after setup, the usual suspects — wrong path, stale token, missing scope — are in troubleshooting. And if none of these fit, alternatives lists adjacent options.