How to Connect Gmail to Cursor: The MCP Setup That Works (2026)
Cursor has no built-in Gmail connection, so every setup runs through MCP. The two routes that work in 2026, the config that goes in .cursor/mcp.json, and the one warning about open-source Gmail servers most guides skip.
- Cursor has no native Gmail connector: everything goes through an MCP server, configured in a .cursor/mcp.json file, and the setup takes about five minutes once you have credentials.
- There are two honest routes: an open-source Gmail server with your own Google Cloud OAuth credentials for a personal inbox, or a vendor-shipped MCP server for a team inbox.
- The open-source route carries maintenance risk: the most popular community Gmail server, with over a thousand GitHub stars, was archived in March 2026 and no longer receives updates.
Table of contents
- What Cursor brings to the connection
- What Gmail brings, and what it does not
- The two routes, honestly compared
- Route 1: your own Gmail through an open-source server
- Route 2: your team's shared inbox, the five-minute version
- What to ask it, and what comes back
- What the connection can and cannot do
- Troubleshooting: the four ways this setup actually fails
- Where this fits in the wider setup
Cursor is where your code lives, and increasingly it is where the emails about your code want to be read: the bug report that references the function you have open, the customer thread that explains the stack trace, the reply you owe once the fix is pushed. Unlike Claude, Cursor has no built-in Gmail connection. Every working setup runs through MCP, the open protocol Cursor uses to reach tools beyond your codebase. The good news is that the configuration is one small JSON file. This guide covers what each side of the connection brings, the two routes that actually work in 2026, and the maintenance warning most setup guides skip.
What Cursor brings to the connection
Cursor is the AI code editor: a fork of VS Code with frontier models built into the editing loop, and in 2026 one of the most widely adopted developer tools in the world. What matters for this guide is how it reaches beyond your code. Cursor speaks MCP, the Model Context Protocol, and any MCP server you configure becomes a set of tools its AI can use mid-conversation: reading tickets, querying databases, or, here, working an inbox. There is no Gmail button to press. The connection is a config file, which is very Cursor: everything is code, including your integrations.
What Gmail brings, and what it does not
Gmail brings the mail, obviously, but also the boundary that shapes both routes below: Google does not ship an MCP server for Gmail. Access goes through the Gmail API with OAuth, which means something has to stand between Cursor and your inbox: either an open-source server you run yourself with credentials you create, or a vendor's server that holds the connection for you. Which one is right depends on whose inbox it is. Your personal mail is yours to wire however you like. A team address like support@ belongs to the team, and wiring it through one person's login builds an invisible dependency that outlasts that person's patience, and sometimes their employment.
The two routes, honestly compared
| Open-source Gmail server | Vendor-shipped MCP server | |
|---|---|---|
| Best for | Your personal Gmail | A team inbox like support@ or sales@ |
| Credentials | Your own Google Cloud OAuth setup | An API key from the vendor |
| Can it send as you? | Usually yes, worth knowing before you connect | Drag's server drafts instead of sending |
| Maintenance | You are trusting a community repo | The vendor's job, not yours |
| Team visibility | None, the connection is yours alone | The whole team sees what the AI did |
| Setup time | 20 to 30 minutes the first time | About five minutes |
AI Platform
The inbox your team and your AI work in together
Shared inbox, live chat, and AI in Gmail, with an MCP server your AI tools can drive.
Route 1: your own Gmail through an open-source server
For a personal inbox, the standard path is a community-built Gmail MCP server running locally through npx, authenticated with OAuth credentials you create in Google Cloud Console:
- Create a project in Google Cloud Console and enable the Gmail API.
- Create OAuth credentials and download the client file.
- Point the server at the client file, per its README.
- Add the server to your
mcp.jsonand restart Cursor.
The server then exposes tools inside Cursor: search, read, label, draft, and usually send.
One warning before you pick a server, and it is the part most guides skip: the community layer moves fast and abandons fast. The most popular open-source Gmail MCP server, GongRzhe's Gmail-MCP-Server with over a thousand GitHub stars, was archived in March 2026 and is now read-only. Forks and successors exist, but whichever repo you choose, check its last commit date before you hand it your mail. Hosted MCP platforms such as Composio and Merge remove that risk by managing the server and the OAuth for you, at the cost of routing your mail metadata through their service.
Whichever server you pick, the Cursor side is the same: an mcp.json file, either at .cursor/mcp.json in the project where you want the tools or at ~/.cursor/mcp.json to make them global (the repo's README will give the exact command and args for that server). Restart Cursor and its tools appear in the MCP panel.
Route 2: your team's shared inbox, the five-minute version
If the email you want in Cursor is a team address, the personal-OAuth route is the wrong tool: the AI would act as you, invisibly to your team, on an inbox everyone shares. The right shape is a shared inbox tool that ships its own MCP server, so the connection belongs to the workspace rather than one person's login.
That is what Drag does for teams running support or sales on Gmail. Get an API key from app.dragapp.com under Settings and Integrations, then add this to .cursor/mcp.json (or ~/.cursor/mcp.json to have it in every project):
{
"mcpServers": {
"dragapp": {
"command": "npx",
"args": ["-y", "@dragapp/mcp-server"],
"env": { "DRAG_API_KEY": "your-key-here" }
}
}
}
Restart Cursor and the Drag tools appear in the MCP panel: the queue, assignment, tagging, and drafting, with replies landing as drafts for human review rather than sending automatically. Drag is $12 per user per month billed annually, with the AI assistants included from $18, on a 7-day trial with no card.
What to ask it, and what comes back
The point of email in Cursor is context you already have open. Below are worked examples of the exchanges this setup is built for, so you can see what the answers actually look like before you wire anything up:
Cursor
Reply, using Drag's MCP toolsCursorReply, using Drag's MCP toolsCursorReply, using Drag's MCP toolsCursorReply, using Drag's MCP toolsAnd two more worth keeping for the end of a working day:
CursorReply, using Drag's MCP toolsCursorReply, using Drag's MCP toolsEvery reply these produce lands as a draft for human review. Nothing sends until a person sends it.
What the connection can and cannot do
Worth knowing before you grant anything, because the boundaries are the point.
| What Cursor with Drag's MCP server can do | What it cannot do |
|---|---|
| Search, read, and summarize the team's shared inbox alongside your code | It does not send email: every reply lands as a draft a human reviews and sends |
| Assign conversations, apply tags, and update statuses the whole team can see | It cannot act invisibly: every action is attributed in the shared inbox, visible to the team |
| Draft replies with the context of both the thread and the code you have open | It does not touch personal Gmail: the connection is to the team's shared inbox, governed by the workspace |
Troubleshooting: the four ways this setup actually fails
None of the guides ranking for this setup cover what happens when it breaks, so here are the four failures that account for most of the support threads.
- The tools simply do not appear after you edit the config. Cursor only reads
mcp.jsonat startup, so fully quit and reopen it, then check the MCP section of settings. A working server shows its tool list there; a broken one shows nothing. - A JSON typo. A missing comma fails silently, with no error and no tools, so paste your config into a JSON validator before you blame anything else.
- The seven-day token trap, specific to the open-source route. If your Google Cloud project is still in testing mode, Google expires its refresh tokens after seven days, which means the setup that worked last week quietly stops working this week. Publish the OAuth consent screen and the tokens stop expiring, or resign yourself to re-authenticating weekly.
npxpulling a newer version of the server that breaks something. If a setup works, pin the package to that version rather than letting it float to latest.
Where this fits in the wider setup
Cursor is only one of the places this pattern works. The same thinking applies across your stack: our Gmail MCP server guide covers the landscape of servers in depth, connecting Gmail to Claude covers the assistant most teams pair with Cursor, connecting Gmail to ChatGPT covers its built-in connector and Developer Mode, and connecting multiple Gmail accounts covers the several-accounts problem across every assistant. If you are still weighing whether MCP is worth adopting over a plain API integration, MCP vs API is the primer.
Frequently asked questions
Does Cursor have a built-in Gmail integration?
No. Unlike Claude, which ships an official Gmail connector, Cursor connects to external services only through MCP servers you configure yourself. That is by design: Cursor is a code editor first, and MCP is its single doorway to everything that is not code.
Is it safe to connect Gmail to Cursor?
The MCP protocol itself is sound, and OAuth means no passwords change hands. The real question is which server you trust: an open-source server runs on your machine with your credentials, while a vendor-shipped server is maintained and accountable. Either way, prefer setups where sending stays in human hands.
Can Cursor send emails from my Gmail?
It depends on the server. Most open-source Gmail MCP servers expose a send tool, which means the AI can send as you. Drag's MCP server deliberately drafts rather than sends for exactly that reason: a reply written next to your code still deserves a human look before it leaves.
Should I connect a shared address like support@ to Cursor?
Not through a personal OAuth login. A shared address needs a connection your whole team can see and govern, which is what a shared inbox tool with its own MCP server provides. Our guide to connecting a shared inbox to AI assistants covers the same setup for Claude and ChatGPT.
Co-founder
Building Drag for nearly ten years: shared inboxes, boards, and now the AI and agent layer, all on Gmail, plus HeyHelp for the personal inbox. Writes the honest versions of the comparisons.
