iMCP ships an MCP server as a native macOS app, so Claude Desktop and Claude Code can read your local data through Apple's permission dialogs. The catch is where the tool call result ends up.

Can I use mattt/iMCP commercially?

Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is mattt/iMCP still maintained?

Yes. The repository last received commits 7 days ago.

What programming language is mattt/iMCP written in?

Mainly Swift, according to GitHub's language statistics.

iMCP review: a macOS MCP server for Messages, Contacts, Calendar and Reminders

At a glance

What is it?: iMCP ships an MCP server as a native macOS app, so Claude Desktop and Claude Code can read your local data through Apple's permission dialogs. The catch is where the tool call result ends up.
Who is it for?: Adopt iMCP if you already run Claude Desktop or Claude Code on macOS 15.3 or later and want local Calendar, Contacts, Messages, Reminders, Maps, Location and Weather data reachable as MCP tools without writing a server yourself.
Can I use it commercially?: Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository last received commits 7 days ago.
What is it written in?: Mainly Swift, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 11, 2026 · mattt/iMCP

The gap iMCP fills: local macOS data behind a permission dialog

Most MCP servers wrap a remote API or a local file tree. iMCP wraps the databases that macOS already holds on your behalf, and it does so through the same consent mechanism as any other Mac app. The README describes the flow plainly: you click a service icon in the menu bar, macOS shows a dialog such as "iMCP" Would Like Full Access to Your Calendar, and you click Allow Full Access. There is no API key to paste and no OAuth round trip. The audience is narrow and specific: people who run an MCP-capable client on a Mac and want the model to answer questions like "How's the weather where I am?" using their own location rather than a typed-in city. That example is the one the README gives, and it is a good illustration of the design intent. The value is not that these tools are hard to build individually. It is that a single app registers the permissions once and exposes them all under one server.

Seven services, twelve tools, one stdio server

The README lists seven capabilities: Calendar, Contacts, Location, Maps, Messages, Reminders and Weather. Calendar covers viewing and managing events, including recurrence, alarms and availability status. Contacts covers your own contact record plus search by name, phone number or email. Messages reads message history with specific participants inside a date range you choose. Reminders supports reading and creating entries with due dates, priorities and alerts across lists. Maps does place search, directions, points of interest, travel time estimation and static map image generation. Location returns current position and converts between addresses and coordinates. Weather returns temperature, wind speed and conditions for a location. The transport is not HTTP. The README's Claude Code example registers a binary path, /Applications/iMCP.app/Contents/MacOS/imcp-server, which means the client spawns that executable and talks to it over stdio. The menu bar app is the front end for permissions and configuration; the executable is what the client actually launches. That split is worth understanding before you debug anything, because a failure in the app's menu does not necessarily mean the server binary is missing, and vice versa.

Install and wire it up: Homebrew, Claude Desktop, Claude Code

The documented install paths are two. Download from https://iMCP.app/download, or run brew install --cask mattt/tap/iMCP. The app requires macOS 15.3 or later, which is stated in the Getting Started section and is a hard floor, not a suggestion. After launch you get a menu bar icon. Services start gray and inactive; clicking one triggers the macOS permission prompt, and once granted the icon takes on its service color, red for Calendar, green for Messages, blue for Location. The blue toggle at the top of the menu indicates the MCP server is running. For Claude Desktop, the app can do the wiring for you: click the menu bar icon, then Configure Claude Desktop. According to the README, this adds or updates the MCP server entry to point at the bundled imcp-server executable and preserves other MCP server configurations already in the file, which lives at ~/Library/Application Support/Claude/claude_desktop_config.json. The manual route is Copy server command to clipboard, then paste into a mcpServers block with a command key. For Claude Code the README gives one line: claude mcp add --scope user iMCP -- /Applications/iMCP.app/Contents/MacOS/imcp-server. After that you quit and reopen Claude Desktop, approve the connection prompt, and the chat box should show a tool count (the README shows 12) that you can click to list the available tools.

The privacy claim is narrower than it sounds

