MCP explained, without the jargon

Model Context Protocol (MCP) is the AI world's flavor-of-the-month acronym, and most explanations of it are word soup. If you've had an ML engineer breathlessly explain "the schema is JSON-RPC, the tools list is queryable, and it supports both stdio and HTTP transports" — you probably left the conversation knowing less than when you started.

Here's what MCP actually is: a small, boring protocol that standardises how AI agents talk to the tools they need to do work. That's it. That's the whole thing.

Boring is a compliment. The interesting thing MCP does isn't in the spec — it's what happens once you have a common protocol.

The problem MCP solves

Before MCP, every AI agent product integrating with every tool required a custom, one-off adapter. To connect a LangChain agent to Slack, you wrote glue. To connect Claude to Slack, you wrote different glue. To connect ChatGPT to Slack, more glue. Every tool times every agent framework, times every AI provider — an N × M explosion of bespoke code, most of it duplicated with minor variations.

The result was predictable:

• Agent frameworks were opinionated silos. LangChain wanted you inside LangChain. Semantic Kernel wanted you inside Semantic Kernel. Portability was theoretical.
• Tools couldn't reach users directly. If Notion wanted their tool available to Claude, they had to build a Claude-shaped integration. If they also wanted ChatGPT support, they had to build a second one. Most tool vendors did neither.
• Enterprise auth was chaos. Every integration invented its own OAuth pattern, its own per-user scope, its own token storage. Security reviewers hated it.
• The market couldn't specialise. There was no incentive for a small team to build "the best MCP server for GitHub" because there was no MCP to build for.

MCP fixes this the way HTTP fixed pages talking to each other, or SMTP fixed mail talking to mail: one standard, everybody speaks it, the market grows around it.

What MCP actually is

Boiled down: MCP is a protocol that lets an AI client (an agent, an assistant, an IDE like Cursor, whatever) talk to an MCP server (a tool, a data source, a piece of software offering capabilities to the model).

The server exposes a small, well-defined API:

• tools/list — "here are the actions I can perform" (e.g., slack_post_message, slack_read_thread)
• tools/call — "please perform this action with these arguments"
• resources/list and resources/read — "here are things you can read" (files, documents, URIs)
• prompts/list and prompts/get — "here are pre-crafted prompts I ship for common workflows"

The transport is JSON-RPC, either over stdio (for local tools) or HTTP with SSE (for remote/hosted tools). Auth for remote MCP is OAuth 2.1, with dynamic client registration when the server supports it. There are some other bits — sampling, roots, notifications — that don't matter for the mental model.

That's the technical shape. The important part is what it enables.

Why this matters

Four consequences flow from having a common protocol:

1. Write the integration once. An MCP server for GitHub works for Claude, ChatGPT, Cursor, VS Code, custom agents, agent platforms — anyone who speaks MCP. The vendor of the tool controls the surface; every AI client picks it up as-is. No more N × M glue.

2. Users can install their own tools. Because the protocol is standard, an end user can point their agent at any MCP server URL and have it work — as long as their agent supports MCP. This changes the "walled garden" default: instead of the vendor picking which integrations you get, you pick.

3. Enterprise auth becomes tractable. OAuth 2.1 with per-user scope means IT can integrate an MCP server once and every user connects their own account. Tokens live in a known place; audit is uniform; access can be revoked cleanly. Compare to the pre-MCP world of "every integration has its own auth story and half of them store tokens in plaintext."

4. The market can specialise. With a common protocol, small teams can build "the best MCP server for Salesforce" or "the fastest MCP server for Postgres" and know their work will be usable across every agent platform. That's a functioning market. Before MCP, it was a series of closed loops.

What MCP is not

Worth clearing up, because vendors muddy this:

MCP is not an agent framework. It doesn't tell you how to prompt the model, how to plan multi-step actions, how to handle memory. It handles one layer: the tool interface between the model and the outside world. Agent frameworks (LangChain, Semantic Kernel, custom runtimes) sit above MCP.

MCP is not model-specific. Any model that can produce a structured tool call — every serious LLM at this point — can drive an MCP client. Claude launched it, but OpenAI, Google, and every open-weight model with tool-calling support work with MCP just as well.

MCP is not just for local tools. The early demos ran locally over stdio (Claude Desktop reading your filesystem, for example). The interesting deployment is remote MCP over HTTP — where a hosted MCP server sits behind an OAuth flow, users connect their own accounts, and the agent can call the tool from anywhere.

MCP is not a replacement for RAG. RAG is a pattern for retrieving relevant text. MCP is a pattern for calling tools. You often use both — the agent calls an MCP tool to fetch documents, then the retrieved text goes into the model's context. Different jobs, complementary.

The current state of MCP

As of mid-2026, MCP is well past the "will this catch on" phase:

• Anthropic launched it in late 2024. The spec has iterated through 2025 and into 2026; the churn has slowed and the shape feels stable.
• Every major model client supports it. Claude Desktop and Claude on the API, ChatGPT via Custom Actions, Gemini, Cursor, VS Code, Zed, most emergent agent platforms.
• First-party MCP servers exist for the tools that matter. GitHub, Notion, Slack, Linear, Google Workspace (Drive, Docs, Sheets, Calendar, Gmail), Salesforce, HubSpot, Figma, Asana, Postgres, Snowflake, and a long tail.
• OAuth is mature. RFC 9728 (protected-resource metadata), RFC 8414 (authorization-server metadata), RFC 7591 (dynamic client registration) — MCP servers that speak these give agents a clean per-user consent flow.
• Hosted MCP marketplaces are emerging. Cloudflare, Anthropic, and independent providers all offer registries. Discovery is starting to be a solved problem.

The remaining friction is around per-user vs. per-workspace scope (does an OAuth token belong to the user or the org?), and around trust — an MCP server is code the vendor runs, and giving it access to your tools requires the same due diligence as any other SaaS integration.

Practical implications for buyers

If you're evaluating an AI agent platform:

1. "Does it support MCP?" is a legitimate first-round question. If the answer is "we're planning to add it," the vendor is behind.
2. Ask specifically about remote MCP over HTTP. Local-only support means the platform can call tools on your laptop but not the SaaS your team actually uses.
3. Look at how they handle OAuth. Per-user token storage, RFC-standard flows, per-user revocation — these should exist, not require a support ticket.
4. Understand the trust model. If admins register MCP servers workspace-wide, who authorises what? Can members register their own? How do you revoke a bad server?
5. Watch for lock-in via non-MCP integrations. A vendor doing custom, non-MCP integrations for each tool is choosing to compete with the standard. That's usually a signal about how they see their moat.

The takeaway isn't that MCP is magic. It's that MCP is sufficient — a well-designed, boring protocol that lets the market build ecosystems around AI agents the same way SMTP and HTTP let the market build ecosystems around email and web pages.

What comes next

Two things worth watching over the next 12 months:

• OAuth-secured, hosted MCP as the default. The stdio + local-file era of MCP was where it grew up. Remote MCP is where it scales.
• Marketplace consolidation. Right now every provider (Anthropic, Cloudflare, community registries) has its own MCP catalog. That fractured surface will consolidate.

For teams building agents right now: bet on MCP. The alternatives — bespoke integration per tool, per model — will look increasingly quaint by the end of the year. MCP is the substrate; everything worth building sits on top.

Gauss agents are MCP-native by default. Admins can register any MCP server for their workspace; members can register their own personal MCPs when they want to. OAuth flows are standard where the upstream MCP supports them. It's the plumbing that makes the "reach" ingredient we wrote about last time actually deliverable — one protocol, every tool your team uses.

— The Gauss team