New MCP Server: Your Agents Get a Badge, Not a Master Key

Read More

What is MCP? The Model Context Protocol Explained

 
 

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.

MCPFunction callingREST APIRAG
What it isOpen protocol for an AI app to discover and invoke external toolsLLM provider feature that lets a model emit a structured tool-call requestContract for software-to-software requests, usually over HTTPRetrieval pattern that feeds source documents into a prompt before generation
What it standardizesTool discovery, invocation, transport, and session between client and serverThe shape of the model's tool-call output, inside one provider's APIRequest and response format between caller and serviceNothing. It is a pattern, not a protocol
Primary consumerAny MCP-compatible AI client (Claude Desktop, Cursor, ChatGPT)The LLM provider's SDK and the app embedding itA developer writing application codeA 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 whenYou want tools written once to work across multiple AI clients and providersYou want one LLM to call a fixed set of in-process tools in your own appYou are integrating software with software, no LLM in the loopThe 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.,

CUSTOMER CASE STUDY

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


Download free ebook
"How DataWalk AI is Transforming Investigative
and Intelligence Analytics


Download the eBook

FAQ

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.
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.
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.
 

Join the next generation of data-driven investigations:
Discover how your team can turn complexity into clarity fast.

 
Get A Free Demo