Abstract
The Model Context Protocol (MCP) is an open standard, originally released by Anthropic in November 2024 and since donated to an independent, Linux Foundation hosted body, that governs how an AI application connects to external tools and data sources. This paper reviews MCP as a system, drawing entirely on the protocol's own specification, its official documentation site, and Anthropic's own announcements, to describe the problem MCP addresses, its host, client, and server architecture, the primitives a server exposes, its transport layer, and how its governance and version history have evolved since release.
The review finds a client server architecture in which one host application manages a dedicated client for every server it connects to, three server side primitives distinguished by who controls each one (tools controlled by the model, resources controlled by the application, prompts controlled by the user), and a wire protocol built on JSON-RPC 2.0 that has moved, across five dated specification revisions in under two years, from a stateful connection handshake to a stateless, per request version declaration. The review also finds that MCP's governance moved from a single vendor to a multi party foundation structure within roughly thirteen months of its release, and flags one widely circulated design analogy whose attribution to Anthropic could not be confirmed on any official page checked during this review.
The paper concludes that MCP's contribution is standardizing connectivity, a distinct concern from the procedural knowledge layer that a mechanism such as Agent Skills provides, and notes that any organization bound by federal or comparable regulatory data handling requirements should review, before deployment, exactly which third party MCP servers a given integration would connect to and what data those servers would receive.
Introduction
An AI application that needs to read a file, query a database, or act on a ticketing system has historically had to be built against that exact system, one integration at a time. Anthropic's own announcement of the Model Context Protocol describes the resulting cost plainly: every new data source requires its own custom implementation, which makes a genuinely connected system difficult to scale, since the number of integrations a team must build and maintain grows with every new tool or data source it wants an agent to reach, not with any shared, reusable layer underneath them.
This is a distinct problem from the one procedural knowledge formats such as Agent Skills address. A Skill tells an agent how to carry out a specific, recurring task once the agent already has a way to reach whatever the task touches. The problem this paper takes up is prior to that one: how does an agent reach an external system in the first place, in a way that does not require a bespoke integration for every combination of AI application and external tool.
The Model Context Protocol is Anthropic's answer to that specific question, open sourced in November 2024 as a universal, open standard for connecting AI systems to data sources, intended to replace fragmented, one off integrations with a single shared protocol. This paper examines MCP as a system: the roles it defines for the applications and servers that use it, the primitives a server can expose, the wire protocol those primitives ride on, and how the protocol's own version history and governance have changed since its release. The aim is to give a reader unfamiliar with MCP a concrete, verifiable account of how the protocol works and why it was built this way, grounded in the protocol's own specification and in Anthropic's own published materials rather than in secondary description.
Background
Before MCP, an AI application that needed to reach an external tool or data source generally did so in one of two ways, and both carry a cost that scales poorly as the number of tools or applications grows.
The first is a fully custom, point to point integration: code written specifically to connect one particular AI application to one particular external system, with no expectation that the same code could serve a second application or a second system. Anthropic's own framing of this state of affairs is direct: every new data source requires its own custom implementation, and the resulting fragmentation is exactly what a shared protocol is positioned to replace.
The second is vendor specific function calling, in which a model provider defines a schema format for describing callable functions and lets a developer register a fixed list of them for a given conversation. This approach standardizes the shape of a single request within one vendor's API, but it does not standardize discovery or connectivity across vendors or across tools: the list of available functions is typically static for the life of a request, defined by the calling application rather than discovered from the tool itself, and a function schema written for one model provider's calling convention is not portable to another's without translation. MCP's own architecture documentation frames its primitive methods, list, get, and call, as enabling dynamic discovery specifically in contrast to this kind of fixed, hard coded function list, though the protocol's own materials stop short of naming any specific vendor's function calling format directly.
Neither of these two prior approaches was designed to answer the question MCP takes up: how a tool or data source should describe itself once, in a form that any compliant AI application can discover and use, without either a bespoke integration or a hard coded, provider specific function list. MCP's own documentation frames this explicitly as a scaling problem, one where the number of integrations needed grows with every new pairing of application and data source under the two prior approaches, and grows only with the number of new systems, not new pairings, once a shared protocol is in place.
MCP Architecture
MCP defines a small set of roles and a small set of primitives, and nearly everything the protocol specifies is a rule about how those roles exchange those primitives over a shared wire format.
Host, Client, and Server Roles
The protocol's own architecture documentation describes three participants. The host is the AI application itself, for example Claude Code, Claude's desktop application, or an integrated development environment, and it is the host that a user directly interacts with and that coordinates one or more clients. A client is a protocol level component, instantiated by the host, that maintains a connection to exactly one server; the documentation states this as a strict one to one relationship, one client per server, even when a single host is coordinating several clients at once. A server is the program that actually provides context, tools, or data, and it can run locally, for example as a local process the host starts directly, or remotely, over a network connection. A local server communicating over standard input and output typically serves exactly one client, while a remote server reachable over a network transport is built to serve many clients from many different hosts at once. This host to client to server structure is the same shape regardless of what a given server exposes, whether that is a filesystem, a database, or a business application, which is what allows a single client implementation inside a host to work against any compliant server without host specific code for that server.
The Three Core Primitives and Who Controls Each
A server exposes its capabilities through three primitives, and MCP's own documentation distinguishes them by naming who or what controls each one rather than only by what each one contains.
This three way division matters for reasoning about what a given MCP integration actually does: a server that only exposes resources is a read only context source the model consults but cannot act through, while a server exposing tools is one the model can actively drive, and a server exposing prompts is offering the user, not the model, a way to invoke a particular combination of the other two. Alongside these three server side primitives, the protocol also defines client side primitives that let a server ask something of the host rather than the reverse; elicitation, for example, lets a server request a specific piece of information from the user mid interaction, such as asking a seat preference while booking travel. Two earlier client side primitives, sampling, which let a server ask the client's own model for a completion, and roots, which let a client tell a server which filesystem paths to focus on, are both marked as deprecated in the protocol's current specification revision, a detail worth noting for any implementation built against an earlier version of the spec.
Transport and Wire Protocol
Every message exchanged between an MCP client and an MCP server is a JSON-RPC 2.0 message; this is a hard requirement in the specification, not an implementation choice left to individual servers. Two transport mechanisms carry those messages. Standard input and output transport is used for local processes running on the same machine as the host, and it is this transport that typically serves exactly one client per server. Streamable HTTP is the transport used for remote servers reachable over a network, and it is built to serve many clients at once. Streamable HTTP itself replaced an earlier transport, described in the specification as HTTP combined with server sent events, and that earlier transport has since been formally reclassified as deprecated under the protocol's own feature lifecycle policy, with existing implementations directed to migrate to Streamable HTTP.
Versioning and the Move to a Stateless Handshake
MCP versions its specification by date rather than by a conventional major or minor number, and five such dated revisions are traceable in the protocol's own published history: an original release, a revision that introduced Streamable HTTP as a replacement for the earlier transport, a widely referenced stable revision, a further revision, and the specification's current revision. Under the version scheme used through the widely referenced stable revision, a client and server negotiated compatibility through an explicit initialize handshake at the start of a connection, with the negotiated version subsequently carried on later requests through a dedicated protocol version header on network transports. The current specification revision removes that handshake entirely: every request now carries its own protocol version and client capabilities directly, and a server must implement a discovery method to advertise which protocol versions, capabilities, and identity it supports, with a mismatched version returning a specific, named error rather than failing the connection during an initial negotiation step. This is a substantial architectural change to how compatibility is established, moving from a connection level negotiation to a per request declaration, and it is recent enough, relative to when this paper was prepared, that its practical migration impact across existing MCP servers had not yet been broadly documented at the time of this review.
Design Rationale
MCP's central design bet is that connectivity between an AI application and an external tool or data source should be a shared, standardized layer rather than something every application and every tool builds separately, and three specific design choices follow from that bet.
The first is discoverability. Because a server's tools, resources, and prompts are each retrievable through a listing method rather than hard coded into the calling application ahead of time, a host can connect to a server it has never seen before and learn what that server offers at connection time, rather than requiring the application's own code to already know the server's capabilities in advance. This is the specific advantage MCP's own architecture documentation claims over a static, hard coded list of callable functions defined entirely on the calling side.
The second is the strict separation of roles between host, client, and server. Because a client's only job is to maintain one connection to one server, and a host's job is to coordinate however many clients a given task needs, a host implementation does not need special case logic for any particular server; every server the host reaches looks the same at the client interface, whether it is a filesystem, a ticketing system, or a database. This separation is also what makes the three primitive types meaningful as a design choice rather than an arbitrary categorization: naming the model, the application, and the user as the three distinct controllers of tools, resources, and prompts respectively gives an implementer a direct answer to the question of who is responsible for deciding when each kind of capability gets used.
The third is standardization through open governance rather than single vendor control. Anthropic open sourced MCP at release in November 2024, and roughly thirteen months later transferred its governance to the Agentic AI Foundation, a directed fund under the Linux Foundation co founded by Anthropic together with other model providers and cloud infrastructure companies, with the protocol now formally structured as an independent project under that foundation's policies. Anthropic's own announcement of that transfer reported more than ten thousand active public MCP servers and adoption across multiple AI applications beyond Claude itself at the time of the transfer, offered as evidence that the protocol had reached a scale where independent governance, rather than continued single vendor stewardship, was the appropriate structure.
Table 1 places MCP against Agent Skills, the complementary Anthropic mechanism examined in a companion review, using Anthropic's own published comparison rather than an inferred one.
Anthropic's own comparison is direct on the relationship between the two: Skills do not replace MCP, since the two solve different problems, MCP providing connectivity and Skills providing the procedural knowledge for using that connectivity well, and Anthropic's own materials describe the most capable workflows as using both together rather than treating either as a substitute for the other.
Compliance note
One design consequence warrants a compliance oriented note given how frequently MCP connects an agent to systems outside the AI application's own boundary. Because an MCP server can be operated by any party, run locally or remotely, and receive whatever data the connected client sends it, each MCP server a host connects to is, from a data governance standpoint, a distinct third party recipient of the request and context passed to it, regardless of who wrote the server. For an organization operating under federal contracting or comparable regulatory data handling obligations, this means an MCP integration's actual compliance posture depends entirely on which specific servers a deployment connects to and what data flows to each one, a determination that must be made per integration rather than assumed from the protocol's own openness or from Anthropic's role in originating it. This paper flags the exception; it does not resolve it, since the applicable compliance determination is specific to each deployment and is outside this paper's own scope.
Experimental Setup
This paper is a specification and documentation grounded technical review rather than an experiment on running code, so reproducibility here means a reader independently locating and confirming the same primary sources this paper cites against the live specification, rather than rerunning a measurement. Because MCP's own specification is dated and has changed materially across revisions, every claim in this paper about roles, primitives, transports, and version negotiation is tied, where the underlying source states it, to a specific dated specification revision rather than treated as a single unchanging fact about the protocol.
Claims in this paper are drawn from three kinds of primary sources: the official specification and documentation hosted at modelcontextprotocol.io, the official modelcontextprotocol GitHub organization and its repositories, and Anthropic's own announcements on anthropic.com and claude.com.
Verification note
Two specific claims that circulate widely in secondary discussion of MCP could not be confirmed on any of these primary sources during this review and are flagged rather than asserted as fact. First, a shorthand description of the integration problem MCP solves, sometimes phrased as an “M by N” integration problem, does not appear on any official page checked for this review; Anthropic's own wording describes the same underlying cost without using that specific shorthand, and this paper reports Anthropic's own wording rather than the shorthand. Second, a widely repeated analogy comparing MCP to a universal hardware connector standard could not be confirmed as Anthropic's own phrase on any official page reachable during this review, one specification page that reportedly contains it having failed to load during this review's research pass; this paper does not use the analogy as an attributed Anthropic quote as a result, and a reader who wants to cite it should verify it directly against the live specification introduction page first.
Sources consulted
PrimaryAnthropic. “Introducing the Model Context Protocol.” (November 25, 2024)
anthropic.com/news/model-context-protocol
Supports the definition of MCP, the fragmentation problem statement, and the open sourcing of the protocol.
PrimaryAnthropic. “Donating the Model Context Protocol and establishing the Agentic AI Foundation.” (December 9, 2025)
anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
Supports the governance transfer, the foundation structure, and adoption figures at the time of transfer.
PrimaryAnthropic Engineering. “Equipping agents for the real world with Agent Skills.”
anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
Supports the framing of Skills and MCP as complementary rather than competing.
PrimaryClaude Blog. “Extending Claude's capabilities with skills and MCP servers.” (December 19, 2025)
claude.com/blog/extending-claude-capabilities-with-skills-mcp-servers
Supports the Skills versus MCP comparison table and the “does not replace” statement.
PrimaryModel Context Protocol. “Governance.”
modelcontextprotocol.io/community/governance
Supports the Lead Maintainer, Core Maintainer, and Maintainer structure and the Linux Foundation policy relationship.
PrimaryModel Context Protocol. “Architecture” (2026-07-28 documentation)
modelcontextprotocol.io/docs/2026-07-28/learn/architecture
Supports the host, client, and server definitions, transport descriptions, and the list, get, call discovery framing.
PrimaryModel Context Protocol. “Server concepts” (2026-07-28 documentation)
modelcontextprotocol.io/docs/2026-07-28/learn/server-concepts
Supports the tools, resources, and prompts definitions and their respective controllers.
PrimaryModel Context Protocol. “Client concepts” (2026-07-28 documentation)
modelcontextprotocol.io/docs/2026-07-28/learn/client-concepts
Supports the elicitation, sampling, and roots definitions and the deprecation of the latter two.
PrimaryModel Context Protocol. “Changelog” (specification revision 2026-07-28)
modelcontextprotocol.io/specification/2026-07-28/changelog
Supports the stateless handshake change, the discovery method, and the deprecation of the earlier transport.
PrimaryModel Context Protocol. “Streamable HTTP transport” (specification revision 2026-07-28)
modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
Supports the transport replacement history.
PrimaryModel Context Protocol. Specification, revision 2025-06-18
modelcontextprotocol.io/specification/2025-06-18
Supports the earlier initialize handshake and protocol version header behavior.
PrimaryModel Context Protocol. Specification base protocol overview, revision 2025-06-18
modelcontextprotocol.io/specification/2025-06-18/basic/index
Supports the JSON-RPC 2.0 requirement and the server feature and client feature grouping.
PrimaryModel Context Protocol GitHub organization
github.com/modelcontextprotocol
Supports the protocol's own description of itself as an open, seamless integration standard.
PrimaryModel Context Protocol specification repository README
raw.githubusercontent.com/modelcontextprotocol/modelcontextprotocol/main/README.md
Supports the repository level description of the protocol.
SecondaryPress coverage referencing a hardware connector analogy for MCP, published following the December 2025 governance transferCited only to note that the analogy circulates publicly; its attribution to Anthropic directly could not be confirmed on an official page during this review.
Results
Two structural results follow from the architecture described above: the shape of the host, client, and server topology itself, and the way the protocol's own version history shows a shift in how compatibility is established between client and server.
Figure 1 shows the topology a single host establishes when it connects to several MCP servers at once, following directly from the one to one client to server relationship described in the official architecture documentation.
Figure 1. One host, three clients, three servers. Each client is fixed to exactly one server.
The diagram makes explicit a structural constraint that is easy to miss when MCP is described only in prose: the host, not the client, is the component that scales to handle many servers, since every client is fixed to exactly one server for the life of that connection. A host adding a new server does not modify any existing client; it instantiates one additional client dedicated to the new server, leaving every other client and server pair untouched.
The second result concerns how the protocol establishes compatibility between a client and a server, which has changed materially across the specification's own dated revisions. Under the widely referenced stable revision, compatibility was established once, at the start of a connection, through an explicit handshake, and the negotiated version then applied to every later request on that connection. Under the specification's current revision, that connection level handshake has been removed entirely in favor of a declaration carried on every individual request, with a dedicated discovery method letting a server advertise its supported versions ahead of time and a specific, named error returned on a mismatch rather than a failed negotiation. Read as a single trend rather than two isolated facts, this is a move away from treating a client and server pair as maintaining shared connection state at all, toward treating every single request as self describing and independently checkable. Whether this reduces or increases the practical burden on server implementers maintaining compatibility across client versions is not yet settled in the protocol's own published materials at the time of this review, since the change is recent relative to when this review was prepared.
Conclusion
The Model Context Protocol answers a specific, previously unstandardized question: how an AI application should discover and connect to external tools and data sources without a bespoke integration for every pairing of application and system. Its host, client, and server architecture, with a strict one to one relationship between each client and the single server it connects to, and its three server side primitives distinguished by whether the model, the application, or the user controls each one, are the concrete mechanism that answers that question, riding on a JSON-RPC 2.0 wire protocol that has itself moved, across the protocol's dated revisions, from a connection level handshake to a per request version declaration. The protocol's governance has moved in a parallel direction, from a single originating vendor to an independent, multi party foundation within roughly thirteen months of release, which this review reads as evidence of the scale the protocol reached rather than as evidence about its technical design. The clearest remaining gap this review can name is that the practical consequences of the recent shift to a stateless, per request handshake are not yet documented at the scale the earlier, stable revision was, and a builder relying on version negotiation behavior should verify it directly against the specification revision a given server actually implements rather than assume the behavior described for any one revision applies universally. Because MCP by design connects a host application to servers operated by any party, an organization bound by federal or comparable regulatory data handling requirements should treat each MCP server a deployment would connect to as its own distinct data governance question, and confirm what data that specific server receives, before connecting an agent handling regulated data to it.
Acknowledgements
This review was prepared entirely from the Model Context Protocol's own published specification and documentation, Anthropic's own announcements, and the protocol's official GitHub repositories, with no external funding. AI assisted search tooling was used to locate and cross check the primary sources listed above; every source cited was independently verified against the URL given rather than accepted from the search tooling's summary alone, and two widely circulated claims that could not be confirmed on an official page are reported as unconfirmed rather than as fact.
