Model Context Protocol: Why MCP Is Not a Memory Layer

The Model Context Protocol (MCP) is an open standard that lets an AI application discover and call tools on an external system through one message format, instead of a hand-written integration per tool. It is a capability protocol. It is not memory, and as of the current specification it holds no state at all.

That last clause is where most explainers go wrong, and it is our angle. Read almost any article about MCP and you will find a promise that the protocol gives agents "shared, persistent context" across tools and sessions. It never carried memory in any revision. Earlier versions had a connection-level session identifier, which is not the same thing as remembering anything. On 28 July 2026 the specification removed sessions outright, and every request became self-contained. A widespread marketing claim became a documented impossibility. If you are choosing an agent platform on the belief that MCP will carry memory between your tools, you are buying something the standard does not sell.

The confusion is not the reader's fault. On Hacker News in June 2025, a developer posting as iambateman asked the thread outright how to think about MCP next to a normal web API: "A REST API makes sense to me…but this is apparently significantly different." That question has been answered a thousand times since, mostly in metaphors: USB-C, a universal adapter, a plug. Almost never with the one sentence that resolves it: MCP standardises what an agent can find out and invoke, not what an agent remembers.

The short answer: MCP is a stateless, JSON-RPC capability protocol that standardises tool discovery and tool invocation between AI applications and external systems. Memory, orchestration, identity and audit remain entirely your problem, and the July 2026 revision makes that division of labour explicit.

Last updated: July 30, 2026.

We have not run a production MCP fleet ourselves and this article reports no benchmark of our own; every protocol claim below was read directly from the 2026-07-28 specification and the project's own changelog on 30 July 2026 rather than from a secondary explainer, and each is linked so you can check it.

The protocol owns discovery and invocation. Memory, identity, policy and audit sit outside it.

What the Model Context Protocol Actually Is

MCP is an open protocol, published by Anthropic on 25 November 2024, for connecting AI applications to the systems where data and tools live. Anthropic's launch note described it as a new standard for connecting AI assistants to the systems where data lives, covering content repositories, business tools and development environments. The specification defines three roles and one wire format, and almost everything else people attribute to MCP is built on top by somebody else.

The three roles come straight from the spec, and they form an ordinary client-server architecture rather than anything novel. A host is the LLM application that initiates connections: a desktop assistant, an IDE, an agent runtime. A client is the connector inside that host which speaks to one server. A server is the service that exposes context and capabilities. Messages between them follow JSON-RPC 2.0, the same plain request/response envelope that has been in use since long before agents existed.

What a server can offer is a short list, and its shortness is the point:

Three server features, one client feature. That is the core protocol as of the 2026-07-28 revision. Everything more exotic, from asynchronous long-running work to interactive UI panes and richer agent instructions, lives in opt-in extensions that both sides must explicitly negotiate.

The spec is candid about its own lineage, comparing itself to the Language Server Protocol: LSP standardised how editors talk to language tooling so that every editor did not need bespoke support for every language, and MCP aims at the same shape for AI applications and tools. That analogy is more useful than USB-C, because it carries the right implication. LSP did not make editors smarter. It made an N×M integration problem into an N+M one. MCP's claim is the same, and it is a claim about plumbing, not intelligence. The Hacker News thread that named it an accidentally universal plugin system was closer to the truth than most vendor copy: a plugin interface is exactly what this is.

A commenter on Hacker News put the deflationary version well in November 2025. Reacting to a thread arguing that MCP is over-hyped, a developer posting as cjonas wrote that people are confused about what it is: "It's just a standard way to provide an LLM with tools." Strip the marketing and that sentence survives contact with the specification. A reply in the same thread added the part that makes it matter anyway: the standard forced a large number of vendors to think critically about what they expose to a model, which is a real benefit even if the protocol itself is unremarkable.