The README carries an important note in its own words: iMCP does not collect or store any of your data, but clients like Claude Desktop do send your data off device as part of tool calls. Read those two clauses together and the architecture becomes clear. iMCP is a local reader with a local process boundary. It is not a filter, a redactor or a policy layer. If a tool call returns message history with a named participant, that text is in the model provider's request. The permission dialogs control what iMCP can read from macOS; they do not control what the client does with the result. Anyone evaluating this for a workplace should treat the MCP client's data handling as the governing question, not iMCP's. The app's own claim is about storage and collection on the Mac side, and that claim is consistent with a native app that reads through Apple's frameworks rather than shipping data to a backend. It is simply a different claim from end-to-end confidentiality.

Where iMCP is the wrong tool

Three constraints stand out. First, platform and version: macOS 15.3 or later, and the server is a Mach-O executable inside an .app bundle. There is no documented Linux or Windows path, and the Homebrew formula is a cask, which is the macOS artifact type. Second, the client must be able to launch a local process and speak MCP over stdio. A hosted or browser-based MCP client that expects a URL will not work with the documented setup. Third, the permission model is interactive. Someone has to click Allow Full Access for each service on that machine. That makes iMCP a poor fit for unattended or ephemeral environments: a fresh CI runner, a shared build box, or a VM that is rebuilt nightly will need those grants again, and the README does not describe a scripted way to pre-grant TCC permissions. There is also a subtler issue. The full-access grants are broad by design. If you only want the model to see weather, enabling Messages and Contacts as well widens what any tool call in that session can reach. The README's advice to repeat the process only for the capabilities you'd like to enable is the right instinct, and it is the main operational discipline this app asks of you.

How it compares to writing your own MCP server

The obvious alternative is a hand-rolled MCP server in Swift, Python or TypeScript that calls EventKit, Contacts, MapKit and the Messages database directly. That approach gives you exact control over which fields leave the process, how results are shaped, and whether a query is logged. It also means you own the permission plumbing, the entitlement setup, the code signing, and every schema change across the seven services. iMCP trades that control for a signed, packaged app with a menu bar UI, a Configure Claude Desktop button that edits claude_desktop_config.json for you, and a cask install. A second alternative is a remote MCP server that fronts a cloud calendar or contacts service. That avoids local permissions entirely but only covers data you have already synced to that service, and it puts a third party in the path by construction. iMCP's distinguishing choice is that the data never leaves the Mac until the client decides to send it, and the app itself is the permission surface. If your priority is a narrow, auditable tool set, the custom server wins. If your priority is getting seven services working this afternoon on one Mac, the packaged app wins.

Maintenance cost and what the MIT licence does and does not cover

The repository is MIT licensed and is not archived. Release cadence visible in the material is uneven: 1.3.0 in June 2025, 1.4.0 in January 2026, 1.4.1 in May 2026, with the most recent push in September 2026. That is roughly one feature release every six to seven months plus a patch, which is normal for a small macOS utility but means you should not expect rapid tool-schema churn to be fixed within days. The practical upgrade cost is low if you installed via the cask, since brew upgrade --cask iMCP handles the app bundle, and the bundled server path stays the same. The cost is higher if you pinned the absolute path /Applications/iMCP.app/Contents/MacOS/imcp-server in a config that lives outside your control, because moving or renaming the app breaks the client silently. On licensing: MIT covers the source in the repository. It does not tell you anything about the terms under which the prebuilt app from iMCP.app is distributed, and it does not address what your MCP client's provider does with tool call results. Those are separate questions, and I am not in a position to give legal advice on either. If your organisation has data-handling requirements around message content or contact records, the place to look is the client's terms, not this licence file.

Editorial conclusion

Adopt iMCP if you already run Claude Desktop or Claude Code on macOS 15.3 or later and want local Calendar, Contacts, Messages, Reminders, Maps, Location and Weather data reachable as MCP tools without writing a server yourself. Do not adopt it if you need a headless server for CI, a Linux host, or a client that cannot spawn a stdio process, and do not treat it as a privacy boundary: the README states that clients like Claude Desktop send your data off device as part of tool calls. Before you rely on it, verify the bundled path /Applications/iMCP.app/Contents/MacOS/imcp-server exists on your machine, confirm which of the twelve tools your client actually lists after you approve the connection, and check whether the tool set changed between 1.4.0 and 1.4.1.

Official sources

Community notes