Give the CLI you already live in a real mailbox. Triage overnight mail before standup, mail a release note, or turn a thread into an issue, without leaving the terminal.
Run claude mcp add --transport http mcpemails https://mcpemails.com/api/mcp, then authenticate in the browser when Claude Code prompts you. That is the whole setup: no API key, no config file to hand-edit.
Claude Code 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 Claude Code.
| 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.
Run the command below. --transport http is the Streamable HTTP transport, which is what this server speaks.
Run /mcp inside a Claude Code session, pick this server and follow the browser flow. If the browser does not open by itself, copy the URL it prints.
Try "summarise anything unread from today". Claude Code calls inbox_list first to discover your mailboxes, so there are no ids to paste.
claude mcp add --transport http mcpemails https://mcpemails.com/api/mcpOfficial Claude Code documentation for remote MCP servers: https://code.claude.com/docs/en/mcp
Wondering which mailbox to connect first? See the provider compatibility matrix
By default Claude Code loads only tool names and the server instructions at session start, then fetches a full schema when it needs one. The practical effect is that adding this server costs a fraction of the context a naive MCP server would, and that a tool you never use never costs you its schema.
The OAuth consent screen decides what the CLI can do for the life of the token. A coding session that should read mail but never send it is a token without send:email. If you later want more, reconnect and approve the wider set; nothing escalates on its own.
Claude Code runs unattended for long stretches, which is exactly when an accidental send hurts most. Two switches exist for that: leave send:email off the token, or turn on human approval in the dashboard so every send, reply, forward and scheduled send waits for a person. Approval is per inbox and applies whatever client made the call.
--callback-port pins the callback to a port you can forward.Add this MCP server by URL: claude mcp add --transport http mcpemails https://mcpemails.com/api/mcp. Then run /mcp in a session and complete the browser sign-in. Claude Code then has tools for reading, searching, sending, replying, forwarding, organizing and scheduling mail.
Yes. Claude Code accepts a header on the add command, so passing an Authorization header with a bearer key from Dashboard, API Keys skips the browser entirely. That is the right choice on a headless machine or in CI, where there is nowhere to complete a sign-in.
Yes, with the caveat that the OAuth flow wants a browser once. Either complete the login where a browser exists, or add the server with a bearer API key header and skip the flow. Everything after that is plain HTTPS to one endpoint.
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.
One command, one browser sign-in. One inbox free forever, no card required.