Adoption followed fast. On 9 December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, citing "more than 10,000 active public MCP servers" and "97M+ monthly SDK downloads across Python and TypeScript." The Linux Foundation's own announcement of the Agentic AI Foundation lists Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI as platinum members, with Cisco, Datadog, Docker, IBM, Okta, Oracle, Salesforce, SAP, Snowflake and others at gold. Treat the server and download counts as vendor-reported: they come from the donating organisation, and no independent census of the MCP ecosystem exists. The membership list is a harder fact, and it is the one that matters for a procurement conversation.

Why MCP Has No Memory, and Never Did

MCP does not provide memory, shared context, or continuity between calls. The specification now says so in a section of its own: MCP is a stateless protocol in which "all the information needed to process a request is contained in the request itself," and a server "MUST NOT rely on prior requests over the same connection to establish context." Anything that must span requests has to be referenced by an explicit identifier the client passes every time.

There is no shared memory between agents in MCP, no cross-tool recall, and no mechanism by which one server learns what another server returned. The word "context" in the protocol's name is doing a lot of unearned work in the public understanding of it. In MCP, context means the material a server can hand to a model for a given call: a file, a database row, a document excerpt, exposed as a resource. It has never meant a durable store that follows an agent around. The confusion is understandable and it has been commercially convenient, because "the protocol remembers" is a much better slide than "the protocol standardises two verbs."

Until mid-2026 the claim at least had a fig leaf. Earlier revisions had an initialize handshake and, over HTTP, an Mcp-Session-Id header, so a connection did carry something you could loosely call session state. The 2026-07-28 revision removed both. Per the changelog, the revision removes "protocol-level sessions and the Mcp-Session-Id header," removes the initialize/notifications/initialized handshake, and requires every request to carry its own protocol version and client capabilities in a _meta block. Servers that genuinely need cross-call state now "use explicit, server-minted handles passed as ordinary tool arguments."

Read that last sentence as an architecture instruction rather than a footnote. It says: if your workflow needs to remember something between steps, you build the store, you mint the handle, you decide who is allowed to present it. The protocol will carry the handle as an argument and take no responsibility for it.

The maintainers were explicit about why. In the release post for the 2026-07-28 specification, lead maintainers David Soria Parra and Den Delimarsky described statelessness as "one of the most highly-requested features from developers who were eager to get better reliability and scalability for their MCP servers," and spelled out the operational payoff: "Any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage."

That is a genuinely good trade for anyone running MCP servers in production. It is also, for anyone who bought the memory story, a quiet correction issued at the level of the standard itself. Three consequences follow, and they are the practical part of this whole article:

1. Continuity is an application feature, not a protocol feature. If your agent needs to know what it did yesterday, that lives in your own database, your own vector store, or your own conversation history. Never in MCP.
2. State handles become a security object. Because a handle is just a tool argument, anyone who obtains one can present it. The spec's own security guidance names this: MCP servers "MUST NOT treat possession of a state handle as authentication," and should bind handles server-side to the authenticated user.
3. Comparisons that credit MCP with memory are comparing against a fiction. Any evaluation matrix with a "persistent shared context" row for MCP is scoring the wrong thing, and the vendor who wrote it either has not read the spec or is counting their own layer as the protocol's.

MCP vs API vs Agent Framework: What Each Layer Owns

The MCP vs API question is the single most common entry point to this topic, and it has a clean answer: they are not alternatives, they are different layers, and most real systems use all three. A REST or GraphQL API is a contract you must know about at design time and wire up yourself. MCP is a convention on top of such contracts that lets a model ask, at runtime, "what can you do?" and then invoke one of the answers. An agent framework is the code that decides which question to ask and what to do with the reply.

The frameworks themselves settled this argument by adopting the protocol rather than competing with it. LangChain reaches MCP servers through the langchain-mcp-adapters library, which converts MCP tools into LangChain tools, resources into blobs, and prompts into chat messages, and which, notably, is "stateless by default," creating a fresh session per tool invocation. A framework treating each call as independent is a framework that has read the same spec you just did.

The dynamic tool discovery point is where MCP genuinely differs from an API and where the governance consequences begin. With a conventional integration, the set of things your software can do is fixed when you ship it. With MCP, the set of things an agent can do is whatever the servers it is connected to return from tools/list at the moment it asks. That is the feature. It is also the reason "which tools can this agent invoke?" stops being a question you can answer by reading your own source code.

