How to Connect Claude — or Any AI — to Any App on Your Mac
There are four ways to give an AI assistant access to your apps. Two of them only exist if you use Claude. All four leave the same gap: the apps already running on your Mac. Here is the whole map, honestly.
Summarize the unread emails in my inbox from this week and list anything that needs a reply today.
The four ways, in order of effort
Every method for connecting an AI assistant to an external app is one of these four. They are not competitors — most people end up using two or three at once.
| Method | What it covers | What it costs you |
|---|---|---|
| 1. Vendor connectors (a directory inside the AI itself) | Popular cloud SaaS: Gmail, Google Drive, Notion, Slack, Jira | Three clicks and an OAuth grant. Read-heavy and often shallow — the Gmail connector, for instance, writes a draft rather than sending the mail. |
| 2. Command-line tools ( gh, acli, stripe…) | Anything with an official CLI, usually deeper than the connector | A terminal, an installed binary, a stored credential — and an AI that is allowed to run shell commands. Most are not. |
| 3. An existing MCP server | Whatever someone already built — browsers, design tools, databases, your Mac | Finding the right one, then installing it. The good ones ship as an app; the rest want Node or Python and a hand-edited JSON config. |
| 4. Custom tools (the AI writes the script) | Internal APIs, private dashboards, anything with no public integration | Real code that you now own and maintain, plus credentials to store somewhere that is not your repo. |
Which of the four your AI actually has
This is the part most write-ups skip. Methods 1 and 2 are not universal features — they are properties of a specific product. Connector directories belong to the vendor that built them, and running shell commands is something only coding agents do. If you use Perplexity, Grok, Raycast or a local model runner, half the map is simply unavailable to you.
| Your AI | 1. Connectors | 2. Shell/CLI | 3. MCP | 4. Custom code |
|---|---|---|---|---|
| Claude Desktop & Claude.ai | Yes | No | Yes | Yes |
| Claude Code | Yes | Yes | Yes | Yes |
| ChatGPT (paid, developer mode) | Yes | No | Yes | Yes |
| Cursor, VS Code, Windsurf, Warp | No | Yes | Yes | Yes |
| Perplexity, Grok | Limited | No | Yes | No |
| Raycast, Goose, LM Studio, Msty, Jan, Cherry Studio | No | Varies | Yes | Varies |
MCP is the only column that is full on every row. That is not a marketing claim, it is the consequence of MCP being an open protocol rather than one vendor’s feature. Anything you connect through it survives you changing your mind about which AI you use — and everything you build on methods 1 and 2 does not.
The gap all four share: your own Mac
Look at what the four methods actually reach and a pattern shows up: cloud services with a public API. That is the whole territory. Now look at where your day happens:
- Apple Mail, Calendar, Contacts, Reminders, Notes, Messages — no connector, no CLI, no public API.
- Microsoft Teams and Slack desktop — the cloud APIs exist, but they need admin approval and tokens most people never get.
- WhatsApp, Signal — no official integration path at all.
- Finder, Safari, OmniFocus, local Word/Excel/PowerPoint/PDF files — nothing in the cloud to connect to.
Method 1 has nothing to offer here. Method 2 has no CLI to install. Method 4 means writing AppleScript and TCC permission handling yourself. Method 3 is the only door — which is why a local Mac MCP server exists.
Connectors write drafts. Local access sends.
The clearest illustration of the ceiling is the one connector everybody tries first: Gmail. It reads your mail well, and when you ask it to reply it produces a draft for you to open and send. That is a deliberate, sensible limit for an OAuth grant handed to a cloud service.
A local server has a different trust model, because nothing leaves the machine. LMCP’s send_email shows you a preview and then actually sends through the Mail app you are already signed into — the same account, the same signature, the same Sent folder. No OAuth grant, because there is no third party to grant anything to.
One install, every client
The hidden cost of methods 1, 2 and 4 is that they are per-AI. Authorize connectors in Claude, install CLIs for your coding agent, write custom scripts against one runtime — then try ChatGPT for a week and none of it comes with you.
A single MCP server does come with you. LMCP installs once, auto-configures the desktop clients it finds (Claude Desktop, Cursor, VS Code, Windsurf, Raycast, Warp, Goose, LM Studio, Msty, Jan, Cherry Studio) and reaches the web AIs — Claude.ai, ChatGPT, Grok, Perplexity — through an encrypted relay. Same 239 tools, same permissions, whichever assistant you happen to be using that day.
When you should not use a local MCP server
Being the only door for Mac apps does not make it the right door for everything:
- GitHub, Stripe, Supabase, Jira — use the official CLI (method 2). It is deeper than any wrapper: it creates releases, not just reads them.
- Google Drive, Notion, Linear as your team’s system of record — the vendor connector (method 1) is three clicks and is maintained by the vendor.
- Your company’s internal API — nobody has built that server. Method 4, and that is fine.
The honest split: cloud services → connectors and CLIs. Your Mac → a local MCP server. Most people need both.
Custom tools without writing the code
Method 4 is where the maintenance burden usually lands: the AI writes a script, it works, and six months later you own an undocumented integration with a credential in it. LMCP’s recipes cover the same ground differently — you describe a repeatable job in plain language (“every Monday, pull last week’s Teams mentions and draft a summary email”), it is saved as a named recipe, and it runs from any connected AI. The credentials stay in the apps you already signed into; there is no script and no secret to store.
Is giving an AI this much access safe?
It is the right question, and the answer differs sharply by method. Methods 1 and 2 hand a token to a third party; method 4’s risk is whatever your script does. Automating a cloud service through an unofficial path carries a real account-suspension risk — that warning is well earned.
A local server changes the shape of the risk rather than eliminating it:
- Nothing leaves the Mac. Your mail, messages and files are read on the machine and handed straight to your assistant. There is no server of ours holding them.
- macOS is the gatekeeper. Access to Calendar, Contacts, Reminders and Automation goes through the system permission prompts. Revoke any of them in System Settings and the corresponding tools stop working immediately.
- Destructive actions preview first. Sending, deleting and moving show you exactly what will happen before it happens.
- One honest exception: WhatsApp has no official desktop API, so that integration uses an unofficial client and carries the account risk that implies. Every other integration reads apps you already run, on hardware you own.
Setting it up
- Install LMCP (a signed, notarized Mac app — no Node, no Python, no JSON editing).
- Approve the macOS permission prompts for the apps you want reachable.
- Desktop AI clients are detected and configured automatically. For web AIs, copy the connector URL from the menu bar and paste it into Claude.ai, ChatGPT, Grok or Perplexity.
- Ask your assistant something it could not answer an hour ago — “what did I miss in Teams yesterday?” is a good first test.
Full walkthrough: Getting Started with LMCP.