Key Takeaways
- The Model Context Protocol (MCP) is the broadly deployed open standard for connecting AI applications to external tools and data sources, released by Anthropic in November 2024.
- MCP standardizes one slice of the AI integration problem: tool discovery, invocation, and transport between an AI client and an external server.
- The base protocol does not solve enterprise authentication, audit, or governance. Those layers stay with the implementer.
- OpenAI, Google DeepMind, and Microsoft all adopted MCP within months of launch. Anthropic donated the protocol to the Agentic AI Foundation under the Linux Foundation in December 2025.
- An April 2026 OX Security audit estimated 200,000 MCP servers are exposed to remote code execution through the default STDIO transport., Anthropic answered the disclosure with a documentation update only.4
- For most teams the practical question is where MCP stops solving the problem and where the rest of the work begins.
What is MCP?
Anthropic released the Model Context Protocol in November 2024 with launch partners Block and Apollo and four IDE vendors: Zed, Replit, Codeium, and Sourcegraph.1 What started as Anthropic’s design experiment is now industry infrastructure: 97 million monthly SDK downloads by Q1 2026, more than 17,000 public servers across registries,2 and first-class client support across the major AI apps.3
The Model Context Protocol is an open standard that defines how an AI application discovers, invokes, and exchanges data with external tools and resources. It runs over JSON-RPC 2.0 and uses a client-server architecture in which the AI app (the host) connects through an embedded client to one or more independent servers, each fronting a specific resource. MCP is the first standardization attempt the LLM industry agreed on as a body.
The protocol exists because the math broke. Before MCP, connecting five AI agents to ten tools required fifty bespoke integrations. Each agent needed custom code for every tool’s authentication, schema, error handling, and data format. Adding one new tool meant writing five more integrations. MCP collapses the math to N+M. Each tool implements one MCP server. Each agent implements one MCP client. Five agents plus ten tools equals fifteen implementations instead of fifty. Work that used to take months now takes days, when both sides speak the same protocol.
Why does AI need a protocol of its own?
The integration burden has always been there. From the 1990s middleware wars to the 2010s API-as-a-service economy, every wave of enterprise computing has had to solve „how does system A talk to system B.” What changed with LLMs is that the talking became dynamic at inference time. A traditional REST integration was decided once at code-time: the developer picked which endpoint to call, which parameters to pass, which response shape to expect. An LLM-driven integration is decided every turn: the model itself selects which tool to call based on a natural-language request. That shift broke the old math. Picking the integration at runtime means the model needs to know what is available, which means the integration contract has to be discoverable. REST APIs are not discoverable that way. MCP is a response to that pressure, not an architecture designed from first principles.
Three sub-queries dominate the search traffic alongside „what is MCP”: MCP versus API, MCP versus function calling, and MCP versus RAG. The „versus” is misleading. None of these replaces another. Function calling, RAG, and MCP solve different problems and routinely run in the same system, and MCP itself makes API calls under the hood to do its work. The only thing MCP genuinely substitutes for is the hand-built, one-off API integration. The table below sets them side by side to show how they differ, not to pick a winner.
| MCP | Function calling | REST API | RAG | |
|---|---|---|---|---|
| What it is | Open protocol for an AI app to discover and invoke external tools | LLM provider feature that lets a model emit a structured tool-call request | Contract for software-to-software requests, usually over HTTP | Retrieval pattern that feeds source documents into a prompt before generation |
| What it standardizes | Tool discovery, invocation, transport, and session between client and server | The shape of the model’s tool-call output, inside one provider’s API | Request and response format between caller and service | Nothing. It is a pattern, not a protocol |
| Primary consumer | Any MCP-compatible AI client (Claude Desktop, Cursor, ChatGPT) | The LLM provider’s SDK and the app embedding it | A developer writing application code | A retrieval pipeline feeding an LLM |
| Stateful? | Yes. The server holds session context across calls so the model doesn’t resend the tool manifest or rebuild auth on every invocation. The cost is a session footprint that fights serverless scaling. | No. Stateless calls scale cleanly and cost less per request, but the app reconstructs the full conversation history and tool definitions on every call. | Usually no. Standard HTTP request-response. | Depends. RAG is a pattern, not a protocol. |
| Use it when | You want tools written once to work across multiple AI clients and providers | You want one LLM to call a fixed set of in-process tools in your own app | You are integrating software with software, no LLM in the loop | The model needs grounding in a fact corpus it does not already know |
The table above reframes a common debate. The „just use an API” position is right for a wide class of integrations. When the call pattern is deterministic and the integration serves one client, a REST API ships faster and costs less per call. Auditors already know how to read it. However, MCP earns its overhead in three specific scenarios: 1. the same tool needs to serve multiple AI clients without re-integration; 2. the model itself selects which tool to call at runtime; or 3. session state needs to survive across multiple model calls in a workflow. Token cost is the underdiscussed trade-off. Every MCP session pushes a tool manifest into the model’s context window at session init, paid for in tokens on every model completion within that session. The teams who feel it first are the ones running many tools per server and many users per host. This is a classic scenario of being easy to miss in the pilot and expensive to discover in production.
The cost-benefit case for MCP depends on a network effect: one server reusable across many AI clients is only valuable if many AI clients exist and speak the protocol. The adoption curve says they do. MCP went from an Anthropic-only launch in November 2024 to OpenAI, Google DeepMind, and Microsoft all shipping support inside 13 months.3 By December 2025 Anthropic had donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation.2 The public server registry crossed 10,000 servers at that handoff and grew to roughly 17,500 by Q1 2026.2,3 The MCP Dev Summit doubled in attendance year over year, drawing about 1,200 to its April 2026 New York event.,
How Ally Built a Modern Fraud Intelligence Platform
Learn how Ally applied graph analytics and contextual investigation tools to uncover complex fraud networks and strengthen fraud prevention.
Read Case Study
How does MCP work?
MCP defines three components and three primitives. The components answer who talks to whom: 1. the host (the AI app, like Claude Desktop or Cursor), 2. the client (a thin broker process inside the host, one per connected server), and 3. the server (the external process exposing tools or data). The primitives answer what gets exposed: 1. tools (executable functions the model can call), 2. resources (read-only data the model can pull into context as reference material), and 3. prompts (templated invocations the user can trigger). Transport runs over Streamable HTTP, with stdio for local servers. The wire format, the session lifecycle, and the SDKs are documented in depth in the official specification6 and on Wikipedia.3
The pattern worth keeping in your head: an analyst types „show me every customer connected to entities flagged for sanctions risk in the last 90 days” into Claude or Cursor, the same way they might type a question into Google – natural language and conversational analytics. Behind the scenes, the LLM in Claude or Cursor reads that plain-English question, decides which tool to call, and forms the structured call. The MCP server fronting the knowledge graph exposes that tool, runs the call across the graph, and returns the connected list of customers. A RAG retriever would have returned fifty document chunks for the analyst to read through. The graph stays where it lives. MCP standardizes the discovery and invocation contract on top, so any compatible AI client can query the graph without a bespoke connector. The analyst no longer needs to know any query language at all.
What breaks when the components are present but uncoordinated: every AI client rebuilds every integration. The lock-in moves from the model layer to the connector layer.
What does MCP leave unsolved at enterprise scale?
The base protocol covers invocation and discovery. The four layers around it stay open, and each one has a concrete enterprise cost.
Authentication has no canonical flow
The spec does not standardize how a server authenticates its client.6 Implementers choose between Client ID Metadata Document (CIMD) and Dynamic Client Registration (DCR) per server. Production teams describe what separates a real deployment from a demo as „everything around the registration mechanism”. For an enterprise CISO that means every one of the 17,500 servers in the public registry potentially ships its own auth posture and its own credential handling, until the implementer standardizes one. MCP has no SOC 2, no PCI DSS, and no FedRAMP certification as of Q1 2026. Buyers in regulated industries are building those layers themselves on top of the protocol.
Statefulness clashes with serverless
Serverless functions terminate after each invocation. MCP sessions are designed to persist across many calls so a model can build context with a server. The mismatch forces teams who moved their stack to Lambda, Cloud Run, or Vercel to reintroduce the long-lived infrastructure they spent years removing. The official 2026 MCP project roadmap concedes the fit problem: „stateful sessions fight with load balancers, horizontal scaling requires workarounds”. The deprecation of Server-Sent Events six months after it was the official transport (May 2025 to November 2025)6 gives a sense of how fast the wire-level decisions are still moving for buyers trying to architect around them.
Trust is unfinished
This is the most quantifiable gap. In April 2026, OX Security disclosed that the default STDIO transport in MCP executes any operating system command it receives without sanitization, with no execution boundary between configuration and command.4 OX scanned the public IPv4 space and found roughly 7,000 publicly exposed MCP servers with STDIO active; extrapolated, the audit put 200,000 MCP instances at risk of remote code execution.4,5 As part of the same audit, OX submitted a benign proof-of-concept malicious package to 11 MCP registries: 9 of 11 accepted it without security review. 4 Anthropic updated its SECURITY.md file nine days after the disclosure to note that STDIO adapters should be used with caution, and made no architectural changes. 4,5 Tool poisoning, where a malicious tool description nudges the model toward unsafe behavior, and prompt injection through server-controlled completions are both documented attack patterns.10 The protocol itself defines no server-vetting mechanism; vetting is delegated to the registrar or the operator. 4
Governance moved to the Linux Foundation in December 2025
The handoff of MCP from Anthropic to The Agentic AI Foundation fixes the vendor-neutrality concern that kept some enterprises off MCP through 2025.2 It does not fix the readiness gap. MCP’s 2026 project roadmap labels enterprise readiness „the least defined of the four priorities” and names four open items: audit trails, SSO-integrated authentication, gateway behavior, and configuration portability.11 Buyers evaluating MCP for regulated workloads in 2026 should expect to build authentication, audit, and governance layers themselves until the spec catches up.
Sources
- Anthropic: Introducing the Model Context Protocol (November 25, 2024 launch announcement; launch partners, original protocol scope) https://www.anthropic.com/news/model-context-protocol
- Anthropic: Donating the Model Context Protocol and establishing the Agentic AI Foundation (December 2025 governance handoff; 10,000+ servers at handoff, 97 million monthly SDK downloads) https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
- Wikipedia: Model Context Protocol (industry adoption timeline; OpenAI March 2025, Google DeepMind April 2025, Microsoft Semantic Kernel, ChatGPT support, public registry growth) https://en.wikipedia.org/wiki/Model_Context_Protocol
- OX Security: The Mother of All AI Supply Chains, Critical Systemic Vulnerability at the Core of MCP (April 2026 STDIO disclosure; 7,000 publicly exposed servers, 200,000 extrapolated, 9-of-11 registries accepting malicious packages, Anthropic 9-day response) https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/
- VentureBeat: 200,000 MCP servers expose a command execution flaw that Anthropic calls a feature (May 2026 reporting on the OX Security disclosure) https://venturebeat.com/security/mcp-stdio-flaw-200000-ai-agent-servers-exposed-ox-security-audit
- InfoQ: AAIF’s MCP Dev Summit, Gateways gRPC and Observability Signal Protocol Hardening (April 2026 Dev Summit recap, ~1,200 attendees) https://www.infoq.com/news/2026/04/aaif-mcp-summit/
- Agentic AI Foundation: MCP Is Now Enterprise Infrastructure (April 2026 MCP Dev Summit blog post; doubling year-over-year attendance) https://aaif.io/blog/mcp-is-now-enterprise-infrastructure-everything-that-happened-at-mcp-dev-summit-north-america-2026/
- The 2026 MCP Roadmap (official MCP project blog; „stateful sessions fight with load balancers” quote, enterprise readiness „the least defined of the four priorities”, four open items, in-progress Tasks primitive) https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/
- MCPcat: MCP Server Best Practices, Production-Grade Development Guide („everything around the registration mechanism” quote on auth) https://mcpcat.io/blog/mcp-server-best-practices/
- AI Monks (Medium): Model Context Protocol (MCP) Key Limitations for Regulated Industries (SOC 2 / PCI DSS / FedRAMP absence; tool poisoning and prompt injection attack patterns) https://medium.com/aimonks/model-context-protocol-mcp-key-limitations-for-regulated-industries-fb351cfae1a1
- Hacker News: „Model Context Protocol works for tools. It breaks for agents.” (community discussion thread on agent-orchestration gap) https://news.ycombinator.com/item?id=47216789
- Model Context Protocol Official Specification (the canonical reference: JSON-RPC 2.0 transport, host/client/server architecture, tools/resources/prompts primitives, Streamable HTTP transport, SSE deprecation, June 2025 outputSchema/structuredContent additions) https://modelcontextprotocol.io/
How DataWalk AI is Transforming Investigative and Intelligence Analytics
Download the eBookFAQ
Does MCP replace orchestration frameworks like LangGraph?
No. MCP handles tool access. Orchestration frameworks handle the agent loop above it: what the agent tries next, what it remembers, how it recovers from failures. Most production agent stacks use both.
Is there a way to handle long-running operations with MCP?
MCP’s 2026 roadmap includes an experimental Tasks feature designed for operations that run longer than a single model turn. It lets a server accept a request and return a handle the agent can check later. Retry semantics and result expiry policies are still being finalized, so production teams typically supplement with their own scheduling logic for now.
How does MCP compare to Google’s A2A protocol?
MCP handles tool access (agent to tool). A2A handles coordination between agents (agent to agent). Google positioned A2A as a complement to MCP, not a replacement. Most production multi-agent stacks use both: MCP for tool access within each agent, A2A for passing work across agent boundaries.
What is contextual analytics?
Contextual analytics is the practice of analyzing data together with its surrounding business meaning, entities, relationships, history, permissions, provenance, and operational context. It helps organizations understand not only what happened, but what it is connected to, why it matters, and what action should follow.
What is data contextualization?
Data contextualization is the process of turning raw or fragmented data into meaningful, connected, reusable context. It connects records to real-world entities, relationships, definitions, permissions, provenance, and history so teams can work from a shared understanding rather than isolated tables, files, or extracts.
What is Persistent Context?
Persistent Context is reusable, governed context that survives beyond a single project. It allows new sources, workflows, investigations, applications, models, and AI initiatives to extend an existing intelligence model instead of rebuilding context from scratch.
How does DataWalk create Persistent Context?
DataWalk maps data to a flexible ontology and maintains entities, relationships, permissions, provenance, and analytical structure in one extensible intelligence model. New sources and use cases extend this model rather than creating disconnected context in separate marts, graphs, or knowledge bases.
Is DataWalk a knowledge graph?
DataWalk uses ontology and graph concepts, but it is broader than a standalone knowledge graph. It operationalizes connected context across entity resolution, search, graph analytics, investigation, scoring, workflows, applications, APIs, MCP, and AI access on one governed context layer.
Does DataWalk replace a data lake or warehouse?
No. DataWalk does not replace existing data lakes, warehouses, or source systems. It connects data from those environments and turns it into reusable context for analytics, investigations, workflows, applications, decisioning, and AI agents.
Why does Persistent Context matter for AI?
AI needs more than clean data. It needs governed context such as resolved entities, explicit relationships, permissions, provenance, definitions, and controlled analytical functions. Without this, AI systems often rely on isolated files or extracts, which leads to weak explainability, poor governance, and inconsistent answers. DataWalk provides a persistent context layer that AI agents and models can consume through APIs, MCP, and analytical functions.
DataWalk Platform
See DataWalk in action
Request a personalised live demo and discover how DataWalk connects the dots across your data.