Function calling deserves its own line here, because people often use the two terms as if they compete. Function calling is a model capability: the model emits a structured request to invoke a named function you defined. MCP is the transport and description convention that lets the function definitions come from somewhere other than your own codebase. You still need function calling; MCP just changes where the catalogue lives.

The honest summary of MCP vs API is therefore not "MCP is better." It is: MCP moves the integration surface from design time to run time, buys you reuse across every MCP-speaking host, and hands you a new operational question in exchange. The reuse argument is also the vendor lock-in argument in reverse. A tool exposed over MCP is portable between hosts in a way a bespoke integration into one assistant never is, which is a genuine strategic reason to prefer it even when the technical case is thin.

How MCP Works: One Tool Call, End to End

Here is how MCP works in practice, at the wire level, using the current revision. Two round trips do the whole job: the client asks what exists, then calls one of the things that exist. Nothing else is mandatory.

Step 1 — discovery. The client sends tools/list. Under the 2026-07-28 revision there is no handshake first; the request carries its own protocol version and the client's capabilities in _meta:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": { "name": "acme-agent", "version": "1.4.0" }
    }
  }
}

If the server does not support the declared version it returns UnsupportedProtocolVersion (-32022) listing what it does support, and the client retries or gives up. A client that wants to settle versions up front can call server/discover, which the spec makes a mandatory RPC returning supported versions, capabilities and identity in one request.

Step 2 — invocation. The client picks a tool from the returned list and calls it. The _meta block is where trace context rides along; the spec documents the W3C traceparent key for exactly this purpose:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" },
    "_meta": { "traceparent": "00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01" }
  }
}

Step 3 — the result. Every result now carries a resultType. "complete" means the operation finished. "input_required" means the server needs something more from the user or the client (a credential, a confirmation, a choice) and returns an InputRequiredResult whose inputRequests field says what. The client gathers the answers and retries the original request with inputResponses attached. This is the Multi Round-Trip Requests pattern, and it replaced the old model in which servers sent requests back to clients mid-flight.

Four things are worth noticing about that exchange, because they are the whole design in miniature.

The tool description is data the model obeys. tools/list returns names, descriptions and JSON Schemas, and the model treats them as instructions about what is available and what it does. Whoever controls a server controls text that steers a model.

Nothing in the exchange identifies a human. Authorisation is a separate framework layered on HTTP transports; over stdio the spec says credentials come from the environment instead. Identity is adjacent to the protocol, not inside it.

The list can change between calls. tools/list results now carry ttlMs and a cacheScope of "public" or "private" as freshness hints, precisely because clients cache them and the underlying set is not guaranteed stable.

There is no conversation. An open stdio process, the spec notes, "is not a conversation or session": clients may interleave unrelated requests on the same transport. If you were picturing a session, delete the picture.

What the 2026-07-28 Revision Changed

The current MCP revision, published 28 July 2026, is the largest breaking change in the protocol's history, and any explainer written before it is now describing a version that is being deprecated around you. If you are evaluating platforms or reading vendor documentation, the table below is the fastest way to tell whether what you are reading is current.

Three of those deserve a sentence each for anyone planning work.

Deprecation now has a clock. The revision adopted a feature lifecycle and deprecation policy with Active, Deprecated and Removed states and a minimum twelve-month deprecation window, plus a public registry of deprecated features. That is unglamorous and it is the single most enterprise-relevant thing in the release: it converts "the standard keeps moving" from an unbounded risk into a planning horizon, and it puts interoperability between mixed-version clients and servers on a documented footing rather than a hopeful one.

Sampling is on the way out. Sampling let a server ask the client's model to generate something. It is now deprecated, with the suggested migration being to integrate directly with an LLM provider API instead. If a vendor is selling you an architecture that leans on MCP sampling, ask which protocol version their roadmap targets.

