How Model Context Protocol (MCP) actually works

Every integration between a model and one of your systems is custom code. Bespoke auth, bespoke schemas, bespoke error handling. Change the model and the glue breaks. Add a tool and you write the glue again. Anyone who has wired an assistant into a real product has felt this: nothing is hard, everything is fiddly, and none of it is reusable.

The Model Context Protocol exists to make that work once instead of every time. It is worth understanding properly, because most of the explainers now circulating describe a version of the protocol that no longer exists. Here is how MCP actually works today.

Why APIs were never built for models

Start with the mismatch, because it explains every design decision that follows.

APIs were designed for programs that already know exactly what they want. A caller forms a precise, deterministic request: this endpoint, these parameters, this shape of response. The contract is fixed at the time you write the code, and the program’s job is to satisfy it exactly.

A language model does not work that way. It reasons over uncertain inputs. It often needs to look at what is available before it knows what to ask for, and sometimes it needs to ask a clarifying question before it can act at all. Handing that kind of caller a fixed API means you have to describe every endpoint in the prompt, keep those descriptions in sync with the real API, and hope the model composes them correctly. That is the fragile system prompt that every team ends up maintaining and nobody enjoys.

MCP closes the gap by making the tools describe themselves. Instead of hard coding each integration, a model can ask what exists, read structured metadata about what each thing does and what input it expects, and then use it. The useful way to hold this: MCP is an abstraction above your APIs, not a replacement for them. Your server can still call the same REST or GraphQL endpoints underneath, and the model never has to learn their shape. It works against one consistent schema, whether it is talking to a GitHub server, a CRM server, or your internal search. Be precise about what that hides, though: the plumbing, not the data. Whatever your server returns lands in the model’s context, and a tool named after the endpoint it wraps announces the backend just as loudly.

Diagram showing a host containing three MCP clients, each connected to its own server, with the servers sitting in front of existing REST and GraphQL APIs

The three parties, not two

Most walkthroughs describe MCP as having two sides, clients and servers. The specification defines three, and the missing one is the one that matters for security.

Hosts are the LLM applications that initiate connections, the thing a person actually uses. Clients are connectors that live inside the host, one per server it talks to. Servers are the services exposing context and capabilities: a database, a file system, your internal tools, a document index.

Collapsing hosts and clients into “the model” is where teams lose the trust boundary. The host owns the relationship with the user, and it is the host that decides what gets consented to and what gets sent where. Your server talks to a client. It does not get to assume anything about the human on the other end, and it should not be written as though it does.

The whole thing runs on JSON-RPC 2.0 messages. The specification draws an explicit comparison to the Language Server Protocol, which standardized how editors talk to language tooling, and that is exactly the right frame. MCP is plumbing. It does not make your model smarter. It makes your integrations stop being one-off.

What a server exposes, and what a client offers back

A common explanation lists four resource types: tools, prompts, resources, and context. The spec defines three, and the fourth causes real design damage.

Resources are context and data for the user or the model to use. Prompts are templated messages and workflows for users. Tools are functions for the model to execute. Each one carries metadata describing what it does, what input it expects, and what it returns, which is what lets a model pick correctly without being pre-programmed.

“Context” is not a primitive. It is the outcome: what the host assembles out of resources, prompts, and tool results before it calls the model. Teams who treat it as a fourth thing to expose end up building a vague get_context tool that returns an unbounded blob, and that single design choice is what makes token costs unpredictable and retrieval quality impossible to debug.

The direction almost everyone misses runs the other way. Clients offer features to servers: sampling, for server-initiated recursive model calls, roots, for asking about filesystem or URI boundaries, and elicitation, for requesting more information from the user mid-task. If you have only ever thought of MCP as “the model calls my functions”, you have been using half of it. A server that can ask a clarifying question is a different and much better design than one that has to guess or fail.

A worked example

Say you are building an assistant that checks a calendar, pulls meeting notes, and drafts follow-up emails.

