Skip to content

MCP and the Context Gap

Why This Page Exists

Since 2025, a cluster of terms — "context layer," "context engineering," "memory layer," "semantic layer" — has spread across vendor blogs, conference talks, and analyst notes, all describing some version of the same claim: agents need durable, structured access to organizational knowledge, and a new architectural layer is emerging to provide it. The terms are used inconsistently. Some sources treat them as synonyms; others as a stack; a few as competing frameworks. Almost all of the definitional content comes from vendors selling a product that the definition happens to require.

One piece of this discourse is not vendor marketing: the Model Context Protocol (MCP). MCP is a real, dated, specification-governed standard, and its own authors are explicit about what it does and does not solve. Understanding MCP precisely — rather than through the vendor gloss layered on top of it — is the fastest way to cut through the rest of the "context layer" discourse, because MCP marks the actual boundary between settled infrastructure and the still-contested territory vendors are racing to define.

What MCP Actually Standardizes

MCP is a protocol: a set of message formats and interaction rules, not a product. It runs over JSON-RPC 2.0 between three roles — a host (the LLM application), a client (a connector inside the host), and a server (something that provides context or capabilities). Anthropic introduced it on November 25, 2024, framing the problem it solves in blunt, specific terms: "every new data source requires its own custom implementation, making truly connected systems difficult to scale" (Anthropic, 2024). That is an integration problem — an N-tools-by-M-applications wiring problem — not a claim about memory, meaning, or governance.

The specification (2025-06-18 revision) defines exactly six primitives, three offered by servers and three by clients (Model Context Protocol, 2025):

Offered by Primitive What it is
Server Resources Context and data, for the user or the model to use
Server Prompts Templated messages and workflows for users
Server Tools Functions the AI model can execute
Client Sampling Server-initiated agentic behaviors and recursive LLM interactions
Client Roots Server-initiated inquiries into which URI/filesystem boundaries to operate in
Client Elicitation Server-initiated requests for more information from the user

That table is the entire surface area of the protocol. There is no seventh primitive for memory, no built-in notion of an "entity," and no field for a governance policy. MCP standardizes how a host reaches a server and what shapes the exchange can take — not what the server remembers, not whether two servers agree on what "customer" means, and not who is allowed to see what.

The Gap MCP's Own Spec Admits

This isn't a gap you have to infer — the specification says it directly, in its own security section: "While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD: build robust consent and authorization flows into their applications..." (Model Context Protocol, 2025). Consent, authorization, and access control are left entirely to whoever builds the host and server — the protocol carries no mechanism to enforce any of it.

That quoted sentence is specifically about enforcement — but the protocol's narrow scope leaves two further gaps beyond it. Together, all three map directly onto the three things "context layer" vendors are each independently trying to sell:

  • No persistence. MCP defines how a server exposes a resource right now. It says nothing about whether that server remembers anything about a prior session — that's a memory system, built on top of MCP or independent of it entirely (Mem0, Cognee, Zep, and Redis's Agent Memory component all live here — see Tooling Landscape).
  • No semantic agreement. MCP doesn't require two servers to mean the same thing by the same word. If a CRM's "customer" and a billing system's "account" are the same real-world entity, MCP has no primitive that says so — that reconciliation is a semantic/entity-resolution layer, built separately.
  • No enforcement. As the spec states outright, access control is an implementor responsibility, not a protocol guarantee. A host that connects to ungoverned MCP servers gets exactly the access those servers choose to grant, however that was decided.

Why MCP Is the One Settled Piece — With a Real Caveat

The rest of the "context layer" discourse deserves real skepticism. The pattern — a durable, unifying layer that will finally give the enterprise one coherent view of its own knowledge — has run before, under other names: master data management, enterprise semantic web and knowledge-graph initiatives, service-oriented integration buses, customer data platforms, data fabric and data mesh. It would be convenient to say those waves faded because they were vendor-siloed and ungoverned, and MCP is different because it has real governance behind it. That's not quite true, and the correction matters. The SOA/web-services era had OASIS, a neutral, not-for-profit consortium founded in 1993 with more than 4,000 participants across 600-plus organizations, and WS-I, a body chartered specifically for cross-platform, cross-vendor interoperability — which wound down cleanly in 2010 by transferring its work to a purpose-built OASIS member section, not by being abandoned or forked apart (OASIS; WS-I). The enterprise semantic web had the W3C itself: OWL is a genuine W3C standard, developed by a dedicated working group as part of a coordinated stack alongside RDF, RDFS, and SPARQL (W3C, 2012). Both waves had real, neutral, multi-vendor governance, and both still faded from the mainstream conversation anyway. Governance alone did not save them — which means MCP having governance is not, by itself, proof that MCP will avoid their fate.

