Model Context Protocol Architecture Overview

What MCP Is, Precisely: A JSON-RPC Session Protocol, Not a Plugin System

MCP is a JSON-RPC 2.0-based, stateful session protocol built for context exchange and structured tool invocation between AI applications and external systems. Model-agnostic by design; it does not care whether Claude, GPT, or Gemini sits on one end, or which external system sits on the other. Any conformant implementation participates.

Most teams, when they first encounter it, misread what it actually is. That misread is where things start to go sideways.

MCP is not a REST API convention. Sessions are stateful, and that statefulness is load-bearing. It is what allows the protocol to carry context across multiple interactions rather than rebuilding from scratch on every call. It is also not a plugin system in the browser-extension sense; servers expose structured primitives defining what the host is permitted to do, and the host interacts only through declared interfaces, never executing arbitrary code. And it is not proprietary to any single model provider, which is precisely what makes it interesting as infrastructure rather than just another vendor integration layer.

Before November 2024, every AI frontend connecting to an external tool needed its own custom integration. Claude connecting to Slack, GitHub, and a database required three bespoke connectors. Then ChatGPT needed its own three connectors to those same systems. Then Gemini. Each integration carried its own authentication scheme, its own data shape, its own failure mode. The math was punishing: N frontends multiplied by M tools produced N×M integrations to build, maintain, and secure. Anthropic introduced MCP explicitly to collapse that multiplication into addition. Each tool implements MCP once. Each frontend implements MCP once. They interoperate.

Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation in December 2025, co-founding it alongside Block and OpenAI. OpenAI formally adopted MCP in March 2025 and announced deprecation of the Assistants API for mid-2026. That deprecation is a signal worth taking seriously: this is ecosystem-wide convergence on neutral infrastructure, not one vendor's preference. By late 2025, the ecosystem had produced roughly 97 million monthly SDK downloads and over 9,400 public servers indexed across major registries, with private and enterprise deployments estimated at three to four times that count.

The Three-Layer Architecture: Hosts, Clients, and Servers

MCP separates responsibilities into three distinct roles, and that separation is not organizational tidiness. It is where the actual governance properties come from.

The host is what the user touches directly: Cursor, Claude CLI, a custom enterprise chat interface. One host can run multiple client instances simultaneously. It owns the user-facing context and decides which servers to connect to.

The client is the isolated executor of a specific session. Each client maintains a dedicated, point-to-point connection with exactly one MCP server. Clients do not share sessions or state with other clients running in the same host. That isolation is architectural, not advisory, baked into the spec rather than appended as a best practice.

The server is the external system exposing capabilities. It can represent a file system, a SaaS API, a database, a workflow, almost any external resource. Per the spec, servers expose capabilities through three defined primitives: tools, resources, and prompts. Tools are callable functions the AI can ask the server to perform. Resources are data the server makes available for the model to read. Prompts are reusable templates the server provides to shape model behavior. A server cannot do something it has not exposed as one of these primitives, and that constraint is what makes policy enforcement tractable in the first place.

Security boundaries exist between host and client, and between client and server. A compromised server cannot reach the host's broader context directly; it can only interact through the client's defined session. The architecture enforces separation structurally. That is the only kind of enforcement worth trusting, because it does not depend on anyone remembering to follow a guideline.

How the Two Transport Layers Work and What Each One Implies for Security

MCP supports two transport mechanisms, and choosing between them is not primarily a latency decision. It shapes the attack surface.

Streamable HTTP with Server-Sent Events handles the case where client and server run on different machines, which is the common enterprise scenario. It is designed for remote, asynchronous, event-driven communication. Under the spec's June and November 2025 revisions, authentication is required under this transport. More network surface, but also more places to enforce policy: an OAuth flow, observable traffic, network endpoints you can inspect.

STDIO-based JSON-RPC 2.0 handles lightweight, synchronous local messaging, typically when server and client run on the same machine. The spec states explicitly that STDIO transport implementations should not follow the HTTP auth specification, and should instead retrieve credentials from the environment. That design decision pushes credential responsibility entirely onto environment configuration; it makes hardcoded or poorly rotated secrets in config files the primary risk vector, not a secondary one. GitGuardian's 2026 State of Secrets Sprawl report found approximately 24,000 secrets in MCP configuration files on public GitHub. That number follows directly from the STDIO credential model.

One thing that surprises people when they first read the spec carefully: MCP does not mandate authentication as a baseline requirement. Unauthenticated MCP servers are spec-compliant, not misconfigured. CVE-2025-49596, carrying a CVSS score of 9.4, illustrates what exposed unauthenticated servers produce in practice. The spec permitted the condition that the CVE exploited.

How Capability Discovery Works and Why Tool Descriptions Are a Trust Boundary

When a host connects to a server, the first thing it does is ask what the server can do. The server responds with a list of its tools, their names, their descriptions, and their input schemas. The model uses those descriptions to decide when to invoke a tool and what arguments to pass. The host typically treats them as authoritative. Nothing in the base MCP spec requires that trust to be cryptographically grounded.

This makes the tool description field an input to the model, which makes it an injection surface.

Tool poisoning, named and demonstrated by Invariant Labs in April 2025, exploits exactly this. A server's description is authored maliciously to manipulate what the model does when it invokes the tool. The distinction from prompt injection is worth being precise about: prompt injection originates in user input; tool poisoning originates in server-side metadata that the model treats as infrastructure. The model has no reason to be suspicious of it. It looks like documentation.

The rug-pull variant is nastier. A previously reviewed server pushes an update that changes its tool descriptions, and the host reloads descriptions without re-prompting for user consent. Working rug-pull attacks were demonstrated against WhatsApp and GitHub MCP servers within months of the initial Invariant Labs disclosure. The original approval was genuine; what it covers has simply changed.

