macOS Apps

macos-apps-mcp

[elfensky/macos-apps-mcp MCP server]

One local MCP server for Mail, Calendar, Reminders, Notes, Messages, Contacts, Photos, Safari, Music and Shortcuts on macOS. Searches and lists return pointers: an id, a one-line summary and a link that opens the item in its app. Bodies are a separate, capped fetch. Writes are tiered and audited; deletes, moves and sends preview first. macOS only. Python + FastMCP + uv. See DESIGN.md and CHANGELOG.md.

What you can ask

• "What is on my calendar this week? When am I free on Thursday afternoon?"
  _{events, free_busy}
• "Which emails need a reply? Draft a reply to the first one."
  _{mail_needs_response, mail_reply. The reply opens as a draft in Mail. It is not sent.}
• "Move the newsletters in my inbox to Archive. Show me first."
  _{mail_search, move_mail, mail_undo. The move previews by default. mail_undo reverses it, within the known limits below.}

Safety and privacy

• Local. No telemetry, and no network requests of its own: only a local unix socket (shim to daemon) and the dashboard on 127.0.0.1. Three tools reach past the Mac through the apps, when called: the send tools (off by default) send through Mail, safari_open opens a page, and run_shortcut runs a Shortcut that can call the web.
• Three tiers. Read, write and outbound. Send tools are absent until you enable them per app: macos-apps-mcp allow-send mail (daemon) or MACOS_APPS_ALLOW_SEND=mail (stdio). MACOS_APPS_READ_ONLY=1 registers reads only and wins over both.
• Dry run first. dry_run defaults to true for delete_draft, move_mail, trash_mail, mail_undo, send_mail, reply_all, forward_mail, delete_reminder, delete_event, delete_note and update_note. Other writes act when called. mail_reply opens a draft only.
• Audit log. Every write goes to ~/.local/state/macos-apps-mcp/audit.jsonl (under $XDG_STATE_HOME when set). An update or delete by id also records the item as it was. The audit tool reads the log back.
• Mail recovery. Before a Mail move or delete, each message is copied as .eml under ~/.local/state/macos-apps-mcp/backup/mail/. mail_undo reverses the batch. No tool empties the Trash.
• Known limits. A message Mail downloaded only in part is backed up without its attachments. Moves and trashes through a Gmail label folder are refused, because Gmail reverts them about 2 minutes later. sent: true means Mail accepted the message, not that it was delivered. All Mail facts.
• Dashboard. Under the signed .app daemon, a local page (127.0.0.1 only) shows every write, what it changed, and the backup behind each Mail batch. Invented data below:

[The dashboard: three newsletters moved to Archive, each one backed up, and the prompt that undoes the batch]

First 5 minutes

Requires macOS, Python ≥ 3.12 and uv. uv provides uvx. The package is on PyPI. Point your MCP client at uvx. It fetches the package and runs it, so there is no clone and no venv path:

{  "mcpServers": {    "macos-apps": {      "command": "uvx",      "args": ["macos-apps-mcp"]    }  }}

If Claude Desktop cannot find uvx, set "command" to its full path: run which uvx in Terminal (a default uv install prints /Users/you/.local/bin/uvx).

For Claude Code:

claude mcp add macos-apps --scope user -- uvx macos-apps-mcp

Or, instead of claude mcp add, install the Claude Code plugin. It starts the same server and adds a skill that teaches the dry-run workflow. In Claude Code, run /plugin marketplace add elfensky/macos-apps-mcp, then /plugin install macos-apps@macos-apps-mcp.

The CLI commands further down (allow-send, dedupe-mail) run the same way: uvx macos-apps-mcp allow-send.

Run doctor first. The doctor tool reports what is granted and opens no dialog (each Automation grant is read live; an app that is not running shows not_running). doctor(request=True), with you at the screen, opens the EventKit and Automation dialogs. The server needs:

• EventKit: Calendar and Reminders.
• Automation, one dialog per app: Mail, Notes, Contacts, Safari, Messages, Music.
• Accessibility (optional, no dialog: turn it on in System Settings → Privacy & Security → Device Control and Data Access, called Accessibility before macOS 27, for the app that starts the server): mail_reply and reply_all put your text above Mail's own quote. Without it, those two refuse and create nothing. doctor and the Health page show whether it is on.
• Full Disk Access (optional, no dialog: turn it on in System Settings → Privacy & Security → Full Disk Access, for the app that starts the server): Messages content, Photos, Mail's index reads, reminder tags and subtasks, and the fast Notes path. Without it, Notes and some Mail reads use a slower path. The rest return an error or a coverage note.

