Cupertino — MCP servers for your everyday Apple apps

Every one of these carries a constraint — an account, a date bound, a filter. That is the part a shell script gets slowly or gets wrong, and the reason a server earns its place: it holds what the model would otherwise have to re-derive every session.

Every Apple app Cupertino brokers gets its own pane: whether it can be driven, whether its store can be read, who is talking to it, and what it can currently say.

Full Disk Access is indivisible, and it lands on whatever process launched the server — your editor, your terminal, never Mail itself. A grant for mail is already a grant for Messages, Safari history and SSH keys. Granting it to Mail.app does nothing: the reader needs the permission, not Mail.

The tool list is a pure function of allowWrites and nothing else, because MCP clients cache it. With writes off the mutating tools are never registered — the host cannot call what it was never told about, so there is nothing to refuse.

Every tool call, live, grouped by the client that made it. It is the answer to “what did the assistant just do with my mail?” — and the reason the servers run under an app you can see rather than inside whichever editor happened to spawn them.

Cupertino runs as a menu-bar app you can open. That is the point of holding the servers in one signed process rather than spawning them inside whichever editor asked first: there is something to look at, and it tells you what happened.

Same query, same mailbox. Apple Events makes Mail.app do the work one message at a time; the index lane reads the Envelope Index directly. Reading the index is the easy half — Mail owns that file and is still writing to it, so every result carries how old the index was and whether the read could see the write-ahead log at all.

drawn to scale — 0.13% of the bar above

A search result carries indexAgeSeconds, and a warning when the index could only be opened immutable — which skips the write-ahead log, so the newest mail is exactly the mail most likely to be missing. A fast wrong answer is the failure mode every indexed reader shares; saying so is the part that is optional.

Without the grant, Notes still works fully below roughly 5k notes; Mail search falls back to the 74-second path. Tools that need the index never disappear — the tool list is a pure function of allowWrites and nothing else, so they return a structured degraded result naming what is absent.

macOS has no body index to borrow — Mail keeps none, and Spotlight excludes ~/Library outright. So the index narrows the query and only the survivors are read, which makes cost linear in how well you filtered. Past the bound it refuses and says so.

log scale · measured against 181,734 messages

degraded: true
capability: "body-scan"
reason: "6566 messages match the other filters, above the
          2000-message body scan bound. Nothing was scanned,
          so this is not "no results"."
hint: "Narrow with mailbox, account, sender or dateFrom and
        try again — a body search over a few hundred candidates
        is near-instant."

Safari's own way to let a program read a page is a single switch that grants every program access to every tab, and whose state cannot be read back. Cupertino ships a Safari extension instead: you allow it one website at a time, in Safari, and take it back the same way.

It is a snapshot, and it says so

The extension captures a page when it loads; nothing reaches into Safari to fetch a fresh copy. So a result is what that page looked like then, and every one carries the time it was taken and how long ago that was. Read something captured twenty minutes ago and it tells you it is twenty minutes old, rather than letting an assistant describe a page you have already left as the one on your screen.

Each of these brokers one Apple app, and all but Simulator are their own npm packages, so a host loads only the tools it wants — and write tools against Mail and against Reminders are not the same risk. They share one bundle and one grant, which is the whole reason they live together.

Mail without the grant — Accounts, mailboxes and writes only — search falls back to the 74-second path.

Notes without the grant — Fully usable below roughly 5k notes with no grant at all — only attachment bytes need it.

Reminders without the grant — Workable over Apple Events — the file lane is what makes search scale.

Calendar without the grant — Nothing — the only surface with no Apple Events read path fast enough to be a fallback.

Contacts without the grant — Nothing — but it asks for the Contacts permission rather than the whole disk, and unlike Full Disk Access that one prompts.

Messages without the grant — Nothing at all. Every read through Messages' own scripting interface fails, so this is the one surface with no second lane to degrade to.

Maps without the grant — Nothing at all — Maps is not scriptable, so the grant is the only way in.

Safari without the grant — Live tabs and page contents — the only things in the whole bundle that work with no Full Disk Access at all. Tabs need an Automation grant; page contents need the extension, allowed per website.

Simulator without the grant — Which simulators CoreSimulator knows and which are booted, read from its own plists. Everything on the device's screen needs Accessibility, and refuses by name until it is given.

One Full Disk Access grant, held by a notarized binary from an identifiable developer, instead of four grants handed out to whichever editors happened to spawn a server. The servers themselves stay MIT and free forever.

• A 30-minute trial, every surface at full function. Press the button; nothing arms itself.
• Every 1.x release, free. 2.0 is a new purchase; nothing lapses in between.
• Every Mac you own or control. No activation limit and nothing counts your installs.
• 30 days to change your mind, for any reason or none.
• No account, no login, no phone-home. The key verifies on your Mac and nowhere else.