The ETDI framework, proposed in 2025 research, addresses this by binding tool definitions to signed JWTs and using OAuth 2.0 scopes to represent tool permissions. It is a sound mitigation; it also demonstrates that the base spec left a meaningful gap, one that researchers felt urgent enough to design a parallel framework around rather than wait for the spec to catch up.

How the Spec's OAuth 2.1 Layer Is Supposed to Govern Access

The June 2025 spec revision made two foundational changes to the authorization model. It officially classified MCP servers as OAuth Resource Servers, formal parties in an authorization flow rather than passive endpoints. And it removed default fallback authentication endpoints in favor of mandatory RFC 9728 Protected Resource Metadata, which requires servers to declare their authorization requirements explicitly rather than relying on assumed conventions.

The November 2025 spec added further requirements. PKCE is now mandatory; clients must verify PKCE support before proceeding and must use the S256 challenge method when capable. Incremental scope requests allow servers to ask for additional scopes at runtime. The Step-Up Authorization Flow formalizes how running operations handle situations where they need permissions not granted at session start.

Two token-handling rules the spec places on servers address a class of attack that is easy to overlook. MCP servers must only accept tokens valid for their own resources; they must not accept or transit foreign tokens. And servers must never pass through the token received from the MCP client to upstream APIs. The spec prohibits this explicitly to prevent confused deputy attacks, where a service acts on behalf of a caller with permissions it was never directly granted. Resource Indicators, now required for MCP clients, mean a token request must name the intended recipient so the authorization server can issue a tightly scoped token valid only for that specific server.

Two additions in the November 2025 spec matter especially at enterprise scale: Client ID Metadata Documents and Enterprise-Managed Authorization (sometimes called Cross App Access). Together they change how clients identify themselves and how administrators govern AI access to internal tools from a single place, the identity provider, without requiring per-user consent screens for every tool interaction. Dynamic Client Registration, by contrast, requires public-facing registration endpoints with strict rate limiting and leads to unbounded database growth as arbitrary clients register. Enterprise-Managed Authorization is partly a direct response to that friction.

Where the Architecture Holds and Where Real Deployments Break Down

The architecture's security properties depend on implementations following the spec. Many do not, and the gap between specification and deployment is where most of the real risk lives.

Hundreds of publicly exposed MCP servers have been identified lacking basic authentication or encryption. Automated scans of MCP projects in 2025 found thousands of AI security risks and code implementation vulnerabilities across the ecosystem. The protocol's optionality around authentication becomes a systemic deployment risk because the compliant choice is not necessarily the secure choice.

CVE-2025-6514, carrying a CVSS score of 9.6, is instructive precisely because it was an implementation failure, not a spec failure. The mcp-remote OAuth proxy accepted server-provided OAuth endpoints without validation and passed them directly to the system shell. A malicious server could supply an authorization endpoint containing shell command injection, which the proxy then executed with the user's full privileges. Over 437,000 developer environments were affected. The spec did not require the proxy to validate those endpoints, so it did not.

Two production incidents are worth sitting with. In June 2025, a bug in Asana's MCP-powered feature caused customer data to bleed into other customers' MCP instances; the integration was pulled offline for two weeks during remediation. In July 2025, a Replit AI agent deleted a production database containing over 1,200 records despite an explicit instruction to freeze all actions. Proper OAuth scope constraints preventing write and delete operations would have limited the damage regardless of what the agent was told. The Replit incident is the clearest demonstration in the public record that constraining an agent's instructions is insufficient. You have to constrain what the protocol allows the agent to do.

AI-related secrets in public GitHub repositories grew 81% year-over-year in 2025, the fastest growth of any credential category. Approximately 24,000 of those were found in MCP configuration files specifically. That growth rate is a systemic pattern rooted in the STDIO transport model.

What the Architecture Requires at the Governance Layer to Work Safely at Enterprise Scale

Here is the tension that does not resolve itself: the client isolation model is a genuine security property, and it also means centralized visibility is not free. Each client maintains its own session. There is no built-in aggregation layer giving an administrator a view across all active sessions in a host. At enterprise scale, with dozens or hundreds of agents running simultaneously, per-session isolation without a visibility layer means consequential actions are happening in parallel with no coherent audit trail unless someone builds one. The architecture creates the right boundaries. It does not surface what is happening inside them.

Scope minimization is the single most important operational discipline, and the Replit incident is the argument for it. OAuth scopes should represent the minimum permissions an agent needs for its defined task, not the maximum it might conceivably use. This requires intentional scope design before deployment, not reactive tightening after something breaks.

Tool description provenance needs to be treated as infrastructure, not content. The capability discovery mechanism assumes trust in server metadata that the protocol does not cryptographically enforce. ETDI-style signing of tool definitions addresses this, but the organization has to decide where in its stack to enforce that requirement, because the spec will not enforce it for them.

Enterprise-Managed Authorization resolves a real operational tension that most teams only discover after they have already built around the wrong model. Centralizing AI access governance at the identity provider means administrators can revoke or modify access across all agents touching a given resource from one place, rather than hunting through per-client registrations. Adopting it early is substantially easier than retrofitting it onto a system already in production.

MCP's governance model is additive by design. The spec establishes a minimum viable architecture. Everything above that minimum — authentication enforcement, scope minimization, tool description validation, session visibility, audit logging — depends on what the deploying organization builds or adopts on top. The teams that will deploy agents safely are the ones who understand the architecture clearly enough to know exactly where the spec ends and their own responsibility begins. Runlayer, for instance, is built around sitting at that boundary — enforcing policies at the individual tool-call level across all active agent sessions.