The old way: integrate Google Calendar, your notes tool, and Gmail separately. Three auth flows, three sets of rate limits, three sets of edge cases, then a long system prompt teaching the model to use them that breaks quietly whenever any of the three changes.

With MCP: you run or install a server for each system. Each advertises what it can do. The model sees list_events, get_meeting_summary, send_email with real schemas attached, and reasons about which to call, in what order, and what to pass between them. When it needs something only the user can supply, it can elicit that instead of guessing.

The difference is not that the model got better. It is that you stopped writing glue for every new tool, and the glue you did write is now reusable by any compliant client.

What changed in 2026

This is where most existing material is now wrong, including the popular video explainers.

They describe a stateful protocol: the client connects, the server advertises its capabilities, and the session persists. The 2026-07-28 specification, described by its maintainers as the largest revision since launch, converts MCP “from a bidirectional stateful protocol into a request/response stateless protocol”.

Concretely: the initialize and initialized handshake is gone, and so is the Mcp-Session-Id header. Each request now carries its own protocol version, client identity, and capabilities in _meta. Requests must include Mcp-Method and Mcp-Name headers so gateways can “route and meter on those headers instead of parsing JSON bodies”. Server-initiated requests that needed an open stream are replaced by Multi Round-Trip Requests, where a server returns resultType: "input_required" and the client retries with answers in inputResponses. List results are now cacheable via ttlMs and cacheScope.

A single tool call on the wire now looks like this. Note that the routing information a gateway needs is all in the headers, and nothing in the request depends on a prior handshake:

POST /mcp HTTP/1.1
Host: mcp.example.com
Content-Type: application/json
Authorization: Bearer <redacted_bearer_token>
Mcp-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: find_database_record
User-Agent: example-mcp-client/1.0.0
Accept: application/json

{
  "jsonrpc": "2.0",
  "id": 12345,
  "method": "tools/call",
  "params": {
    "name": "find_database_record",
    "arguments": {
      "collection": "customers",
      "query": {
        "status": "active"
      }
    }
  }
}

The motivation is operational, and it will be familiar to anyone who has put a websocket behind a load balancer. The project’s 2026 roadmap states it plainly: “stateful sessions fight with load balancers, horizontal scaling requires workarounds”. The legacy HTTP+SSE transport “is also considered to be officially deprecated, with a year-long offramp”, and Dynamic Client Registration is deprecated in favor of CIMD with twelve months of backward compatibility.

If you built against the stateful model, nothing breaks today. You are on a clock.

Diagram comparing the older stateful MCP session, where one persistent connection carries a session id, against the newer stateless model where independent self-describing requests are spread across two servers behind a load balancer

What MCP does not do for you

The specification is unusually direct here, and this is the section worth reading in full before you install anything. MCP “enables powerful capabilities through arbitrary data access and code execution paths”.

Two points deserve real attention. Tools are arbitrary code execution, and the spec states that “descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server”. A tool description is input your model reads and acts on, so installing third-party servers means letting strangers write instructions into your model’s context. And the part teams skip entirely: “MCP itself cannot enforce these security principles at the protocol level”. Consent, authorization, access control, and audit are your job. The protocol hands you a schema, not a permission model.

There is also an honest threshold for adoption. If you have one model calling three internal services you already own, MCP will cost more than it returns: a protocol layer, a server process, a transport, and a spec version to track, in exchange for standardizing integrations that were never going to change. Write the three function calls and ship. MCP earns its keep when more than one consumer needs the same tools, when those consumers are not all yours, or when third-party tools need to work inside your product without bespoke work each time.

Factor in the governance too. Anthropic introduced MCP in November 2024, then donated it in December 2025 to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI. It is no longer one vendor’s protocol, and the spec will keep moving, so budget for version churn as recurring maintenance rather than a one-time integration. That is the part we spend most of our time on at NukyLabs: taking an agent integration that demos beautifully and making it survive a spec revision and a real user.

Facing this in your own build?

NukyLabs helps founders take AI-generated apps, agents, and automations from a working demo to something that survives real users. If any of the above hit close to home, we can scope it with you.

Get a free consultation →or message us to talk through your project.