Give the editor a real mailbox. Reply to a bug report from the file that caused it, mail a customer the fix, or clear an inbox without switching windows.
Add one entry under mcpServers in ~/.cursor/mcp.json with the url https://mcpemails.com/api/mcp. Cursor then prompts you to sign in through OAuth, and no API key is involved.
Cursor runs the standard MCP OAuth flow against this server. It registers itself with RFC 7591 dynamic client registration, so there is no client ID to create, and authorizes with authorization code plus PKCE using S256. No client secret is ever transmitted, and the token carries only the scopes you approve on our consent screen. The access token it receives lasts an hour and refreshes itself; it is listed in Dashboard, API Keys as OAuth: followed by the client name, which is where you revoke the connection.
Everything on this page is a way of getting this URL into Cursor.
| Field | Value |
|---|---|
| MCP server URL | https://mcpemails.com/api/mcp |
| Transport | Streamable HTTP (MCP 2025-06-18) |
| Authentication | OAuth 2.1, authorization code with PKCE. No API key. |
Four steps. The first two are the same for every client, the rest are specific to this one.
Sign up at mcpemails.com, no card required, then go to Dashboard, Inboxes, Connect Inbox. Gmail connects with one-click Google sign-in; iCloud, Fastmail, Yahoo, Zoho and Yandex take an app-specific password; anything else connects over plain IMAP and SMTP. The free plan holds one inbox, forever.
Edit ~/.cursor/mcp.json for every project, or .cursor/mcp.json inside one project.
Add the entry below under mcpServers. The field Cursor wants here is url.
Cursor prompts you to sign in through OAuth. Authorize with mcpemails and approve the scopes you want the editor to hold.
{
"mcpServers": {
"mcpemails": {
"url": "https://mcpemails.com/api/mcp"
}
}
}Official Cursor documentation for remote MCP servers: https://cursor.com/docs/mcp
Wondering which mailbox to connect first? See the provider compatibility matrix
A server in ~/.cursor/mcp.json follows you into every project; one in .cursor/mcp.json belongs to that repository only. Mail is usually a you thing rather than a repository thing, so the global file is the better home, and it keeps the entry out of a repo other people clone.
The entry itself holds no secret, just a public URL, and OAuth tokens are stored by Cursor rather than written here. That changes the moment someone swaps the OAuth entry for a bearer API key inline. If you go the key route, keep it out of a committed file, and revoke any key that has ever been pushed: keys are revocable from Dashboard, API Keys in one click.
A coding agent with delete:email is a strange amount of power to hand a tool whose main job is refactoring. Read, search and draft scopes cover almost every editor workflow. You can always issue a second, wider connection for the assistant you actually triage mail in.
Add an entry under mcpServers in ~/.cursor/mcp.json with the url https://mcpemails.com/api/mcp, then complete the OAuth sign-in Cursor prompts for. Cursor then has tools for reading, searching, sending, replying, forwarding, organizing and scheduling mail across every mailbox you have connected.
No. Cursor runs the OAuth browser flow against this server, registering itself dynamically and authorizing with PKCE, so the config file holds nothing secret. A bearer API key remains an option for scripted or headless setups.
Because the two clients chose different config schemas for the same idea. Cursor reads url under mcpServers, Windsurf reads serverUrl, VS Code wants type and url under servers, and Gemini CLI wants httpUrl. The endpoint is identical in all four; only the key name differs, and copying a snippet across clients is the usual reason a setup silently does nothing.
Gmail over Google sign-in, iCloud, Fastmail, Yahoo, Zoho and Yandex with an app-specific password, and any other mailbox that speaks IMAP and SMTP on the standard ports. The client sees them all through the same connection: your agent calls inbox_list first to discover every connected mailbox and its id, so there are no UUIDs to paste anywhere.
Only if you let it. Sending is gated on the send:email scope, so a key or a token without that scope cannot send at all. On top of that, an inbox owner can require human approval in the dashboard, which holds every send, reply, forward, draft send and scheduled send until a person releases it.
No. Every message is fetched live from your provider for the request that asked for it and handed straight to your client. Only the encrypted OAuth token or app password is kept, so future calls can authenticate. Deleting the inbox in the dashboard, or revoking access at your provider, ends the connection at once.
Four lines of config, one sign-in. One inbox free forever, no card required.