Version skew is now per-request, not per-connection. Because every request declares its own version and the server accepts or rejects each independently, a mixed fleet does not fail at connect time. It fails at call time, on some calls and not others. That is friendlier to rolling upgrades and considerably less friendly to debugging, which is an argument for centralising MCP traffic somewhere you can see it.

Migration is real work, and the maintainers said so: the release post concedes "there will be some migration cost, especially for developers that did depend on session identifiers," while pointing to SDK migration notes. The spec keeps a backward-compatibility path for handshake-based revisions, so a big-bang cutover is not required.

What MCP Does Not Do

The most useful section of any explainer is the one listing what the thing is not, because that is where a buyer's assumptions get corrected before they become a purchase order. MCP is a narrow standard by design. Here is the boundary, stated plainly.

It is not memory. Covered above, and worth repeating because it is the claim most likely to appear in a competitor's feature grid.

It is not an authorisation model. The specification provides an authorisation framework for HTTP transports built on OAuth, but it governs how a client obtains a token for a server, not what your organisation's policy about that access should be, and not who inside your company is allowed to approve a new connection. Over stdio, the spec explicitly says implementations should not follow the authorisation framework and should take credentials from the environment.

It is not a trust boundary. The spec's own framing is unusually direct: "While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD" build consent flows, access controls and documentation. It also warns that tool annotations "should be considered untrusted, unless obtained from a trusted server." A protocol that tells you its own descriptions are untrusted is a protocol telling you where your controls have to live.

It is not orchestration. Retries, branching, human approval steps, budget caps, scheduling. None of that is in MCP. Those belong to whatever runs your agent.

It is not a curation service. The official MCP Registry is metadata, not vetting. It does namespace authentication through DNS and GitHub verification so that a server name provably belongs to its claimed owner, and it is explicit that it "delegates security scanning" to the underlying package registries and to downstream aggregators. Namespace ownership tells you a package is genuinely from com.example. It tells you nothing about whether com.example should be allowed near your CRM.

It is not agent-to-agent messaging. MCP connects an AI application to tools and data. Coordination between separate agents is a different problem with different standards, and the Agentic AI Foundation's project list makes the separation visible.

The Cost Line Missing From Every MCP Explainer

Every tool an MCP server exposes has a description and a JSON Schema, and in the conventional pattern those definitions are loaded into the model's context before the user's request is even read. That is the cost line, and it is missing from essentially every conceptual explainer of the protocol because it only shows up on an invoice.

Anthropic's engineering team documented the scale of it in a post on 4 November 2025 on running MCP through code execution, which reports reducing token usage in one worked scenario "from 150,000 tokens to 2,000 tokens—a time and cost saving of 98.7%." The two culprits it names are tool-definition overhead, where every connected server's full tool list occupies context, and intermediate result duplication, where a large document retrieved by one tool and passed to another traverses the model's context twice.

Two structural facts make this a governance problem rather than a tuning problem.

The first is that the cost scales with connections, not with usage. Add a tenth MCP server to an agent and every subsequent request pays for its tool definitions, whether or not any of those tools are ever called. A team that connects servers enthusiastically raises the floor price of every interaction for everyone using that agent.

The second is that spend attribution breaks at the fan-out. One user instruction can produce a chain of tool calls across several servers, each with its own latency and token cost, resolved at runtime. Attributing that to a person, a team or a cost centre after the fact requires a record that spans the whole chain. That is exactly what a stateless protocol will not give you on its own, and exactly why the answer lives at the gateway rather than in the client.

We are not going to give you a dollar figure, because any single number would be invented. The cost of an MCP deployment is a function of your tool inventory, your model's price per token and how often agents fan out, and none of those are knowable from outside your organisation. What is knowable is the measurement: sum the token length of every tool definition your agent loads, multiply by requests per day, and price it at your current input rate. That arithmetic takes an afternoon and it is the only MCP cost number worth quoting internally.

