iMCP: a macOS menu bar app that turns Messages, Contacts and Reminders into MCP tools

The gap iMCP fills: Apple's data silos have no MCP endpoint

Calendar, Contacts, Messages and Reminders live behind Apple's permission prompts and private frameworks, not behind an HTTP API. An MCP client such as Claude Desktop can call tools, but it has no way to reach those stores on its own. iMCP closes that gap by shipping a native macOS app that hosts an MCP server and a bundled executable named imcp-server, which the client launches as a subprocess. The audience is narrow and specific: people already running an MCP-capable client on a Mac who want the assistant to answer questions like "How's the weather where I am?" using real location and weather data rather than a typed-in guess. It is not a general automation tool and it is not a server you deploy anywhere. The README frames it as connecting "your digital life with AI," and the seven capabilities listed are all local macOS data sources.

How the app, the permissions and the MCP server fit together

The architecture has three layers. The outermost is a menu bar app with a blue toggle that indicates whether the MCP server is running. The middle layer is a set of per-service permission grants handled by Apple's standard security model: activating Calendar triggers a dialog reading "iMCP" Would Like Full Access to Your Calendar, and each service icon shifts from gray to a color when granted. The inner layer is imcp-server, the executable the client actually spawns. Tool calls flow from the client to that process, which reads the granted stores and returns results. Two details matter here. First, the README states plainly that iMCP does not collect or store your data, and then adds the qualifier that clients like Claude Desktop do send your data off device as part of tool calls. Second, permissions are per service, so the surface you expose is exactly the set of icons you have colored in. Leaving Messages gray keeps message history out of reach of the model, which is the practical way to scope this thing down.

Installing iMCP and getting 12 tools into Claude Desktop

The README gives two install paths: a download from iMCP.app/download, or a Homebrew cask. Both require macOS 15.3 or later.

brew install --cask mattt/tap/iMCP

After launching, a menu bar icon appears. Click it and the menu lists every service, all initially gray. Click a service icon, accept the permission dialog, and repeat for each capability you want. The blue toggle at the top of that menu is what tells you the MCP server is up.

For Claude Desktop, the app writes the client configuration for you: click the menu bar icon, then "Configure Claude Desktop". That adds or updates the MCP server entry to point at the bundled imcp-server executable and preserves any other MCP server entries already in the file. The file lives at `~/Library/Application Support/Claude/claude_desktop_config.json`, and the README shows the manual shape if you would rather edit it yourself:

{
  "mcpServers": {
    "iMCP": {
      "command": "{paste iMCP server command}"
    }
  }
}

Quit and reopen Claude Desktop, approve the connection prompt, and a hammer icon with the number 12 appears at the bottom right of the chat box. Clicking it lists the tools iMCP has contributed. If you use Claude Code instead, the README gives a single command to register the server globally:

claude mcp add --scope user iMCP -- /Applications/iMCP.app/Contents/MacOS/imcp-server

Where iMCP stops: platform lock-in and data leaving the device

The first limitation is the operating system. iMCP requires macOS 15.3 or later and is distributed as a macOS app with a bundled Mach-O executable at a fixed path inside the bundle. There is no Linux build, no Windows build, and no container image, so a headless server or a CI runner is simply not a target. The second is the data path. The README's warning is worth reading twice: iMCP itself does not collect or store data, but the client sends your data off device as part of tool calls. Anyone who wants message history to stay on the machine needs to leave the Messages icon gray, because there is no documented local-only mode that still lets a remote model reason over the content. The third is scope of access. Granting Calendar is full access, not filtered access, and the README does not describe a way to restrict which calendars or which reminder lists are visible to the server. If your threat model cannot tolerate a model reading a work calendar alongside a personal one, this is the wrong tool.

iMCP versus writing your own Swift MCP server

The realistic alternative is a hand-written MCP server in Swift, built on the same protocol and pointed at EventKit, Contacts and the Messages database. That approach gives you control over which fields are exposed, how results are filtered, and where the process runs; it also means you own the permission plumbing, the menu bar or daemon lifecycle, and every schema change. iMCP trades that control for a working app: seven capabilities, a permission flow that uses Apple's standard dialogs, and a one-click configuration writer for Claude Desktop. The trade is real in both directions. You cannot reshape iMCP's tool schemas to fit a narrower policy, and you inherit its release cadence for fixes. In exchange you skip the parts that are tedious rather than interesting, which for most people evaluating MCP clients is the whole point. Note that the README's capability table describes behavior such as recurrence and alarm settings on calendar events and priority and alert settings on reminders, so the tool surface is broader than simple read access.

Maintenance, licensing and the upgrade question

The repository is not archived, and the last push was on 2026-09-08, which is recent enough that the project is being worked on. Release history is uneven rather than steady: 1.4.1 landed on 2026-05-07, 1.4.0 on 2026-01-30, and 1.3.0 on 2025-06-23, so expect gaps of months between tagged releases. That cadence matters because the app is distributed as a binary with a bundled server executable, and the client configuration points at a path inside the app bundle. Replacing the app in place is the upgrade path the README implies, but the README does not document rollback, does not describe a versioned config migration, and does not say what happens to an existing claude_desktop_config.json entry when the bundle path changes. The license is MIT, which permits commercial and private use and modification; the LICENSE.md file at the repository root is the authoritative text, and nothing here is legal advice. One licensing-adjacent point worth flagging: the MIT grant covers the code, not the Apple frameworks it calls, so your use of Calendar, Contacts and Messages data is still governed by Apple's platform terms.

Editorial conclusion

Adopt iMCP if you already run Claude Desktop or Claude Code on macOS 15.3 or later and want tool calls against Calendar, Contacts, Messages or Reminders without writing a Swift bridge yourself. Skip it on Linux or Windows, on macOS older than 15.3, and anywhere you cannot accept that the client, not iMCP, ships tool results off device. Before trusting it, open the menu bar and confirm which service icons are colored rather than gray, then check the 12 tools listed in Claude Desktop match the services you actually enabled. The README does not document rollback of the claude_desktop_config.json edit, so back that file up first.

Frequently asked questions

Official sources

1. License: MIT
2. mattt/iMCP on GitHub
3. Project website
4. README
5. Releases