If governance didn't save OASIS, WS-I, or the W3C's Semantic Web committees, why bring up MCP's governance at all? Because what changed is procedural, not just organizational — and that distinction is worth being precise about rather than glossing over. OASIS and WS-I ran on membership process and published specs. WS-I did test conformance — but that tooling certified whether a vendor's product matched an already-finalized profile, not whether a change to the profile itself was allowed to ship. Nothing in either body's record points to a published, dated commitment to a minimum deprecation window, or to a rule that a spec revision itself must pass a conformance test before it can be finalized. MCP's stewards have both, gating the evolution of the spec, not just certifying what's built on top of it. On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare, and Bloomberg. At the time of donation, MCP had more than 10,000 active public servers and over 97 million monthly SDK downloads across Python and TypeScript, with adoption across ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code (Anthropic, 2025). Since the donation, the protocol's stewards have added a Feature Lifecycle Policy requiring at least twelve months between deprecating a feature and removing it, a namespaced Extensions framework (reverse-DNS IDs, separate repositories with delegated maintainers, independent versioning) built specifically so an extension can evolve without forking the core protocol, and a rule that a Standards Track proposal cannot reach Final status until a matching scenario lands in the conformance test suite (MCP, 2026).

That's a real difference in mechanism, by the page's own read of what's published — but it is an untested one. Nothing about OASIS's or the W3C's committees suggests they failed for want of procedural discipline; adoption economics and shifting vendor incentives look like the more likely cause, and those are exactly the forces MCP's governance model has no more power over than its predecessors did. The current "context layer" wave shares that same vendor-incentive tell: one of the most visible voices defining the term is Atlan, a data-catalog vendor whose own guide to "context layer" positions Atlan's product line — an "Enterprise Data Graph," "Context Agents," and a "Context Lakehouse" — as the delivery mechanism for the category it is defining (Atlan, 2026). That's a company defining the category in the shape of the product it sells. It isn't disqualifying on its own, but it's the same question this page keeps returning to: what, specifically, is being added on top of MCP, and by whom?

MCP's governance also stops at the protocol core; it has no jurisdiction over the ecosystem built on that core, and that ecosystem already shows a familiar pattern, present tense. A 2025 measurement study crawled 17,630 listed entries across six major MCP marketplaces and found more than half are invalid or low-value; of the entries that passed validity filtering, 8,401 projects (8,060 servers and 341 clients) were analyzed in depth. Servers specifically face structural risks including dependency monocultures and uneven maintenance, while clients are still in a transitional phase of protocol and connection patterns (Guo et al., 2025). That study measured the marketplace layer, not any causal effect of protocol governance on it, so the parallel to SOA's and the semantic web's own tool sprawl is an observation, not a proven mechanism — but it's a real one worth naming plainly: a well-governed core protocol coexists, right now, with an ecosystem on top of it that looks a lot like the ones this page is skeptical of. The honest summary: MCP itself is on firmer, more precisely-governed ground than "context layer" as a marketing category — but firmer ground is a lower bar than "unprecedented," and the ecosystem growing on top of MCP hasn't earned that word yet either.

A handful of independent academic preprints have also started proposing names and structures for what should sit on top of MCP — a maturity model running prompt engineering through context, intent, and specification engineering (Vishnyakova, 2026), and a declarative, Kubernetes-inspired governance model for the same gap (Mouzouni, 2026). Both are solo-author arXiv preprints, unreviewed — real proposals, not yet a field consensus.

Reading a "Context Layer" Pitch, Now That You Know This

Once the boundary is clear, a vendor's "context layer" or "context engineering" pitch becomes easy to place. Ask what it's actually claiming to add on top of MCP's six primitives:

  • If the pitch is about remembering things across sessions — that's a memory-layer claim; see the tools named above.
  • If the pitch is about making different systems agree on what an entity means — that's a semantic/entity-resolution claim, closer to the metadata and lineage work already covered in Data Readiness.
  • If the pitch is about deciding who can see or change what — that's a governance and access-control claim, the domain AI Governance Framework already owns.
  • If the pitch bundles all three under one new noun and implies you need to buy the whole stack from one vendor to get any of it — treat that framing with the same skepticism this track applies to any single-vendor lock-in claim (see Common Failure Modes in the Technology Architecture Framework).

None of the three gaps require abandoning MCP or waiting for the "context layer" category to mature — they're solvable today, piece by piece, on top of a protocol that is already standing on solid, checkable ground. For the current landscape of tools that fill the memory piece specifically, see the Memory and Context Frameworks category in the Tooling Landscape. For the security risk this same connectivity introduces — a different question from what MCP structurally covers — see Supply Chain and MCP Risk.