Mitigations exist and are worth naming, because the fix is architectural rather than a matter of connecting fewer things. On-demand tool discovery, in which the agent searches for the tools it needs rather than loading all of them, addresses the definition overhead. Executing tool chains as code in a sandbox, filtering results before they reach the model, addresses the duplication. And the 2026-07-28 revision quietly helps: because standard MCP request headers are now required on Streamable HTTP POSTs, the release post notes that "gateways can route and meter on those headers instead of parsing JSON bodies." Metering MCP traffic just got substantially cheaper for anyone who puts a gateway in the path. Our analysis of how model routing changes LLM spend covers the budgeting side of the same problem.

What the Evidence Says About Real MCP Servers

Academic measurement of the MCP ecosystem now exists, and it is less reassuring than the adoption numbers. Two studies are worth knowing before you approve a server.

The first empirical study, Model Context Protocol (MCP) at First Glance by Hasan, Li, Fallahzadeh, Rajbahadur, Adams and Hassan, examined 1,899 open-source MCP servers. It found 7.2% contained general vulnerabilities and 5.5% exhibited MCP-specific tool poisoning, while 66% showed code smells and 14.4% carried known bug patterns. The authors identified eight distinct vulnerability types, only three of which overlap with traditional software vulnerabilities. That is the finding that matters, because it means your existing static analysis will miss most of them.

The second, A First Look at the Security Issues in the Model Context Protocol Ecosystem by Xiaofan Li and Xing Gao, accepted to DSN 2026, went wider: 67,057 servers across six public registries, of which their tooling flagged 833 vulnerable servers and 18 with suspicious descriptions. Their structural conclusion is the one to carry into a procurement meeting: weak vetting at the registry level lets adversarial or hijacked servers enter hosts, and once integrated, "attacker-controlled tool metadata can shape LLM reasoning and induce attacker-intended operations, which hosts execute without independent verification." That is prompt injection delivered through a channel most review processes do not treat as content at all: a field in a tool catalogue.

The specification's own security best practices document is a good companion to those papers and is more forthright than most vendor material. It documents the confused-deputy attack against MCP proxy servers in step-by-step detail, states flatly that MCP servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server," and adds a new entry for the stateless era: state handle hijacking, in which an attacker guesses or obtains a server-minted handle and operates on another user's state. Its mitigation is the sentence every implementer should tape to a wall. Do not treat possession of a handle as authentication.

We wrote about this attack surface at length in our earlier analysis, MCP server security: governing AI connectors, which goes deeper on tool poisoning, OAuth scope design and credential brokering than there is room for here. This piece is the layer beneath it: what the protocol is, and why its shape produces those risks.

It is also worth being fair to the protocol. None of these findings are evidence that MCP is badly designed. They are evidence that a low-friction integration standard produces a large population of low-effort integrations, which is what every successful standard has ever done. The relevant question is not whether the ecosystem is clean. It is what you do at the boundary.

For a clear visual walkthrough of the request path, this Google Cloud Tech explainer covers the same mechanics from an implementer's angle.

The Reconstruction Test: Five Questions Before You Connect

Here is a diagnostic you can run in one sitting, on one agent, today. We call it the Reconstruction Test, and it asks a single question in five parts: from your logs alone, could you reconstruct a tool call that was resolved at runtime? If the answer is no, dynamic tool discovery has moved capability decisions out of your change-control process and into a model's inference, and no amount of policy documentation changes that.

1. Which server? For any given call, can you name the MCP server, its version, and who approved it entering your environment? If servers arrive by developers editing a local config file, the honest answer is no.
2. Which tool, at which revision? tools/list is resolved at call time and its results are cached with a TTL. Can you show which tool definition was in effect when the call was made, not which one is in effect now?
3. On whose authority? Was the call made with a token issued to that MCP server, or with a token minted for something else and passed through? The spec forbids the second. Your logs should be able to prove which one happened. Our analysis of non-human identity — owner, scope and expiry for AI agents covers what a durable answer looks like.
4. Who approved the capability, and when? Not the server, the individual tool. Least privilege at the level of a whole MCP server is not least privilege at all, because a server is a bundle and the bundle can grow. A server you vetted in March can return a new tool in July. If nothing in your process notices, "approved server" has silently become "approved everything that server ever offers."
5. What did it cost, and against whom? Tokens, latency and downstream calls, attributed to a person or a team. If a single instruction fanned out across four servers, the record has to span all four. Our post on AI observability and audit trails sets out what an evidence-grade record contains.

