Apple Mail

@mgcrea/mcp-apple-mail

Model Context Protocol server for the macOS Apple Mail app. Read, search and act on the mail that is already synced to your Mac — no IMAP credentials, no OAuth, no mail leaving the machine.

Unofficial. Not affiliated with Apple. It drives the Mail app that is already on your Mac.

Status

Search, listing, counting, threading, body reading, body _search_ and every mutation are implemented.

How it works

Apple Mail exposes two very different surfaces, and this server uses each for what it is good at. The split is not a preference; it comes from measurements on a real 29,617-message mailbox:

So searching cannot go through Apple Events at all. It has to read Mail's own SQLite index (~/Library/Mail/V10/MailData/Envelope Index), which is what Mail itself searches. That gives three lanes:

• AppleScript lane — accounts, mailboxes, counts, message-by-id, and every mutation. This is also the _authority_ lane: after a write, the result is what Mail re-read, never what the index says.
• Index lane — read-only SQLite for search and filtering. Needs Full Disk Access.
• Body lane — .emlx files on disk for message bodies and attachments. Needs Full Disk Access, and falls back to a per-message Apple Event.

The index is never written to. Mail owns it, holds it open, and reconciles it against IMAP; a write there is corruption with a delay fuse.

Permissions

Two separate macOS permissions, doing different jobs. Neither is granted to Mail.app — it is the _reader_ that needs permission, not Mail.

Automation is granted to the app that launches the server (Terminal, iTerm, VS Code, Claude…). macOS prompts for it on the first Apple Event, so usually you just click Allow.

Full Disk Access is the awkward one.

Why you should not just grant it to your editor

macOS attributes a process's file access to its _responsible process_ — the app at the top of the launch chain. When Claude spawns this server the chain is:

launchd → Visual Studio Code.app → Code Helper → claude → node dist/cli.js

so the grant would have to go to VS Code, and with it every extension, task and terminal command that editor ever runs would gain read access to your entire disk: Messages, Safari history, SSH keys, other apps' containers. That is a much larger permission than "may search my mail", and it defeats APPLE_MAIL_ACCOUNTS, which exists to bound exactly this.

You cannot avoid it by granting the permission to .mcp.json (it is data, not code) or to node (it is not the responsible process, and it is shared by every node program on the machine).

What to do instead

Install Cupertino.app, the signed menu bar app this package is developed in. It holds one Full Disk Access grant and serves this server beneath it, so the permission belongs to a notarized binary rather than to your editor:

brew install --cask mgcrea/tap/cupertino

Measured: Full Disk Access and Automation granted to a signed .app are inherited two levels deep by the processes it spawns, so a node grandchild reads the Envelope Index and tccd resolves a grandchild osascript to the app rather than to whatever launched it.

Earlier versions of this package described a small compiled launcher that made itself its own responsible process through a private API. It is no longer built or shipped — there is nothing left to escape — though native/launcher.c stays in the repository as the clearest statement of the problem.

If you would rather not install the app, granting Full Disk Access to your editor does work. Read the paragraph above about what that grant actually covers before you do.

Restart your MCP host after granting. apple_mail_diagnostics reports which permission is missing and what it is blocking.

A wrinkle worth knowing: stat() on a TCC-protected file succeeds — you can see the size and mtime of the index without Full Disk Access, and only reading it is denied. So "the file is there" is not evidence that the permission is granted; access(R_OK) is.

This install flow is a stopgap. docs/distribution.md covers where it goes next — a signed, notarized app so the grant survives updates and no one needs a compiler — and why the App Store cannot host any of it.

Quick start

# A. from npm

npx -y @mgcrea/mcp-apple-mail

B. from source

pnpm install && pnpm build && node dist/cli.js

Wire it into Claude Code (.mcp.json) or Claude Desktop:

{

"mcpServers": { "apple-mail": { "command": "npx", "args": ["-y", "@mgcrea/mcp-apple-mail"], "env": { // Off by default. With it off the write tools are not registered at all. "APPLE_MAIL_ALLOW_WRITES": "0", }, }, }, }

Inspect the tools directly:

npx @modelcontextprotocol/inspector node dist/cli.js

Tools

Every message carries an opaque ref (m1: / # ) which the read and action tools take. It is versioned and carries its mailbox, so a row id can never be applied to the wrong mailbox. Do not construct one by hand.

Attachments

Mail almost always stores attachment bodies _outside_ the message file, in a sidecar tree — on a real mail store, none of the attachments sampled were inline. So an attachment's size and whether it can be fetched cannot be answered by parsing the message alone, and two plausible shortcuts are both wrong:

• A non-empty MIME part does not mean the bytes are there. Stripping leaves a byte of delimiter whitespace behind, which reads as a present, 1-byte attachment.
• X-Apple-Content-Length is not a byte size. It records the base64-encoded length, so a 164,156-byte PDF advertises 224,634.

list_attachments therefore reports sizeBytes from the file on disk and a retrievable flag saying whether the bytes are on disk, rather than guessing from the message.

An attachment with retrievable: false has not been downloaded by Mail, which on a Gmail account caching messages without their attachments is most older mail. save_attachment then asks Mail to save it, and Mail's save fetches it from the server first; the result says from: "mail". Mail also keeps what it fetched, so the attachment reads retrievable: true afterwards. Mail has to be running and online, a large file can take a while (Mail allows itself two minutes), and Mail writes into a staging folder inside APPLE_MAIL_ATTACHMENT_DIR that is removed after the copy, never into the destination itself.

Security

Blast radius. This server can read your entire mail archive and, with writes on, send mail as you. Two independent controls:

• APPLE_MAIL_ALLOW_WRITES (default off) gates every mutation. With it off the write tools are not registered — they are invisible to the model, not merely refused.
• APPLE_MAIL_ACCOUNTS restricts which accounts are visible at all. This is the _read_-side control, and ALLOW_WRITES does not cover it. It is enforced in one place, so no query path can escape it.

Once implemented, sending will default to leaving a draft open for review; actually sending requires both ALLOW_WRITES and an explicit confirm: true.

No secrets. The server holds no credential of any kind — its access is the macOS permission you granted the host app. There is nothing here to leak, and nothing is sent anywhere: the server makes no network calls at all. What reaches a network is Mail itself, doing what it was asked: sending, checking for new mail, and also save_attachment asking it to download an attachment from your own mail server.

Attachments. save_attachment can only write inside APPLE_MAIL_ATTACHMENT_DIR, and the filename is reduced to its basename first — a sender who names their attachment ../../../.ssh/authorized_keys gets a file called authorized_keys in your downloads folder and nothing else. Existing files are never overwritten unless you ask.

Going the other way, send_message, reply_to_message and forward_message take attachments, absolute paths that Mail reads and attaches. On a draft, the default, you see the files before anything goes. Attaching and sending in one call (sendNow) is refused unless APPLE_MAIL_ALLOW_FILE_SEND is set, because nobody looks and a path is a way to mail out anything this server can read.

No shell. The one place this package spawns a process uses execFile, never exec, and no caller input is ever interpolated into script text. Scripts are static constants piped to osascript over stdin; every value travels as a JSON argument. A mailbox named "; do shell script "touch /tmp/pwned"; // is data, not syntax — there is a tes