Sources

  • Anthropic — Introducing the Model Context Protocol, 2024-11-25. Every new data source requires its own custom implementation, making truly connected systems difficult to scale. The Model Context Protocol is an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools. View source · verified 2026-07-08 · primary
  • Model Context Protocol — MCP Specification (2025-06-18 revision), 2025-06-18. Servers offer any of the following features to clients: Resources: Context and data, for the user or the AI model to use. Prompts: Templated messages and workflows for users. Tools: Functions for the AI model to execute. Clients may offer the following features to servers: Sampling: Server-initiated agentic behaviors and recursive LLM interactions. Roots... Elicitation... View source · verified 2026-07-08 · primary
  • Model Context Protocol — MCP Specification (2025-06-18 revision) — Security and Trust & Safety, 2025-06-18. While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD: Build robust consent and authorization flows into their applications... View source · verified 2026-07-08 · primary
  • OASIS — OASIS organization description (via innoQ SOA/web-services standards overview), 2026. OASIS is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. Founded in 1993, OASIS has more than 4,000 participants representing over 600 organizations and individual members in 100 countries. View source · verified 2026-07-10 · primary
  • WS-I / OASIS / InfoQ — WS-I charter (via innoQ) and WS-I-to-OASIS transition announcement (InfoQ, Nov 2010), 2010. The Web Services Interoperability Organization is an open industry organization chartered to promote Web services interoperability across platforms, operating systems and programming languages. ... The Web Services Interoperability (WS-I) organization has just announced that its mission has been accomplished and it is transferring all future efforts to OASIS. ... OASIS announces the creation of a Web Services Interoperability Member Section to accept and take over the donations from the WS-I. View source · verified 2026-07-10 · primary
  • W3C — OWL (Web Ontology Language) — W3C standard page, 2012. The current version, OWL 2, was developed by the W3C OWL Working Group and published in 2009, with a Second Edition released in 2012. OWL is part of the W3C's Semantic Web technology stack, which includes RDF, RDFS, SPARQL, etc. View source · verified 2026-07-10 · primary
  • Anthropic — Donating the Model Context Protocol and establishing the Agentic AI Foundation, 2025-12-09. co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, Amazon Web Services (AWS), Cloudflare, and Bloomberg... more than 10,000 active public MCP servers... 97M+ monthly SDK downloads across Python and TypeScript... adopted by ChatGPT, Cursor, Gemini, Microsoft Copilot, Visual Studio Code. View source · verified 2026-07-08 · primary
  • Model Context Protocol — MCP specification update blog post (release-candidate governance mechanics), 2026-05-21. The feature lifecycle policy gives every feature an Active, Deprecated, and Removed lifecycle with at least twelve months between deprecation and the earliest possible removal. ... extensions are identified by reverse-DNS IDs, negotiated through an extensions map on client and server capabilities, live in their own ext-* repositories with delegated maintainers, and version independently of the specification. ... a Standards Track SEP can no longer reach Final status until a matching scenario lands in the conformance suite. View source · verified 2026-07-10 · primary
  • Atlan — Context Layer for AI Agents: Enterprise Guide 2026, 2026-05-08 (published), updated 2026-06-30. the de facto standard for connecting agents to tools (referring to MCP). Atlan's own guide names its product line — Enterprise Data Graph, Context Agents, Context Lakehouse — as the delivery mechanism for the context layer it describes. View source · verified 2026-07-08 · primary
  • Guo, Hao, Zhang, Xu, Lv, Chen, Cheng — A Measurement Study of Model Context Protocol Ecosystem (arXiv:2509.25292), 2025. more than half of listed projects are invalid or low-value... servers face structural risks including dependency monocultures and uneven maintenance, [while] clients exhibit a transitional phase in protocol and connection patterns. View source · verified 2026-07-10 · primary
  • Vishnyakova, V.V. (independent arXiv preprint author) — Context Engineering: From Prompts to Corporate Multi-Agent Architecture (arXiv:2603.09619), 2026. whoever controls the agent's context controls its behavior; whoever controls its intent controls its strategy; whoever controls its specifications controls its scale. View source · verified 2026-07-08 · primary
  • Mouzouni, C. (independent arXiv preprint author) — Context Kubernetes: Declarative Orchestration of Enterprise Knowledge for Agentic AI Systems (arXiv:2604.11623), 2026. establishes a three-tier permission model ensuring agent authority remains subordinate to human authority... Formal verification using TLA+ model-checking confirms safety across millions of states. View source · verified 2026-07-08 · primary