The Model Context Protocol (MCP) is the thing everyone is suddenly building servers for, and the thing almost no one explains clearly. If you have searched it and come away more confused, that is not you. The single most-clicked result for "claude code mcp" is a Reddit thread literally asking what the difference is. So here is the plain-English version, with the three words that get tangled together pulled apart first.
Client, server, protocol: the three words people mix up
Almost all the confusion comes from using one word for three different things. Keep these separate and the rest is easy:
- The protocol is MCP itself: a written standard for how an AI app and a tool provider talk to each other. It is a spec, not a program.
- A server is a small program that follows that standard to expose some capability, like reading files, querying a database, or searching the web. You can write one, or use one someone else published.
- A client is the AI app that connects to servers and uses their capabilities. Claude Desktop, Claude Code, Cursor, and various agents are all MCP clients.
So "MCP server" means a program exposing tools over the MCP standard, and the client is whatever AI app calls it. You almost always use servers and write servers; the client is usually an app you did not build.
A useful analogy: USB-C for AI tools
The official framing is that MCP is like a USB-C port for AI applications. Before USB-C, every device had its own connector. MCP is the standard plug: write a tool once as an MCP server, and any MCP-compatible client can use it without custom glue. The same filesystem server works in Claude Desktop, Cursor, or your own agent, unchanged.
What a server actually exposes: three primitives
An MCP server can offer three kinds of things, and a given server declares which it supports:
- Tools are actions the AI can take:
read_text_file,run_query,send_message. Each comes with a schema describing its arguments, so the model knows how to call it. - Resources are read-only data the AI can pull in for context: a file's contents, a database row, an API response. Think "here is information," not "do something."
- Prompts are reusable, parameterized templates: a saved instruction like "review this code for security issues" that takes a file path and assembles the full prompt.
Tools are by far the most common, which is why most people think of MCP as "giving the AI tools." Resources and prompts are the quieter two-thirds of the spec.
What a session looks like
Under the hood it is just structured messages in a format called JSON-RPC 2.0, the same wire format the Language Server Protocol uses. Every session follows the same shape, which I walked through hands-on in a separate post where I drove a real server by hand. The short version:
- The client launches the server and sends an
initializemessage. The server replies with its name and what it supports. - The client asks
tools/list. The server returns its menu of tools, each with an input schema. - When the model decides to use one, the client sends
tools/callwith the arguments, and the server returns the result.
That is the entire loop: introduce, list, call. Everything fancier is built on those three steps. If you want to see the raw messages, the companion tutorial runs the official filesystem server and shows each one.
How the client and server connect: transports
MCP defines two main ways for the client and server to actually exchange those messages:
- stdio is for local servers. The client launches the server as a child process and they talk over standard input and output pipes. It is fast, needs zero networking, and is what most desktop setups use.
- Streamable HTTP is for remote servers. Messages go over HTTP, with Server-Sent Events for streaming responses back. This is what you use when the server runs somewhere else and may serve many clients, and it is where authentication enters the picture.
For a first server on your own machine, stdio is the default and the simplest. You graduate to Streamable HTTP when you want to host a server other people or apps connect to.
Why this exists at all
You might ask why we need a protocol when models already have "function calling" or "tool use" built in. The difference is reuse and portability. With plain function calling, you describe each tool inside your own app, coupled to one model's API. With MCP, the tool lives in a standalone server that any client can discover and call, and switching from one AI provider to another does not mean rewriting your integrations. Build the tool once, run one server, connect many clients. (I dig into exactly when each approach wins in a separate comparison post.)
So, do I write a client or a server?
Almost certainly a server, if you write anything. Writing a client means building the AI application itself, which is a big job most people do not need to do. Writing a server means wrapping something you care about - your notes, your database, your homelab - so an existing AI app can use it. That is the common, approachable starting point, and it is one short Python or Node file to get going.
Takeaways
- MCP is a protocol. A server is a program that follows it to expose tools. A client is the AI app that calls servers. Keep those three separate and the topic stops being confusing.
- Servers expose three primitives: tools (actions), resources (read-only data), and prompts (templates). Tools are the common one.
- Every session is the same three steps over JSON-RPC: initialize, list, call.
- Local servers use stdio; remote servers use Streamable HTTP, which is also where auth shows up.
- If you build anything, you will most likely build a server, and it can be a single small file.