imap-mcp

A Model Context Protocol (MCP) server for any IMAP mailbox. It speaks IMAP rather than one vendor's API, so it works with whatever provider you already have.

Lets MCP clients like Claude Code, Claude Desktop or Codex read and search your mail, organise it into folders, save attachments and draft replies — with every message fenced as untrusted content, and the write tools off unless you turn them on.

Eleven tools, not fifty: a mail account is a workflow, not an API surface, so related operations are folded into one tool with a mode rather than split across many. And eleven is the ceiling, not the floor — IMAP_ALLOW_TOOLS=essential registers a curated six instead, and under the read-only default that narrows to four. See choosing which tools load.

What makes it different

It cannot send mail. That is the feature. An agent with access to private data, exposure to untrusted content, and a channel to the outside world is exploitable by anyone who can put a message in the inbox — the pattern that produced EchoLeak, where one crafted email exfiltrated internal data from Microsoft 365 Copilot with no user interaction. This server has the first two and deliberately not the third. save_draft writes the reply into your Drafts folder; you send it from your own mail client. No amount of clever text in a message can make this server post anything anywhere.

Writes are off until you turn them on. With only IMAP_HOST, IMAP_USER and IMAP_PASSWORD set, the server registers six read tools and nothing else. The mailbox tools appear with IMAP_READ_ONLY=false — note the default is true, the opposite of the other servers in this family, because this one reaches a mailbox. Tools that are off are not registered at all — a capability the model cannot see is one it cannot be talked into using.

Mail is treated as hostile input, because it is. Anyone in the world can put text in your inbox. Message bodies are fenced between markers carrying a per-call random nonce, and every line inside them is prefixed with that nonce, so the "this is data" signal does not stop at the edges of a long forwarded thread. A reminder follows the block, because otherwise the last instruction-shaped sentence in the model's context is the attacker's. Zero-width characters and directional overrides are stripped before the model sees anything, hidden HTML elements are dropped on a best-effort basis (the fencing, not the stripping, is what carries the weight), and markdown image syntax — inline and reference style — is defused so a rendering client cannot be made to fetch a tracking URL.

That covers folder names too, and it did not always: a folder name is chosen by whoever created the folder, which on a shared mailbox is not necessarily you. list_mailboxes returns the name twice — path exactly as the server spelled it, because that is the handle every other tool takes, and display_name cleaned up for reading, with a warning on the entry when the two differ.

Alongside the message you get a server-side assessment: the SPF/DKIM/DMARC verdicts with the authserv-id they came from, which prompt-injection shapes matched, and which words mix Latin with Cyrillic or Greek letters. When something matches, the warning is the first thing in the result rather than a field buried in JSON.

Those verdicts carry a forgeable flag, and by default it is always true. A sender can write an Authentication-Results header of their own, and if your provider does not add one, theirs is the only one there — nothing inside the message distinguishes the two. Set IMAP_TRUSTED_AUTHSERV_ID to the id your provider stamps (it is the first token of the header on any message you already have) and only that id counts as authentic. Until you do, spf=pass is reported as what it is: a claim, from a header anyone could have written.

"New mail" that actually works. The server tags messages it has handed over with a custom IMAP keyword (AiSeen by default), so list_new_messages returns each message once. The human \Seen state is never touched — everything is read with BODY.PEEK.

Deleting and moving ask a person. Where the client supports MCP elicitation, delete_messages, move_messages and deleting a folder raise a real dialog that the model cannot answer on its behalf. Where it does not, they fall back to a two-call token — and say so, rather than implying somebody approved. ELICITATION=false takes that fallback deliberately; it never removes the guard. See Asking a person.

Requirements

• Node.js 22 or newer
• An IMAP account. Providers with two-factor authentication generally need an app-specific password.

Configuration