What Is Model Context Protocol (MCP)? How It Works in 2026
What Model Context Protocol is, how AI apps use it to reach tools and data under the 2026-07-28 spec, who runs it, and how to start using or building a server.
MCP, short for Model Context Protocol, is a shared standard for plugging AI apps into other software. Someone builds one MCP server for a tool, say Slack or GitHub, and every AI app that speaks MCP can use it. Nobody has to build a separate connection for each app. The official docs compare it to a USB-C port for AI applications.
It isn't an experiment anymore. As of the July 2026 spec release, MCP's main SDKs were getting close to half a billion downloads a month, and Claude, ChatGPT, VS Code, and Cursor all support it. If you've added a connector in one of those, you've already used it.
Anthropic created MCP. In December 2025 it gave it to the Agentic AI Foundation, part of the Linux Foundation, which now looks after it.
The problem MCP solves
Before MCP, connecting an AI model to a tool meant custom code for that exact pair. Claude to Slack was one build. ChatGPT to Slack was another. OpenAI's API to Stripe was a third.
The math gets ugly fast. Ten tools and five AI apps meant fifty separate connections to build and keep working. In general, N tools and M apps meant N times M.
MCP turns that into N plus M. Each tool gets one MCP server. Each AI app learns to speak MCP once. After that, any app can use any server right away.
The bigger win is reuse. If a server already exists for a tool, connecting it is a settings change, not a project.
How MCP works
The current specification is version 2026-07-28, released July 28, 2026. The architecture overview describes four pieces.
Hosts, clients, and servers
The AI app you're using, such as Claude Code or VS Code, is called the host. For each server it connects to, the host creates one MCP client, a small piece of it whose only job is talking to that server.
A server is any program that gives the AI something to work with. It can run on your own machine, started by the host, or live somewhere else and be reached over the internet.
Messages that stand on their own
Every message uses a standard format called JSON-RPC 2.0.
Under the 2026-07-28 revision, each request carries everything the server needs to answer it: the protocol version and what the client can do, tucked into a _meta field. So a server can handle any request without remembering an earlier conversation. That's what "stateless" means here.
Earlier versions started every connection with an initialize exchange first. Clients still fall back to that when they meet an older server.
Two ways to send messages
Servers on your own machine use stdio: the host starts the server as a program and they pass messages back and forth through its standard input and output, one per line.
Remote servers use Streamable HTTP. Each message is an HTTP POST to one address, and the reply comes back either as a single JSON object or as a short stream of updates for that one request (transports spec).
Three things a server can offer
- Tools are actions. "Send a Slack message." "Create a GitHub issue." The client calls a tool with
tools/call, and the server runs it and sends back the result. - Resources are data the client can read. "The files in this Drive folder." "This repository's code."
- Prompts are reusable templates. "A standard prompt for writing SQL queries." The client asks for one by name and gets it back with blanks to fill in.
How a client finds out what's available
A client can send server/discover to learn which protocol versions and features a server supports. Then it sends tools/list, resources/list, or prompts/list to see what's on offer.
Each tool comes back with a name, a plain-language description, and a JSON Schema that spells out what inputs it takes. The model reads those to decide what to call. Because the description travels with the server, nobody has to write a separate setup guide for every AI app. That's why MCP scales.
Two more pieces you'll see mentioned. Servers can stop partway through a request to ask the user for input, which the spec calls elicitation. And sampling, where a server asks the client's model to write something for it, is deprecated as of 2026-07-28.
To watch discovery and a tool call happen on your own machine, the course lesson Build an MCP server and client for a ticket-label tool runs both sides with the Python SDK against the 2026-07-28 protocol. It tests good calls, calls with the wrong inputs, and protocol errors.
How widely it's used in 2026
Two numbers show how far it has spread. Both need their limits spelled out.
- Downloads. The 2026-07-28 release post reports close to half a billion monthly downloads across the Tier 1 SDKs, with the TypeScript and Python SDKs each past one billion total. In December 2025 the figure was 97 million a month.
- Servers. The last official count is "10,000 active servers", from that same December 2025 post. The official MCP Registry is a better place to look now. On September 27, 2026, its public API listed about 36,700 server names at their latest version, of which about 36,300 were marked active. That count comes from paging through the registry's public API on that date, not from an official figure. It counts listings, not servers anyone checked actually work, and the registry is still in preview.
On the app side, the MCP docs list Claude, ChatGPT, VS Code, and Cursor among the applications that support it. Coding agents do too. MCP servers for coding agents walks through adding one to Claude Code and Codex.
Who runs it. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a fund run under the Linux Foundation. Anthropic, OpenAI, and Block co-founded it, with Google, Microsoft, AWS, Cloudflare, and Bloomberg backing it. The announcement says the same people keep maintaining MCP and the Linux Foundation won't dictate its technical direction. The specification repository is MIT-licensed.
Search the official MCP Registry before you build anything. If your tool doesn't have a server yet, the SDK docs cover the official language SDKs, and a server that offers one tool is a small program.
What MCP looks like at work
Three example setups show where it fits. They're sketches of how the pieces connect, not reports on real companies.
Customer support. A support team connects servers for its help desk, its billing system, and its internal knowledge base. When a ticket comes in, the assistant reads it, looks up the customer's account, searches the knowledge base, and drafts a reply. The same servers work from any MCP app the team uses.
Code and monitoring. An engineering team connects its code repository and its monitoring tool. The agent in their editor can read code, search logs, and suggest a fix without leaving the editor, and the servers stay inside the company network.
Payments. A team wraps its payment provider in an MCP server so an assistant can check whether a payment went through. Issuing a refund is a different matter. A tool that moves money needs the same approval step it would need anywhere else. Human approval for agents shows how to tie an approval to the exact action.
MCP vs traditional API integrations
| Traditional integration | MCP | |
|---|---|---|
| Setup | Custom code for each model and tool pair | One server per tool, reused by any MCP client |
| Tool discovery | A developer reads the API docs | tools/list returns names, descriptions, and input schemas |
| Versioning | Each API versions its own way | Every request names its protocol version, and a server rejects one it doesn't support with a list of versions it does |
| Protocol errors | Each integration reports errors differently | JSON-RPC error format for protocol failures |
| Authentication | Varies per integration | Remote servers take bearer tokens, API keys, or custom headers, and the docs recommend OAuth for getting tokens |
| Reuse across models | Build for Claude, rebuild for ChatGPT | One server works with every client that speaks the protocol |
A traditional API connection runs between exactly two things. You write code for Stripe's API, more code for Slack's, more for GitHub's. MCP puts one shared layer between all those APIs and every AI app.
One thing MCP doesn't do: decide what a tool should be allowed to do. That's still the server's job. The MCP docs keep a security best practices page for people building servers and clients. Read it before you expose anything that can change data.
How to get started with MCP
If you're not a developer. If you use Claude, ChatGPT, Cursor, or VS Code and have added a connector or MCP server, you're already using MCP. Adding another is a settings step, not coding. Read what a server can do before you connect it, the same way you would for any app you give access to your accounts.
If you build tools or automations. Check the MCP Registry for a server that already exists. If you need something custom, pick an official SDK from the SDK docs and follow the course lesson on building a server and client. The steps are the same every time: decide which tools to allow, which data to expose, and any prompt templates, then start the server and test it from a client.
If you use coding agents. MCP servers for coding agents covers adding a read-only server to Claude Code and Codex and which permissions to set.
If you're setting it up for a company. Run a private MCP server in front of internal data, such as a CRM, a database, or internal APIs. Then every AI tool your team uses can reach that data the same way. Signing in to remote servers follows the transport spec, but what each person is allowed to do through each tool is still a rule your server has to write and enforce.
What's still changing
MCP isn't finished. The 2026-07-28 revision changed how connections start, deprecated sampling, and left the registry in preview, so expect more changes.
Still, with support across Claude, ChatGPT, VS Code, and Cursor, a foundation backed by the major AI labs and cloud providers, and downloads in the hundreds of millions a month, it's the default way to connect AI tools to the rest of your software. When you choose tools, favor ones that support MCP. When you need a custom connection, build an MCP server instead of one-off code. The server and client lesson is the place to start.