How MCP Actually Works (the USB of AI)

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?

Let me explain without the hype. MCP is a pretty simple idea that solves a real problem.

1. The mess before MCP

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.

2. What MCP actually is

MCP 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.

3. The three parts

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.

4. What a server can actually expose

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.

5. How the messages actually flow

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.

6. Transports (how messages travel)

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.

7. Why this is actually 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.

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.