Score it honestly: five yeses means your MCP deployment is governed. Three or fewer means you have an integration, not a deployment. A failing score is still worth having, because the cheapest first fix is always the same one. Produce the inventory that question 1 demands. You cannot approve, meter or revoke a server you have never listed, and in most organisations that list has never been written down.

The point of the name is portability. "Run the Reconstruction Test on that agent" is a sentence a security reviewer and an engineering lead can both act on without a shared glossary.

One caveat before anyone reaches for a network control to answer these questions. MCP over stdio does not cross a network at all: the server is a local process spawned by the host, taking credentials from the environment, and the spec says implementations on that transport should not follow the HTTP authorisation framework. A gateway sees none of it. Locally installed servers therefore need a different control: client-side policy about what may be installed and what it may execute. The specification's security guidance devotes a whole section to local server compromise for exactly that reason. Anyone who tells you a network gateway governs all your MCP traffic has not asked where the servers run.

The test also explains why so many MCP pilots stall between demo and production. Nothing in the demo is hard. Everything in questions 3 through 5 requires infrastructure that nobody budgeted for, because the explainer that sold the team on MCP described a protocol and not an operating model. A developer posting as 9dev described the reality on Hacker News in July 2026 after trying to connect a commercial MCP server to a major enterprise chat product: documentation "often outdated, sometimes contradictory," four different ways to wrap an agent, and multi-tenancy unsupported by any of them. Two months, on integration plumbing, for a protocol whose entire pitch is that integration is solved.

Where Governance Fits, and Where LeapForce Fits

The five questions above are not answerable inside MCP, and that is not a flaw in MCP. It is the division of labour the specification chose. They are answerable in the layer that sits between your agents and everything they reach. That layer is what we build at LeapForce: one controlled place where every AI tool, connector, model and agent is identified, policy-checked, executed with brokered credentials and recorded. Our connectors approach treats a connector registry as something IT vets once, with action-level scoping and credentials exchanged for short-lived tokens per call rather than handed to an agent, and our AI gateway is where identification, policy evaluation and per-call attribution happen in the request path, which is also where the 2026-07-28 header standardisation makes metering cheap. The rollout model we publish is deliberately unheroic: observe first, enforce second, optimize third. Point one team's traffic at the gateway in observe mode, learn what is actually in use, and only then write rules. LeapForce is in active development and we disclose per-capability build status honestly rather than describing planned capabilities as shipping ones.

Honest Limits: What This Analysis Cannot Tell You

This article is a reading of a specification and the public evidence around it, and there are things that reading cannot establish.

We have not benchmarked MCP overhead ourselves. The 150,000-to-2,000-token figure is Anthropic's, from a scenario Anthropic constructed. It is directionally useful and it is not a number you should plug into your own model without measuring your own tool inventory.

The security studies measure public servers, not yours. Both papers sample open registries. A vulnerability rate of 7.2% across 1,899 public servers says something about what you might install; it says nothing about a server your own team wrote and reviewed.

Adoption figures are vendor-reported. "More than 10,000 active public MCP servers" and "97M+ monthly SDK downloads" come from the organisation that donated the protocol. We could find no independent audit of either. The Linux Foundation membership roster is verifiable; the counts are not.

The revision is two days old at the time of writing. Published 28 July 2026, the current specification has not yet met the long tail of client implementations. Anything we say about how statelessness behaves under real load is inference from the design and from the maintainers' stated rationale, not observation.

MCP may not be the right question for you at all. If your integrations are few, stable and internal, the protocol's central benefit, runtime discovery across many hosts, is close to worthless, and the honest recommendation is a plain API and a fixed tool list. Several practitioners argue exactly this, and on a small surface they are right.

We could not independently verify the most-quoted enterprise adoption statistics. Numbers on the share of enterprises running MCP in production circulate widely from analyst firms whose reports sit behind paywalls we did not purchase, so they are excluded here rather than repeated on trust.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.