Model Context Protocol Architecture Overview

Model Context Protocol, or MCP, is an open standard that gives AI applications one reusable way to connect to outside tools, data, and services. Before it existed, every pairing of an AI app and a data source needed its own custom-built connection. An assistant that needed to read a calendar, query a database, and search a file system needed three separate integrations, each maintained on its own schedule, each with its own quirks. MCP replaces that pile of one-off wiring with a single shared protocol that both sides agree to speak.

The comparison people reach for is USB-C: one connector standard instead of a drawer full of proprietary cables, each built for exactly one device. That image holds up well for MCP, because the appeal is the same. Build the connector once, on each side; any compliant device then plugs into any compliant port. An AI application that speaks MCP can reach any MCP server, and a tool built as an MCP server can be reached by any MCP-compatible application, with no bespoke code required for each new pairing.

Wiz Research found MCP servers running in at least 80% of observed cloud environments in early 2026. The protocol has already become common infrastructure in the time it would normally take a new standard to earn broad trust. Adoption moved quickly. The thinking around how to secure these connections has not kept the same pace, and that gap matters before anything else about MCP makes sense.

The three-role architecture: host, client, and server

MCP's design rests on a clean division of labor across three roles: host, client, and server. Each one does a distinct job, and each one carries its own exposure to risk.

The host is the application a person actually works with. Claude Desktop, Claude Code, and Cursor IDE are all examples of hosts. The host holds the top-level context for a session and manages the connections that reach out to whatever servers that session needs.

The client lives inside the host and does the protocol work. One client gets created for every server connection the host opens, and that client maintains a dedicated link to its one server. A client does not juggle multiple servers at once. The relationship is one client per server, full stop, which keeps each connection isolated from the others by design.

The server is the external program on the other end. It exposes tools, resources, and prompts through a standardized interface that any compliant client can call. A server's trustworthiness is not guaranteed by the protocol itself. A server is only as trustworthy as the team that built and deployed it, since MCP standardizes the shape of the connection, not the judgment of whoever is running the code behind it.

Each of these three roles opens its own door to attackers, and the doors are different. A host that fails to isolate sessions properly can let context meant for one conversation bleed into another. A client that accepts tool descriptions without checking them first is open to poisoning: testing of seven major MCP clients found that five of them have no static validation mechanism for tool descriptions. A server with broad, standing authority (access it holds at all times, not just when a specific task calls for it) can be tricked into acting far outside the narrow job it was supposed to do.

How the host-client-server roles interact at runtime

The roles above describe the shape of MCP. What happens when a session actually runs is where the risk takes form, because the dangerous moments live in the handoffs between steps, not inside any single role acting alone.

A session starts when the host spins up one client for each server it plans to use. Each client then asks its server what it can do, pulling back a list of available tools. Those tool descriptions land in the model's context before the user has taken any action. That timing matters: it is the exact moment when a tool poisoning attack would take hold, since the model absorbs whatever the tool description says long before anyone has a chance to review it.

From there, the sequence plays out step by step. The model decides it needs to call a tool. The client passes that call to the server. The server runs it and sends results back. The model reads those results and, based on what it finds, may decide to call another tool, chaining one action into the next.

That chaining is what builds a multi-hop trust chain stretching across the whole session. MCP hands the model running authority that spans every hop in that chain, and no amount of perimeter security or identity checking at the edges fully accounts for what happens once that authority is in motion.

The reason this differs from how software has traditionally worked comes down to who is making decisions in the middle of the process. In a conventional application, user input passes through validation layers that were written in advance, with fixed rules about what counts as acceptable. In an MCP session, the model itself decides what to call next, based on what it has read in its context. That open-ended decision point is what prompt injection targets: feed the model a crafted instruction buried somewhere in its context, and it may act on that instruction as though a legitimate user had asked for it.

JSON-RPC 2.0 as the message format binding the layers together

Every message that moves between an MCP host, client, and server uses JSON-RPC 2.0, a lightweight remote procedure call format built to let one program ask another to run a function and get the result back. It is the shared language that makes the three-role architecture actually work in practice, not just on paper.

The format itself is simple on purpose. A message names a method to call, carries whatever parameters that method needs, and includes an ID that ties the eventual response back to the request that triggered it. Errors follow their own standard shape too, so a client always knows how to read a failure the same way it reads a success.

JSON-RPC 2.0 does not care what it travels across. The same message structure works whether it runs over STDIO or over HTTP. The choice of transport can shift without touching the message format underneath it. As of the July 28, 2026 revision, MCP itself is stateless, so anything more involved, like interactive sessions or Enterprise-Managed Authorization, lives in optional extensions sitting outside the core protocol rather than being baked into the base message format.