Under stdio, macOS gives each grant to the app that starts the server (Claude Desktop, Terminal, VS Code), so each client needs its own. The signed .app daemon holds one set for all: docs/DAEMON.md.

Load only the apps you use. MACOS_APPS_ADAPTERS_OFF=photos,music registers no tools for those apps, so your client holds fewer tools in its context. Under the daemon, see turn adapters off.

From source (development): use this path to work on the server itself.

git clone https://github.com/elfensky/macos-apps-mcp && cd macos-apps-mcpuv sync

Then point your MCP client at the project's own venv python — deterministic, and it carries the locked PyObjC wheels:

{  "mcpServers": {    "macos-apps": {      "command": "/absolute/path/to/macos-apps-mcp/.venv/bin/python",      "args": ["-m", "macos_apps_mcp"]    }  }}

Why not apple-mcp?

apple-mcp by Dhravya Shah pioneered one MCP server for all Apple apps. It is now archived. It returned full note and email bodies inline. This server returns pointers, fetches bodies only on request, and gates every write by tier. See CREDITS.md.

Something broke? Run doctor and paste its output into a GitHub issue. The report shows process paths, so check them before you post.

Tools

Reads return pointers; results are capped per adapter. Bodies/content are a separate bounded fetch. Writes/actions are skipped entirely when MACOS_APPS_READ_ONLY is set (see below).

Calendar & Reminders — read/write (EventKit)

Event and reminder pointers carry folder = the calendar or list id, which free_busy(calendars=…) and the write tools (calendar=, list_name=) take.

