What Is MCP?
The M×N integration problem MCP solves, the host/client/server model, and what the protocol does and doesn't standardize
What Is MCP?
TL;DR
MCP (Model Context Protocol) is an open protocol that standardizes how AI applications connect to external systems — data sources, tools, and workflows. Officially described as "like a USB-C port for AI applications": one standard connector instead of a different bespoke integration for every application-to-tool pairing. Current spec version: 2026-07-28.
| Property | Value |
|---|---|
| Level | Beginner — start here |
| Reading time | ~18 minutes |
| Prerequisites | None. If you've used a tool-calling AI assistant before, you're ready. |
| You will understand | The problem MCP solves, the host/client/server model, and what the protocol deliberately does not cover |
The Problem: M × N Integrations
Imagine three AI applications — a code editor's AI assistant, a chat app, and a custom internal tool — and three external systems they'd each like to use: GitHub, a company database, and a local filesystem.
Without a shared standard, each application has to write its own integration with each system. Three applications, three systems: nine separate, bespoke integrations, none of them reusable across the others. Add a fourth application or a fourth system and the number climbs multiplicatively — this is the classic M × N problem, where M is the number of applications and N is the number of external systems.
This isn't a hypothetical inconvenience — it's exactly what happened before a shared protocol existed. Every AI application maintained its own plugin format, its own auth handling, its own way of describing a tool to a model. A GitHub integration built for one chat app was worthless to any other application, even though the underlying problem — "let an LLM query GitHub" — was identical every time.
The Fix: M + N
MCP breaks the multiplication. Each external system is exposed once, as an MCP server. Each AI application implements the protocol once, as an MCP host. Any host can then talk to any server, because both sides speak the same protocol.
Without MCP: 3 apps × 3 systems = 9 bespoke integrations
With MCP: 3 apps + 3 systems = 6 total implementations (each side, once)The saving compounds as the ecosystem grows. A new tool author writes one MCP server and it's immediately usable by every MCP-compatible host that exists — Claude, ChatGPT, VS Code, Cursor, and others — without that tool author writing a single line of integration code for any of them specifically.
The one-sentence definition
MCP is a standardized protocol for context exchange between AI applications and external systems — not a specific tool, not a specific model, and not an agent framework. It's the connector, not the electronics on either end of the cable.
Host, Client, Server
MCP's architecture has three named roles, and getting the vocabulary precise matters — these terms get used constantly throughout this track.
| Role | Definition |
|---|---|
| MCP Host | The AI application that coordinates and manages one or more MCP clients — Claude Code, Claude Desktop, VS Code, Cursor |
| MCP Client | A connector inside the host that maintains a dedicated connection to one MCP server, obtaining context for the host to use |
| MCP Server | A program that provides context — tools, resources, prompts — to MCP clients |
One host, several servers
MCP Host
MCP Clients
MCP Servers
A host creates one client per server. If Claude Code connects to a local filesystem server and a remote Sentry server, it instantiates two separate MCP client objects, each holding its own dedicated connection. Connect to a third server and a third client object appears. This 1:1 client-to-server pairing is what lets each connection be independently managed — reconnected, capability-negotiated, or torn down — without affecting the others.
"MCP server" describes a role, not a location. A server can run locally on the same machine as the host (a filesystem server using stdio, launched as a subprocess) or remotely on someone else's infrastructure (a hosted server like Sentry's, reached over HTTP). Both are "MCP servers" in exactly the same protocol sense — the name refers to what the program does, not where it runs.
What MCP Standardizes — and What It Doesn't
In scope vs out of scope
In scope: context exchange
RecommendedThe message format for describing and invoking tools, exposing data, and offering templates (the data layer), and the mechanisms for actually transporting those messages between a client and a server (the transport layer).
Out of scope: how the host uses an LLM
MCP does not dictate which model a host uses, how it prompts that model, how it manages conversation state, or how it decides when to call a tool versus when to just answer. That's entirely the host's design — MCP hands it context, and what the host's LLM does with that context is outside the protocol's concern.
This separation is deliberate. It's what lets the same filesystem server work identically whether the host behind it is Claude, a different model entirely, or a non-LLM automated system that happens to speak MCP.
The MCP Project's Scope
"MCP" refers to more than just the wire protocol. The project includes four pieces:
| Piece | What it is |
|---|---|
| The Specification | The authoritative protocol document — implementation requirements for clients and servers |
| SDKs | Official libraries in multiple languages implementing the spec, so you write a typed function instead of hand-rolling JSON-RPC |
| Development Tools | Tooling for building and testing servers/clients, including the MCP Inspector |
| Reference Server Implementations | Working example servers (filesystem, and others) demonstrating the protocol in practice |
MCP also draws deliberate inspiration from the Language Server Protocol (LSP) — the standard that lets one code editor support many programming languages without a bespoke integration per language. MCP does the same thing for AI applications and external context: standardize the interface once, and the ecosystem on both sides can grow independently.
Broad Ecosystem Support
MCP is genuinely multi-vendor, not a single company's plugin format wearing an "open protocol" label. AI assistants including Claude and ChatGPT support it; development tools including Visual Studio Code and Cursor support it; dedicated MCP tooling like MCPJam exists around it. A server written once is reachable from all of them — this is the practical payoff of the M+N model, not just a theoretical one.
Build once, integrate everywhere is the actual value proposition, not a marketing line. If you're a developer exposing an API or dataset, writing one MCP server makes it usable from every MCP-compatible host that currently exists or will exist later — you never write host-specific integration code.
Concept Checks
Check yourself
Why does MCP turn an M×N integration problem into an M+N one?
Because each side of the connection only has to implement the shared protocol once, rather than once per counterpart. A tool author writes one MCP server, usable by every compatible host; a host author implements the client side once, able to reach every compatible server. The multiplicative cost of bespoke pairwise integrations disappears — the total work scales additively with the number of applications and systems, not multiplicatively.
A company hosts an MCP server for its product API on its own cloud infrastructure, reached over the internet. Is it still correctly called an 'MCP server'?
Yes. "Server" describes the protocol role — a program that exposes tools, resources, or prompts to clients — not where it physically runs. A remote, internet-hosted server and a local server launched as a subprocess on the same machine as the host are both MCP servers in exactly the same sense; only the transport (Streamable HTTP vs stdio) differs.
Does MCP specify which LLM a host should use, or how it should decide when to call a tool?
No. MCP standardizes context exchange only — the message formats for tools, resources, and prompts, and how those messages travel between a client and a server. Model choice, prompting strategy, and the agent loop deciding when to invoke a tool are entirely up to the host's own design and sit outside MCP's scope.
Key Concepts Recap
| Concept | One-line summary |
|---|---|
| M×N problem | Without a shared protocol, every app-to-tool pairing needs its own bespoke integration |
| M+N fix | Each side implements the shared protocol once; any host can then reach any server |
| Host | The AI application coordinating one or more MCP clients |
| Client | One per server, holds the dedicated connection, lives inside the host |
| Server | Exposes tools, resources, or prompts — local or remote, same protocol role either way |
| In scope | Context exchange — the data and transport layers |
| Out of scope | Model choice, prompting, and agent-loop design — the host's business |
| LSP inspiration | Same "standardize the interface once" idea, applied to editors and languages before MCP applied it to AI apps and context |
| Current spec version | 2026-07-28 |
Next
With the problem and the roles established, see how those roles actually communicate: The MCP Architecture.
MCP Crash Course
All of the Model Context Protocol on one page — architecture, primitives, transports, auth, and what changed in the 2026-07-28 spec
The MCP Architecture
The data layer vs transport layer split, and the stateless per-request model that replaced the old initialize handshake in spec 2026-07-28