What Is MCP? The Model Context Protocol Explained

Okay so MCP is everywhere these days. Model Context Protocol. Every AI tool has a banner saying “works with MCP”. But what IS it really?

So what is MCP, and how does the Model Context Protocol actually work? Let me explain without the hype. MCP is a pretty simple idea that solves a real problem.

The problem MCP solves: N times M integrations

Say you want to connect GitHub to Claude. You write some glue code. Cool, it works.

Now you want to also connect GitHub to ChatGPT. You write it AGAIN because they have different APIs and different tool formats.

Now you want it in Gemini too. Write it a third time.

Now you want to add Slack. To all three. Three more integrations.

See the problem? For N apps and M tools, you have N times M integrations. Nobody wants to build and maintain that many copies of the same thing.

Toggle the demo. Without MCP you see all the spaghetti lines. With MCP there is one protocol in the middle. Every app only needs to speak MCP once. Every tool only needs to expose MCP once.

What is MCP? (the USB of AI)

MCP, short for Model Context Protocol, is a standard way for AI apps to talk to tools.

Analogy: MCP is basically USB for AI. Before USB, every device had its own plug shape. Printer plug. Mouse plug. Keyboard plug. A serial port, a parallel port, PS/2. What a mess. Then USB came along and said “here is one shape everyone uses”. Now every device has a USB plug and it just works.

MCP does the same thing for AI. One protocol. Any AI app can talk to any tool that speaks MCP.

Under the hood it is just JSON-RPC. Which is a super simple format. You send a message saying “call this method with these arguments” and you get back a response. That’s it.

The full spec lives at modelcontextprotocol.io/specification if you want the nitty-gritty.

The three parts of MCP: host, client, and server

MCP has three main roles.

Host: the app the user is actually using. Claude Desktop, Cursor, Zed, whatever. The host is what runs the AI model.

Client: a thin layer inside the host that speaks the MCP protocol. The host usually has one client per server it connects to.

Server: the thing that provides the actual tools. Like a GitHub MCP server or a filesystem MCP server. Someone wrote that server and it speaks MCP on behalf of GitHub or the filesystem.

In practice as a developer, you mostly write servers. Or you use ones that someone else already wrote.

What an MCP server exposes: tools, resources, and prompts

An MCP server can expose three kinds of things.

Tools: actions the model can take. Like “create an issue” or “read a file” or “send a slack message”. The model decides when to call these based on what the user asks.

Resources: read-only data the model can look at. Like the contents of a file, or a row from a database, or a web page. The model does not “call” these, it just reads them as context.

Prompts: pre-made prompt templates that the user can pick. Like a “summarize this” shortcut or a “write a PR description” shortcut.

Most MCP servers are mostly about tools. Tools are where the interesting stuff happens.

How MCP messages flow (the protocol in action)

Let’s say you open Claude Desktop. It has a GitHub MCP server configured. You type “show me open issues in my repo”. What happens?

{
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "clientInfo": { "name": "Claude Desktop" }
  }
}

Step through the demo. The important beats:

1. Initialize. Client and server shake hands. They agree on the protocol version and what each side supports.

2. tools/list. Client asks the server what tools it has. Server sends back a list. Each tool has a name, description, and a JSON schema for its arguments so the model knows what to put in.

3. User sends a message. Claude sees the user message plus the list of available tools. It decides to call one.

4. tools/call. Client sends “call github.list_issues with repo=my-repo”. Server runs the actual function (it calls the real GitHub API behind the scenes) and returns the result.

5. Result flows back. Claude gets the result and writes a natural language response to the user.

All of this happens in a second or two. The user just sees their answer.

MCP transports: stdio, HTTP, and SSE

MCP supports a few ways to actually send the messages.

stdio: simplest option. Server runs as a subprocess of the host, and messages go through stdin and stdout. Good for local tools like a filesystem server or a local database.

HTTP: for remote servers. Messages go over regular HTTP requests.

SSE (Server-Sent Events): for streaming responses. Useful when a tool call takes a while and the server wants to send updates back as it runs.

Most local MCP servers use stdio because it is dead simple. Remote ones use HTTP. Both are equally valid MCP.

Why MCP is a big deal

Before MCP, if you built a cool tool and wanted AI apps to use it, you had to wait for each app to add your tool. Or you had to go to each app and convince them to do a custom integration. Both are painful.

Now you write an MCP server once. Every AI app that speaks MCP can use it immediately. Claude Desktop, Cursor, Zed, Cline, whatever comes along next year. All of them.

And the other direction too. If you are building an AI app, you don’t have to write a hundred different tool integrations. Point your app at any MCP server and it just works.

Wrap up

MCP is not magic. It is basically JSON-RPC with a specific shape that says how AI apps and tools should talk to each other.

The value is standardization. Before MCP, everyone was writing the same integrations over and over. Now you write one MCP server and every app can use it. That is a huge unlock for the ecosystem.

Next time you see a tool saying “works with MCP”, you can just nod, because now you know what is going on underneath.

Frequently asked questions

What is MCP (Model Context Protocol)?

MCP is an open standard that lets AI apps talk to external tools and data in one consistent way. Instead of every app building custom integrations for every tool, both sides speak MCP. People call it the USB of AI because it is one plug shape that works everywhere.

How does MCP work?

Under the hood MCP is just JSON-RPC. An MCP client inside the host app connects to an MCP server, they agree on a protocol version, the client asks the server what tools it has, and then the model can ask the client to call those tools. The server runs the real work and sends the result back.

What is an MCP server?

An MCP server is a program that exposes tools, resources, or prompts to any AI app that speaks MCP. A GitHub MCP server, for example, wraps the GitHub API so a model can create issues or read files. You either write your own server or use one someone else already published.

What are the three parts of MCP?

The host is the app the user is in, like Claude Desktop or Cursor, and it runs the model. The client is a thin layer inside the host that speaks MCP, usually one per server. The server provides the actual tools.

What can an MCP server expose?

Three things. Tools are actions the model can take, like creating an issue. Resources are read-only data the model can look at, like a file or a database row. Prompts are pre-made templates the user can pick. Most servers are mostly about tools.

Why does MCP matter?

Because it removes the N times M integration problem. Before MCP, connecting every app to every tool meant rewriting the same glue code over and over. Now you write one MCP server and every app that speaks MCP can use it right away.

Sources

• modelcontextprotocol.io. The official MCP home, with intro docs and SDKs.
• MCP specification. The full protocol spec, including message shapes for tools, resources, and prompts.
• modelcontextprotocol on GitHub. Reference servers, SDKs for Python/TypeScript/Rust, and example integrations.