MCP for Mac Users: What Connecting Gmail to a Local Agent Actually Does

If you have connected an AI assistant to Gmail, Notion or Slack in the last year, you have almost certainly used MCP without being told. It is the plumbing behind the Connect button, and it is worth ten minutes of understanding, because the choices it exposes are the ones that determine whether "local-first" means anything in your setup.

This is written for the person clicking Connect, not the person writing a server.

What it is#

The Model Context Protocol is an open standard for connecting AI applications to external systems. The spec's own analogy is the good one:

Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.

Before it, every assistant wrote its own Gmail integration, its own Notion integration, and you were limited to whatever your vendor had got around to. Now anyone can publish a server and any client can speak to it. Claude, ChatGPT, VS Code and Cursor all support it. So does Jarvis.

The important consequence for you is portability. Your connections are not a feature your assistant's vendor grants you; they are a standard your assistant speaks. Switching assistants does not mean rebuilding your integrations.

Three things a server can offer#

Worth knowing because the words appear in permission dialogs:

• Tools — executable functions the AI can invoke: send an email, create an event, query a database. These are the ones that change the world.
• Resources — data sources it can read: file contents, records, API responses.
• Prompts — reusable templates, the least interesting of the three from a safety point of view.

When you evaluate a connection, the question is which tools it exposes. "Reads your calendar" and "manages your calendar" are different servers even when the button looks identical.

The distinction that actually matters#

Here is the part that gets lost, and it is not really about MCP at all.

Local servers communicate over stdio — standard input and output between two processes on the same machine. The server is a program running on your Mac. A filesystem server reading your documents never touches a network. If your reason for choosing a local-first assistant is that your data should stay on your hardware, local MCP servers are consistent with that.

Remote servers use HTTP, live on someone else's infrastructure, and authenticate with bearer tokens or OAuth. When you connect a hosted Notion or Sentry server, your requests leave your machine.

Both are MCP. The protocol is identical. But "we support MCP" tells you nothing about where your data goes, and a tool that is scrupulously on-device for inference can still be shipping every calendar query to a third party through a remote connector. The question to ask about any connection is simply: is this server running on my machine, or someone else's?

What "Connect Gmail" actually does#

Roughly: you are sent to Google, you approve a set of scopes, and your assistant receives a token it stores and replays on your behalf.

Three practical consequences.

The scopes are the real permission. Not the marketing copy — the list on Google's consent screen. Read-only calendar access is a fundamentally different grant from full mailbox access, and an assistant asking for the second to do the first is telling you something about how it was built.

Revocation happens at the provider. Deleting the app from your Mac does not invalidate the token. Go to Google's account permissions page, Slack's app management, and remove it there.

The token outlives the machine. Everything else you grant an assistant is bounded by one laptop. This is not.

What changed in July 2026#

If you read older MCP writing, two things are now out of date, and both are in the current spec dated 2026-07-28.

Sampling is deprecated. It let a server ask the client to run a model completion, so server authors could stay model-independent. The spec now says new implementations should integrate directly with LLM provider APIs. Logging is deprecated alongside it, in favour of stderr or OpenTelemetry.

Elicitation is the client primitive that remains, and it is the interesting one: it lets a server request more information from the user mid-operation, or ask for confirmation of an action. That is the protocol-level hook for "are you sure you want to send this," which is the right place for it to live.

The protocol also went stateless — every request carries the protocol version and capabilities in a _meta field, so a server infers nothing from previous requests, and servers advertise themselves through a server/discover call. Practically this matters because it makes remote servers far easier to scale and cache, which is why you will see more hosted connectors, which loops back to the local-versus-remote question above.

A short checklist before you connect anything#

1. Local or remote? If the point of your setup is on-device, prefer servers that run on your machine.
2. Which tools does it expose? Read actions matter less than write actions. Anything that can send, delete or pay deserves a pause.
3. What scopes is the provider asking for? The consent screen is the contract.
4. Where do I revoke it? Know before you grant, not after.
5. Does it need to be connected all the time? Many connectors are used once a month and left live forever.

Why this is the interesting layer#

Models are converging and none of them knows anything about you. What differs between assistants now is what they are allowed to touch and what they remember between sessions. MCP is the standard for the first half of that, which is why it went from an Anthropic proposal to something ChatGPT, VS Code and Cursor all speak inside a year.

The second half — the memory — is not standardised and probably will not be, which is the argument for keeping it somewhere you control. More on that in what a real Mac agent looks like.

Jarvis speaks MCP, is free and open source, and runs on-device by default. If you want the developer-facing view of the same territory, we wrote about what changes when your tools run on someone else's computer.