Reminder tags and subtasks (tags, parent = the parent's id) are read from the Reminders store, read-only, and need Full Disk Access. When that store cannot be read, the reminders still come back and coverage says why. No public API writes a tag or nests a reminder, so no tool here does.

A write targets its container by name or Pointer.id; an ambiguous name raises rather than guessing. Recurrence is an RFC 5545 RRULE: FREQ, INTERVAL, COUNT, UNTIL, BYDAY (with ordinals such as 2TU or -1FR for monthly and yearly rules), BYMONTHDAY, BYMONTH, BYYEARDAY and BYSETPOS, e.g. FREQ=MONTHLY;BYDAY=2TU;COUNT=6. A recurring reminder needs a due date. BYWEEKNO, BYHOUR, BYMINUTE, BYSECOND and WKST are refused by name (EventKit saves BYWEEKNO but expands only the first date), and so is any value out of range or any combination RFC 5545 forbids; each part is checked again after the write. A start date that does not match its rule is accepted — RFC 5545 counts it as the first occurrence — and the event result says that the first occurrence is an extra one.

Mail — id-first read + draft-and-open (Automation)

Sending is off by default: reads, create_draft, and mail_reply never send — they open a compose window for you to review. Outbound (send_mail, reply_all, forward_mail) exists but only runs when the operator opts in via MACOS_APPS_ALLOW_SEND, and dry_run still defaults to True even then.

Messages — content via chat.db (read-only; Full Disk Access)

Notes — NoteStore.sqlite reads + opt-in bodies

Other read-only context

Actions (writes)

Read-only mode

Set MACOS_APPS_READ_ONLY=1 (or true / yes) to register reads only — every write and action tool is skipped, a safe-deploy guard. (Reads may still open apps / read local stores.)

Turning adapters off

Set MACOS_APPS_ADAPTERS_OFF=photos,music (a comma list of adapter names) to register no tools for those apps. Under the daemon, the file ~/.local/state/macos-apps-mcp/adapters_off holds the same list and takes effect after a restart. Details: docs/DAEMON.md.

Dashboard

Under the daemon, http://127.0.0.1:47632 shows the audit trail, Health, the adapter switches, usage and the Mail backups. Run macos-apps-mcp dashboard to open it with its page key. Details: docs/DAEMON.md. Both screenshots use invented data.

Cleaning up duplicate mail

Mail accumulates redundant copies of the same message — a UI drag copies rather than moves, Gmail shows one message under both a label and All Mail, migrations leave copies on two accounts. The read tools already collapse them, so this is only about what is physically on the server. Ask a session for mail_duplicates() to see the damage, then clean up in a terminal:

macos-apps-mcp dedupe-mail                       # preview every mailbox — changes nothingmacos-apps-mcp dedupe-mail --verbose             # also list the sets it will NOT touchmacos-apps-mcp dedupe-mail --execute --mailbox=<folder-url>   # do one mailbox for real

A CLI command, not a tool, for the same reason as allow-send: thousands of deletes against a 30-second-capped serialized worker is hours of work a human starts. It only collapses copies that are byte-identical (size and date sent) — Mail gives no way to address one specific copy, so the survivor is whichever one Mail leaves, and identical bytes are what make that safe. Sets that differ are counted, left alone, and listed under --verbose.

Redundant copies go to Trash, in small batches, each its own mail_undo receipt. Emptying the Trash is yours to do in Mail.app — nothing here can erase a message.

It is slow: ~1 minute per duplicate set against a real IMAP account (Mail's whose lookup scans the whole mailbox), so a big folder is hours. Run it in a terminal you can leave, one mailbox at a time. It is resumable — the plan is recomputed from Mail's index on every run, so interrupting it costs nothing and re-running just finds less to do. A set Mail fails to delete is reported, not retried silently.

Outbound (send) mode

Sending is off by default — the server creates drafts and never sends. Turn it on with:

macos-apps-mcp allow-send mail    # or: messages / mail,messages / all / offmacos-apps-mcp allow-send         # print the current setting

That persists the opt-in and restarts the daemon so it re-registers (registration happens at import, so a restart is unavoidable — reconnect your MCP client afterward). It is a CLI command, not a tool: the gate is your consent, so the model can neither grant itself sending nor restart the server out from under your session.

The same choice is available as MACOS_APPS_ALLOW_SEND in the environment, which is what a stdio server reads (a set variable always wins over the persisted toggle):

MACOS_APPS_READ_ONLY always wins: with both set, no send tools are registered.

Send tools take dry_run, which defaults to True — deliberately inverted from the id-addressed deletes. A delete targets an item a read already returned; a send constructs its recipient, and a wrong recipient is the failure that matters. The dry run makes no call into Mail at all and reports the resolved envelope; pass dry_run=False to actually send. reply_all is the one exception: its dry run reads (never sends) the original message's actual to/cc recipients, because that's exactly the recipient set a caller can't predict.

A successful send_mail / reply_all / forward_mail result (sent: True) means Mail accepted the message — not that it was delivered. Device-verified: a perfectly-formed message can sit in Mail's Outbox undelivered for minutes after send returns, and a stranded recipient-less message can jam the outbox so later, valid sends queue behind it and never leave. Every result also reports outbox_pending, Mail's current outbox count; when it's greater than zero the result carries a note explaining that delivery is not confirmed and to check Mail ▸ Outbox.

A real reply_all keeps Mail's own quote and takes about a minute: Mail can autosave a copy of the reply into Drafts that survives the send, so the call waits until 45 seconds after the reply window opened and deletes that copy only when it is provably its own. The result's drafts_copy (removed, none, late, unproven or unavailable) and a plain note say what it found; sent stays true whatever that is, and nothing in Sent or All Mail is touched.

Run the doctor tool to check whether sending is actually enabled — deployment.outbound lists every adapter currently send-enabled ([] if none), derived from the same registration logic above rather than a re-read of the raw env var, so it can never disagree with what got registered; deployment.outbound_note explains the state in prose.

Under the daemon deployment, setting MACOS_APPS_ALLOW_SEND in an MCP client's config is a silent no-op: the client's env block reaches the shim, not the long-lived daemon process that reads the variable at import time, and the shipped LaunchAgent plist ships no EnvironmentVariables key. This is exactly why allow-send exists — it writes state the daemon can read (~/.local/state/macos-apps-mcp/allow_send, home-pinned so the shell that writes it and the launchd process that reads it always agree) and survives reboots, unlike launchctl setenv. See docs/DAEMON.md ("Outbound (send) mode under the daemon").

Develop

uv syncuv run pytest                   # unit tests (mock at the adapter boundary)uv run pytest -m integration    # real macOS / EventKit / TCC — run manually, never in CIuv run ruff check .             # lint (config in pyproject.toml)uv run ruff format .            # formatuv run macos-apps-mcp                  # run the server (stdio)

ruff (lint + format, line-length 88) and pytest gate CI — full workflow in CONTRIBUTING.md.

Prior art & credits

macos-apps-mcp builds on prior work — the Apple Mail MCP it draws from, the EventKit/Photos servers it references, the project that pioneered the unified-Apple-MCP pattern, and FastMCP / PyObjC / the MCP spec it depends on. See CREDITS.md.