Hi, I'm Lena. Something felt slightly off the first time I tried to explain MCP to someone.
I kept saying "it connects your AI to tools" — and that's technically true, but it didn't capture what was actually happening underneath. The person I was talking to nodded, then asked: "so it's like a plugin?" And I paused. Because it's not quite that either.
That gap — between "I know it works" and "I understand how it works" — is what I want to sit with here. Not as a formal technical breakdown, but as a slow walk through what I've observed about how MCP servers actually behave.
The Problem MCP Was Built to Solve
Why every model-tool integration used to be custom
Before MCP existed, connecting a language model to an external tool meant writing a custom integration every time. GitHub had its own format. Databases had theirs. Every API was a separate project.
It wasn't that any single integration was hard. It was the accumulation — the fact that none of them could talk to each other, and the model had no standard way to ask "what can I do here?" Each connection was hand-stitched.
Model Context Protocol is Anthropic's answer to that. Open-sourced in November 2024, it introduced a shared language — a standardized client-server protocol so that any AI application could connect to any tool provider without custom wiring. By mid-2025, OpenAI and Google DeepMind had adopted it. It has since moved under the Agentic AI Foundation, a Linux Foundation project.
That move matters a little. It stopped being one company's standard and started becoming something more shared. I'm not fully sure yet what that changes in practice, but I keep noticing it.
MCP Architecture: The Three Moving Parts
When people ask how do MCP servers work, I think the clearest starting point is the three-part structure. Each piece has a distinct job, and the confusion usually comes from collapsing them together.
MCP Host (the AI app)
The host is the application you're actually using — Cursor, Claude Desktop, VS Code with an AI extension. It's what the user sees and interacts with.
The host is a security broker. It manages the model's context window, decides which tools are available, and controls what gets passed back to the LLM. It doesn't execute tool calls itself — it just governs access. Most developers never write host logic unless they're building a custom agent platform, but understanding it matters because the host is what decides what the model can and can't reach.
MCP Client (built into the host)
The client is created by the host. It sits between the host and each MCP server, managing the connection. There's typically one MCP client per MCP server — each maintains its own dedicated session.
The client handles capability negotiation, routes messages back and forth, and abstracts the transport details. The host doesn't need to know whether a server runs over stdio or HTTP. That's the client's job.
MCP Server (the tool provider)
The server is where the actual capabilities live. It exposes tools, resources, and prompts — whatever it's been built to provide. A GitHub MCP server exposes repository operations. A Postgres server exposes query functions. Each server typically focuses on one integration domain.
What surprised me when I looked at this more closely: a server is just a program. It can run locally on the same machine as the host, or remotely somewhere on the internet. The protocol doesn't change — only the transport does.
How a Tool Call Actually Happens
This is the part I kept getting slightly wrong in my head until I mapped it out step by step.
Step 1: Server advertises available tools
When the client first connects to a server, there's a handshake. The client sends an initialize request. The server responds with its protocol version and a list of its capabilities — which tools it offers, their names, input schemas, and descriptions. This is called capability negotiation.
The client then embeds those tool definitions into the model's system prompt. This is how the LLM knows what's available. It's not magic — it's just structured context.
Step 2: Model decides to use a tool
When the model is processing a request and determines a tool call is appropriate, it emits a structured call: the tool name and the arguments it wants to pass. The model doesn't call the tool directly. It outputs a structured instruction, and the host interprets it.
Step 3: Client sends the call to the server
The client takes that structured call and forwards it to the correct server as a tools/call request over JSON-RPC 2.0. This is the wire format — a dictionary with a method name, parameters, and a unique ID for correlation.
Step 4: Server executes and returns the result
The server runs the actual function — a database query, an API call, a file read, whatever it's been built for. It returns a structured response. If something goes wrong, it returns a typed error, not a raw exception. Well-built servers return error messages that actually help the model understand what failed and why — which matters for recovery.
Step 5: Model incorporates the result
The result flows back through the client and host into the model's context. The model reads it as part of the conversation and continues from there.
…okay, I think I see what it's doing. Each step is deliberately separated. The model never touches the tool directly. There's always a layer in between.
Transport Layer: How Servers and Clients Talk
stdio (local) vs. HTTP/SSE (remote)
Stdio transport uses standard input and output streams. When the host launches a local MCP server as a subprocess — like running npx my-mcp-server — the client and server communicate by writing to and reading from those streams. No network is involved. No latency overhead. It's fast because it's just process-to-process communication on the same machine.
Streamable HTTP transport (the current standard for remote servers, specified in the March 2025 protocol update) uses HTTP POST for client-to-server messages, with optional Server-Sent Events for streaming responses. This is what remote servers use — hosted on a platform like Cloudflare or Vercel, serving many clients simultaneously.
There's an older HTTP+SSE format (from the November 2024 spec) that required two separate endpoints. The newer Streamable HTTP spec consolidated that to a single endpoint. Worth knowing if you're reading older documentation — the patterns changed.
What this means for latency and security
Local stdio servers are faster and have a smaller attack surface. The only process that can communicate with them is the host. Remote servers introduce network latency and require authentication. Research in July 2025 found that nearly 2,000 MCP servers exposed to the internet had no authentication at all — anyone could access their tool listings. The June 2025 spec update addressed some of this by classifying MCP servers as OAuth Resource Servers, but implementation remains inconsistent.
That detail stayed with me. The protocol can define security patterns, but it can't enforce them. The official MCP security documentation covers the recommended practices — worth reading before deploying anything that handles sensitive data.
The Layer Most Developers Miss
What happens to a successful tool call
Here's the part that confused me for a while: a successful tool call doesn't persist anything by itself.
The result comes back into the model's context for that session. The model uses it, generates a response, moves on. But the fact that the tool was called — the specific path the model took, the inputs it chose, the result it got — that lives only in the conversation window. When the session ends, it's gone.
The MCP server doesn't accumulate knowledge. It doesn't get better at responding based on past sessions. Each new connection starts from the same initial state — the handshake, the capability list, clean slate.
Why connection ≠ capability persistence
This is what I mean when I say "connection is not capability persistence."
Connecting an MCP server gives the model access to a tool. It does not give the model a memory of how it used that tool before, or what worked, or what failed. The server exposes the same capabilities in every session, regardless of what happened in previous ones.
I keep thinking about this. It's not a flaw exactly — it's just a design boundary. The protocol handles communication and execution. What happens to the output of that execution — whether it's stored, learned from, carried forward — is a different layer entirely.
…there might be more here. I'll keep thinking about this one.
FAQ
- What is an MCP server exactly?
An MCP server is a lightweight program that exposes tools, resources, and prompts to AI agents through the Model Context Protocol. It translates structured requests from language models into actual operations — database queries, API calls, file reads — and returns the results in a standardized format. It can run locally on the same machine as the AI app, or remotely over HTTP.
- What transport protocols does MCP use?
MCP supports two transport mechanisms. Stdio uses standard input/output streams for local, same-machine communication — fast, no network overhead. Streamable HTTP (the current standard for remote servers) uses HTTP POST with optional Server-Sent Events for streaming. All messages use JSON-RPC 2.0 as the underlying format regardless of which transport is in use.
- Can an MCP server call another MCP server?
The protocol allows for it. An MCP client can maintain concurrent connections to multiple servers simultaneously — one for a database, another for file access, a third for an external API, all in the same session. What's less common, and less clearly defined in current implementations, is a server acting as a client to another server. That pattern exists, but it adds complexity and the security boundaries get harder to reason about.
The protocol is still forming. The spec has already changed meaningfully between the November 2024 release, the March 2025 update, and what's in active use now. What the architecture looks like in another version or two — I'm genuinely not sure. But I will learn more about it.
