What Is MCP, and Why Is Every AI Tool Suddenly Speaking It?
For most of the last decade, connecting an AI model to your company's tools meant a custom integration for every pair. Model Context Protocol, the open standard Anthropic introduced in November 2024, replaced that with one plug that fits everywhere — and OpenAI, Google, and Microsoft have all since adopted it. Here is how it actually works, and a real checklist before you connect one to your team's data.
Open Claude's desktop app and ask it to check your team's open pull requests, and it can just do that. Not because Anthropic built a GitHub integration into Claude. Because somewhere — your IT team, a vendor, a developer on GitHub — someone wrote a small program that speaks a protocol called MCP, and Claude already knows how to talk to anything that speaks it. The same is now true of ChatGPT, Google's Gemini, and Microsoft Copilot. That convergence, more than any single feature release, is why MCP has become the thing nearly every AI vendor spent the past year building support for.
What MCP actually is
MCP stands for Model Context Protocol. Anthropic designed it, and open-sourced the specification along with the first SDKs on November 25, 2024. Its own launch materials described the idea with an analogy that stuck: think of MCP as a USB-C port for AI applications — one physical connector standard instead of a different cable for every accessory. At launch, Anthropic named early adopters already building MCP support into their own products, including the enterprise software companies Block and Apollo, plus the developer-tool makers Zed, Replit, Codeium, and Sourcegraph. Claude's desktop app shipped, on the same day, with the ability to run MCP servers locally on a person's own machine.
The problem it solves: N tools times M data sources
The problem MCP solves has a name engineers use casually: the N-by-M integration problem. Say a company uses five AI tools that need to act on company data — Claude, ChatGPT, GitHub Copilot, Cursor, and an internal support bot — and that data lives in eight places: Slack, GitHub, a Postgres database, Salesforce, Notion, Google Drive, Jira, and an internal API. Without a shared protocol, connecting every tool to every source in a useful way takes up to forty separate integrations — five times eight — each with its own authentication scheme, its own error handling, and its own maintenance tax every time one of those APIs changes shape. Add a sixth AI tool and the number jumps to forty-eight. In practice, nobody built all forty. Each AI vendor built the handful it judged worth the engineering time, and everything else stayed manual: copy, paste, re-explain, repeat.
MCP turns the multiplication into addition. A company that wants Claude to read from its Postgres database does not build a Claude-specific Postgres connector. It builds — or reuses one someone else already published — one MCP server that exposes Postgres, and that server works with Claude, ChatGPT, Gemini, or any other MCP-compatible agent without further code. Anthropic's own list, at launch, named prebuilt servers for Google Drive, Slack, GitHub, Git, Postgres, and a browser-automation tool called Puppeteer. The point was never that Anthropic would build all of them. It's that anyone could, and the catalogue of available servers has grown well past what any single company could staff.
How the protocol actually works
Strip away the framing and MCP is a fairly plain client-server protocol, deliberately unglamorous by design. It defines three roles. A Host is the application a person actually opens — Claude Desktop, an IDE like Cursor, the ChatGPT app. The Host embeds an MCP Client, which opens a direct, stateful connection to an MCP Server — a small program that exposes one specific system: a database, a ticketing tool, a filesystem, an internal API. Client and server exchange messages formatted as JSON-RPC 2.0, a lightweight remote-procedure-call format already common across existing infrastructure, over one of two transports: stdio, when the server is a program running locally on the same machine, or Streamable HTTP, when it's a hosted service running somewhere else.
What a server can expose comes down to three primitives. Tools are functions the model can call to take an action — create_task, run_query, send_message — and the model decides when to call one based on the conversation. Resources are read-only context the Host can pull in and hand to the model without it having to ask — a file's contents, a database schema, a support ticket. Prompts are reusable, user-triggered templates — a canned "summarize this thread" or "draft a status update" that a person invokes explicitly, rather than something the model decides to do on its own. A well-built server is explicit about which of the three it's offering for a given capability, because that distinction is exactly what determines whether a connected AI tool can look at something or change it.
Who else picked it up, and when
MCP's first few months were an Anthropic-only project. That changed fast, and in a way that's genuinely unusual in AI: direct competitors converged on one company's protocol rather than shipping their own. OpenAI added MCP support to its Agents SDK in March 2025, letting developers connect agent workflows to any MCP server instead of building bespoke, OpenAI-specific tool integrations. The following month, Google DeepMind confirmed that Gemini and its own agent-development kit would support MCP as well — a move Google paired with its own complementary protocol, Agent2Agent, aimed at letting independent agents coordinate with each other rather than with tools. By May 2025, Microsoft had brought native MCP support to Windows 11 through what it calls Windows AI Foundry, with support also landing inside GitHub Copilot and Copilot Studio.
None of those four companies agree on much when it comes to model architecture, pricing, or platform strategy. All four now ship products that speak the same protocol for connecting an agent to a tool. That's rare enough in this industry to be the actual story — more than any individual feature MCP enables.
Why this is a trust question, not just plumbing
That convergence is genuinely useful, and it's also exactly why MCP deserves scrutiny rather than blind trust. A protocol that makes it trivial for an agent to connect to your company's systems is a protocol that makes it trivial for a badly built or badly configured connection to reach those same systems. MCP itself doesn't prevent that. The specification defines how a client and server talk to each other — it says nothing about who's allowed to grant a connection, what that connection is allowed to touch, or whether anyone will notice if something goes wrong. Those choices sit entirely with whoever built or configured the specific server or client in front of you. Some vendors build all of that carefully. Some don't build it at all, and the protocol will not stop them.
MCP is a wire protocol, not an access-control system. It standardises how an agent asks a tool to do something. Whether that ask is scoped, logged, and revocable is a decision someone made — or didn't — on top of it.
A checklist before you connect one
Before your team connects an MCP server — whether it's a vendor's product, an open-source tool someone found on GitHub, or something built in-house — six questions separate a governed connection from an open door. None of them require reading the specification. They just require someone to ask before clicking approve, and to actually read the answer the connection screen gives back.
| Ask this | What good looks like | Watch for |
|---|---|---|
| What scopes or tools does it request? | Itemized A named, specific list you can read before approving — "create tasks, read messages in this channel." | Blanket "Full account access" with no itemized list of what it can actually do. |
| Is it read-only, or can it write and act? | Separated Read access by default; any action that changes data needs its own visible grant. | Bundled Write access included automatically, with no way to tell which capability does what. |
| Is it per-person or shared team-wide? | Per-person Each person signs in with their own login; the agent can only see what that person can see. | Shared One API key or service account used by the whole team, bypassing individual permissions. |
| Is there an audit log of what it did? | Logged Every tool call recorded — who connected it, what it touched, and when. | Unlogged No record beyond whatever the AI tool itself chooses to tell you happened. |
| Can it be revoked instantly? | Immediate One toggle, effective right away, from a settings page you control. | Delayed Revoking requires a support ticket, a vendor call, or isn't possible at all. |
| Does revoking it break anything else? | Isolated Scoped to that one connection; turning it off affects only that. | Entangled Shares a credential with other tools, so revoking one quietly breaks three others. |
What a well-built connection actually looks like
FabricLoop's own MCP setup is one concrete answer to that checklist — not because it's unusual, but because each piece maps directly to one of the six questions above, and it's worth naming the actual mechanics rather than the marketing version of them. FabricLoop runs as both roles at once: it is an MCP server that outside tools connect into, so Cursor, Claude, or ChatGPT can create a task, add a comment, or read a note using a specific person's own FabricLoop permissions — and it is an MCP client that connects outward, so a channel can pull in a vendor's MCP app, like GitHub or Linear, and @mention it like a teammate.
Every connection, in either direction, starts with a person, not a workspace. Connecting an external client like Cursor opens an OAuth consent screen at app.fabricloop.com/oauth/consent, where that person picks a workspace and approves the specific tools the client is asking for — the client can then only act with the scopes granted on that screen, under that one person's permissions, never a shared service account. The reverse direction runs the same way: an admin can enable a vendor's MCP app for the whole team, but each person still completes their own sign-in before it works for them, and an admin can set that app to read-only mode or restrict it to an allowlist of specific tools instead of everything the vendor exposes.
Every connected client shows up on a settings screen next to a Revoke control that disconnects it immediately — the person's own page, not a support ticket. On Enterprise plans, that activity — including MCP grants and what a connected agent actually did — lands in an audit log a security team can review on demand, rather than screenshots pulled from a chat thread after the fact.
None of that is exotic engineering. It's a small, deliberately unglamorous set of decisions, repeated consistently: scope it, attach it to a person, log it, make it revocable without collateral damage. That's the same argument this site makes about Legibility more broadly — access you can name, log, and revoke beats access nobody has to think about — and MCP only delivers that when someone builds it that way. The protocol makes the plumbing standard. It doesn't make the governance automatic.
The decision that actually matters
MCP is not going away, and objecting to it at this point is a little like objecting to USB. Every major model provider now ships it, the list of available servers keeps growing, and an agent that can't reach your tools is, for most real work, an agent that can't do much. The interesting decision isn't whether to let an AI tool connect to your systems — increasingly, some version of that decision is already being made for you, one integration at a time, as tools your team already uses quietly add MCP support underneath a feature you clicked into without reading the fine print. The decision that's still actually yours is what you check before you click approve.
MCP standardised how an AI agent asks a tool to do something. It did nothing to standardise whether that ask is safe to grant — that part is still, and will remain, a decision for the person clicking "approve."