What Is MCP? The Model Context Protocol, Without the Hype
The problem MCP solves is easier to state than the protocol itself.
You have some number of AI applications — a chat client, a coding assistant, an agent. You have some number of tools you want them to reach — your database, your calendar, a ticketing system, a filesystem. Without a standard, connecting them is N × M integrations: every application needs bespoke code for every tool.
MCP makes it N + M. Each application implements the protocol once. Each tool exposes itself as an MCP server once. Anything that speaks MCP can then use anything that speaks MCP, without either side having been written with the other in mind.
That’s the whole value proposition. Everything below is how it works.
What MCP actually is
Stripped of marketing: MCP is a JSON-RPC protocol — messages must be UTF-8 encoded — with a defined lifecycle, running over one of two transports.
An MCP server is a program that exposes capabilities. A client is the AI application that connects to it. The model discovers what a server offers at runtime by asking, rather than by having been programmed with that knowledge in advance.
That runtime discovery is the part that distinguishes a tool from an API endpoint, and it’s worth being precise about, because “MCP is just an API wrapper” is a common dismissal that misses it:
- A REST endpoint is documented for humans. A developer reads the docs and writes code that calls it correctly.
- An MCP tool describes itself to the model — its name, what it does, what arguments it takes, in a form the model consumes directly. Nobody writes integration code per tool per application.
- MCP sessions are stateful. A session begins with an initialisation handshake and can persist across many messages, which a stateless REST call doesn’t.
So MCP isn’t a replacement for APIs. It’s a standard way to present capabilities — often APIs you already have — to a model at runtime.
The two transports
Here’s where most explanations are out of date, because this part changed.
The specification currently defines two standard transports:
1. stdio. The client launches the MCP server as a subprocess and talks to it over standard input and output, one JSON-RPC message per line. The spec is emphatic about the discipline this requires: the server “MUST NOT write anything to its stdout that is not a valid MCP message” — logging goes to stderr instead. This is the local case, and the spec says clients “SHOULD support stdio whenever possible.”
2. Streamable HTTP. The server runs as an independent process handling multiple clients, exposing a single HTTP endpoint that supports both POST and GET — something like https://example.com/mcp. This is the remote case.
What about SSE? This is the confusion worth clearing up. There was a separate HTTP+SSE transport in protocol version 2024-11-05. It is deprecated, and Streamable HTTP replaces it.
Confusingly, Streamable HTTP can still use Server-Sent Events — a server may answer a POST with text/event-stream to stream several messages back. So SSE still appears, but as a mechanism inside the current transport rather than as a transport of its own. If a guide tells you to choose between “SSE” and “Streamable HTTP,” it’s describing the 2024 spec.
Two headers matter if you’re implementing against it: clients must send MCP-Protocol-Version on HTTP requests, and servers may issue an Mcp-Session-Id at initialisation that clients must then echo on every subsequent request.
Before you expose one, read the spec’s own warning
The specification includes a security section for Streamable HTTP, and it’s unusually direct. Three requirements:
- “Servers MUST validate the
Originheader on all incoming connections to prevent DNS rebinding attacks” - “When running locally, servers SHOULD bind only to localhost (127.0.0.1) rather than all network interfaces (0.0.0.0)”
- “Servers SHOULD implement proper authentication for all connections”
And the consequence, stated plainly: “Without these protections, attackers could use DNS rebinding to interact with local MCP servers from remote websites.”
Read that third time. A local MCP server bound to 0.0.0.0 with no authentication can be reached by a website you visit, via DNS rebinding — and an MCP server exists precisely to expose capabilities: your files, your database, your internal APIs.
This isn’t hypothetical at scale. Scanning reported in early 2026 identified thousands of MCP servers reachable on the public internet, with security researchers at Trend Micro finding several hundred that had no client authentication and no traffic encryption at all. That matches the broader pattern we’ve written about — 31% of scanned Ollama servers answered a stranger’s prompt — and the cause is the same: software that defaults to safe, deployed by a tutorial that says to change the bind address.
What running a remote MCP server actually involves
This is where MCP stops being a protocol question and becomes an infrastructure one.
A stdio server needs nothing — it’s a subprocess on the machine already running the client.
A remote MCP server over Streamable HTTP is a long-running HTTP service. That means:
- A host that stays up. It’s a persistent process, not a function you invoke.
- TLS. You’re carrying tool calls and their results, which will include whatever your tools touch.
- Authentication, per the spec’s own SHOULD — and given what an MCP server exposes, treat that as a MUST in practice.
- Origin validation, per the spec’s MUST.
The resource requirements are modest — an MCP server is usually a thin adapter over something else, so it’s ordinary application load rather than anything heavy. A small VPS handles it comfortably. What a VPS is covers the basics, and if you’re deploying with Docker, remember that ufw doesn’t filter published container ports — which is exactly how a server intended for localhost ends up public.
For anything genuinely personal, the cleanest answer is not to expose it at all: keep it on stdio, or reach it over a private network where nothing is published.
Where MCP fits
MCP is plumbing between an AI application and the tools it uses. It doesn’t make a model smarter, it doesn’t do orchestration, and it isn’t an agent.
An agent decides its own next step in a loop. MCP is one of the ways that agent’s tools get connected to it — a good one, because it means the tools don’t have to be written for that specific agent. The two are complementary rather than alternatives, and conflating them is the most common confusion in this area after the SSE question.
How we checked this
Everything technical here is from the Model Context Protocol specification (version 2025-06-18), read in August 2026: that MCP uses JSON-RPC with UTF-8 encoding, that it currently defines two standard transports, the stdio rules including the stdout prohibition, the single-endpoint POST-and-GET requirement for Streamable HTTP, the MCP-Protocol-Version and Mcp-Session-Id headers, and the three security requirements with the DNS rebinding warning quoted verbatim.
One correction to a widely-repeated claim. The brief for this article described three transports — stdio, SSE and Streamable HTTP. The specification defines two. HTTP+SSE was a transport in protocol version 2024-11-05 and is deprecated; Streamable HTTP replaces it, while still using Server-Sent Events internally as one way of returning messages. Treating SSE as a current third transport is a 2024-era description, and it’s the single most common out-of-date detail in MCP explainers.
The exposed-server figures are from published security research rather than our own scanning, and we’ve described them in round terms because the reported counts vary between sources and scanning dates.
What we did not do: we did not build or deploy an MCP server for this article. The infrastructure requirements above follow from the transport definition — a long-running HTTP service needs a host, TLS and auth — rather than from a deployment we ran.
This article has no affiliate links.
FAQ
What is MCP in simple terms?
A standard way for AI applications to connect to tools. Without it, linking N applications to M tools needs N×M integrations; with it, each side implements the protocol once and anything can talk to anything.
What is an MCP server?
A program that exposes capabilities — a database, a filesystem, an API — over the Model Context Protocol, so that any MCP-speaking AI application can discover and use them at runtime without bespoke integration code.
How is MCP different from an API?
An API is documented for developers who then write integration code. An MCP tool describes itself to the model directly, is discoverable at runtime, and operates within a stateful session. MCP typically wraps APIs rather than replacing them.
What transports does MCP support?
Two: stdio, where the client runs the server as a subprocess, and Streamable HTTP for remote servers. The older HTTP+SSE transport is deprecated — though Streamable HTTP still uses Server-Sent Events internally for streaming responses.
Do I need a server to run MCP?
Only for remote access. A stdio MCP server runs as a subprocess on the machine you’re already using. Streamable HTTP servers are long-running HTTP services and need hosting, TLS and authentication.
Is it safe to expose an MCP server?
Only with care. The spec requires Origin header validation to prevent DNS rebinding, recommends binding to localhost when running locally, and recommends authentication on all connections — because without them, a website you visit could reach a local MCP server.
Is MCP the same as an AI agent?
No. An agent decides its own next steps toward a goal; MCP is how that agent’s tools get connected. They work together, and MCP is plumbing rather than intelligence.