That minimalism means the core format carries no built-in authentication and no built-in authorization. Nothing in a JSON-RPC message says who is allowed to make this call or what they are allowed to do with the result.

The two transport mechanisms

MCP supports two transport mechanisms, STDIO and Streamable HTTP, and the choice between them is not a minor deployment detail. It sets the trust model, the authentication requirements, and how far damage can spread if something goes wrong.

STDIO runs the MCP server as a local child process of the host application. Communication happens over standard input and output streams on the same machine, so there is no network overhead and the operating system keeps the process isolated the way it isolates any other local process. STDIO only supports one client connection, and the server's lifecycle is tied directly to the host's: when the host closes, the server goes with it. The tradeoff shows up directly in security: STDIO transport runs operating system commands without sanitizing or validating them first, which opens a path to remote code execution on any host that has a vulnerability for an attacker to find.

Streamable HTTP takes the opposite shape. The server runs as an independent service reachable over a network, and multiple clients can connect to it at the same time. That independence lets it scale horizontally, and the server's lifecycle no longer depends on any single host staying open. The cost of that reach is that authentication now has to be handled properly: Streamable HTTP requires OAuth 2.1 when authorization is implemented, and every endpoint has to run over HTTPS.

Neither of these is simply the better option. Streamable HTTP opens up enterprise-scale connectivity, letting many clients share one server, but that only stays safe if OAuth is configured correctly. Get it wrong, and the attack surface widens considerably. In cloud environments, a misconfigured HTTP server can expose instance metadata endpoints that an agent should never be able to reach in the first place, and the preconditions are mundane: no egress allowlist, no validation of URL schemes before a request goes out. Those are exactly the kind of gaps that matter given how many environments already run MCP servers: Wiz Research's finding of at least 80% of observed cloud environments in early 2026 means a transport misconfiguration today lands inside infrastructure that is already widespread.

Why the specification stays silent on security

The MCP specification standardizes how a model discovers tools and calls them. It says nothing about authentication, nothing about authorization, and nothing about transport security beyond what each implementer chooses to add. That silence is how the protocol was built, and every deployment inherits the consequences of that choice.

An MCP server's security depends entirely on the judgment of the team that deployed it, because the specification requires none of these controls on its own. That single fact changes what an identity system can actually tell you. It can confirm who made a request. It cannot tell you which MCP server that request passed through, what tools that server had exposed, or whether the tool description the model read at the start of the session still matches what someone reviewed when the server was first deployed. None of that visibility comes from the protocol. It has to be built on top of it, deliberately, by whoever is running the deployment, because no future spec update is going to close this gap for them.

Two documented incidents show what happens when nobody does that work. In September 2025, a fake npm package impersonating a vendor's email server MCP got installed through normal channels, passed review because it behaved exactly as expected at install time, and then pushed a later update that silently copied every agent-sent email to a domain the attacker controlled. The malicious behavior did not exist until that update shipped, so standard review caught nothing. In April 2025, Invariant Labs disclosed a poisoned math tool whose description quietly instructed an agent to read SSH key files and pass their contents through an extra parameter disguised as part of a routine calculation. The developer using the tool saw a correct arithmetic answer and nothing else. No user interaction triggered the theft, and no persistent trace was left behind to flag it later.

Both incidents trace back to the same structural fact: a tool's underlying code and behavior can change without any notice reaching the MCP client or the person using it. The specification does not require a client to re-validate a tool's description each time it runs, so a tool can pass inspection once and change its behavior entirely afterward, as the Postmark package did. Testing across seven major MCP clients found that five had no static validation mechanism for tool descriptions whatsoever, and nothing in the specification obligates them to add one.

The risk extends past individual tools into how credentials move across the system. When an upstream OAuth token gets forwarded straight through to a downstream tool call instead of going through proper token exchange under RFC 8693, a credential issued for one specific audience ends up reaching systems it was never meant to touch. A single compromised service sitting in the middle of that chain can then reuse the token against additional targets far outside its original scope. OX Security disclosed exactly this kind of systemic architectural flaw in April 2026, and the exposure reached across a supply chain tied to more than 150 million package downloads.

None of this means MCP is broken. That is the argument for governance sitting at the foundation of an MCP deployment rather than bolted on after the fact. Platforms built specifically as MCP gateways, enforcing policy at the level of individual tool calls across the host, client, and server all at once, turn that strict division of labor from an architectural idea into an actual working security boundary. Runlayer is one platform built around that model, applying real-time policy enforcement across all three roles so the separation MCP defines on paper becomes something a security team can actually rely on in production.