Model Context Protocol (MCP) is the open standard for connecting AI assistants and agents to the tools, data sources, and services they need to do real work. Anthropic introduced it in November 2024 as a way to standardize how LLM-based assistants discover and call tools without every host application reinventing the integration layer from scratch. Eighteen months later, MCP has crossed from "Anthropic-led proposal" to "industry-default standard": 78% of enterprise AI teams reported at least one MCP-backed agent in production in April 2026, and the protocol’s SDK reached 97 million monthly downloads (faster adoption than React’s first three years) per Digital Applied’s 2026 adoption tracker.
This post covers what MCP actually is, how the architecture works, the 2025–2026 adoption arc that made it the industry standard, where it fits in the agent stack (especially next to the A2A protocol covered in our Copilot Studio recap), the operational growing pains the protocol is now working through, and what this means for organizations deciding how to wire AI agents into their tool ecosystem. For background on the agents that consume MCP, see our AI Agents practitioner’s guide; for the framework layer, our AI agent frameworks comparison.
What Model Context Protocol actually is
MCP is a JSON-RPC-based open protocol that defines how an AI host application (an assistant, a chat client, an IDE, an agent runtime) talks to external systems that provide capabilities. The protocol standardizes three things:
- Tools: functions the AI can call (read a file, query a database, send an email, list calendar events). The host enumerates available tools at connect time; the AI decides which to call and with what arguments at runtime.
- Resources: data the AI can read (file contents, API responses, database query results). Resources are addressable by URI and can be subscribed to for change notifications.
- Prompts: reusable prompt templates that the host can offer the user as quick actions. Less commonly used than tools and resources but part of the standard.
A working MCP system has two halves: an MCP host (Claude Desktop, ChatGPT, Cursor, Copilot Studio, custom agents) and one or more MCP servers (a GitHub server, a Postgres server, a Slack server, a Google Drive server). The host connects to whatever servers the user authorizes; the servers expose tools and resources; the AI inside the host can then call those tools and read those resources as part of its work.
The mental model that helps most operators: USB-C for AI. Before USB-C, every peripheral needed a custom cable. After USB-C, any compatible device works with any compatible host. MCP is doing the same thing for AI-to-tool connections.
How MCP works (the architecture)
The protocol layer is JSON-RPC 2.0 over a transport. The original transports were stdio (the MCP server runs as a local subprocess) and Server-Sent Events (the MCP server runs as a remote HTTP service). The 2026 roadmap, published on the official MCP blog, formalizes streamable HTTP as the production transport and standardizes patterns for scaling to high-concurrency deployments.
The connection lifecycle is straightforward. The host starts; the user (or an admin policy) authorizes one or more MCP servers; the host opens a JSON-RPC session with each server; the server announces its capabilities (tools, resources, prompts) via a handshake; the host adds those capabilities to the LLM’s available toolset; the LLM calls tools at inference time; results flow back to the LLM as part of the next reasoning step.
Authentication and authorization were the most underspecified parts of the original protocol and the area where the 2026 roadmap is investing most heavily. The current pattern uses OAuth 2.0 with PKCE for web-hosted servers and bearer tokens or local credentials for stdio servers. Enterprise deployments add SSO integration (typically via the host’s identity layer) and per-tool policy enforcement.
The protocol is deliberately simple. The full specification fits in a few dozen pages. The simplicity is the point: a small, stable surface area is what made it adoptable across competing AI vendors. Complexity lives in individual MCP servers, not in the protocol itself.
The 2025–2026 adoption arc
The adoption timeline is the most consequential thing to understand about MCP, because the speed of the adoption arc is what makes "MCP support" a default expectation rather than a differentiator.
- November 2024: Anthropic publishes MCP as an open standard alongside reference implementations in Python and TypeScript. Initial momentum is concentrated in the Claude Desktop user base and a handful of early developer-tool integrations.
- Q1–Q2 2025: open-source server ecosystem grows quickly. Community-built MCP servers ship for Postgres, MySQL, Slack, GitHub, Google Drive, Notion, Linear, and dozens of other commonly-used systems.
- Q2 2025: OpenAI adds MCP support to ChatGPT through the Apps SDK and Connectors, signaling that the protocol’s reach is no longer Anthropic-specific.
- Q3 2025: Microsoft ships MCP servers for GitHub (which Microsoft owns), Azure, Microsoft Teams, and the broader Microsoft 365 surface. Microsoft Copilot Studio gains MCP-server-enabled tools in preview.
- December 2025: governance moves from Anthropic to the Linux Foundation. The protocol now has neutral stewardship suitable for adoption by competing vendors.
- Q1 2026: Google adds MCP support to the Gemini API and Vertex AI Agent Builder. With Anthropic, OpenAI, Microsoft, and Google all supporting the same standard, MCP becomes the default agent-integration protocol industry-wide.
- April 2026: 78% of enterprise AI teams report at least one MCP-backed agent in production. 67% of CTOs surveyed name MCP as their default agent-integration standard within 12 months. SDK downloads cross 97 million per month. The public MCP server ecosystem grows past 5,800 servers.
Per The New Stack’s coverage of the 2026 roadmap, the protocol’s adoption curve reached the React-comparable scale (97 million monthly downloads) in 16 months. React took roughly three years to reach the same milestone. The MCP curve is one of the fastest standards-adoption arcs in recent software history.
Where MCP fits in the agent stack
MCP and the Agent-to-Agent protocol (A2A) are complementary, not competing. The shorthand:
- MCP: how an AI host talks to external tools and data. “Agent to tool” communication.
- A2A: how AI agents talk to each other. “Agent to agent” communication, used for multi-agent orchestration across vendor and platform boundaries (covered in our Copilot Studio recap).
A mature production multi-agent system in 2026 typically uses both. Agents communicate with each other via A2A. Each agent uses MCP to reach the tools and data it needs to do its work. The two protocols evolved separately (MCP from Anthropic, A2A from a consortium initially led by Google) but ship together in most enterprise agent platforms.
The alternative to MCP was custom integration: every host application implementing its own way of calling GitHub, its own way of calling Postgres, its own way of calling Slack. That approach scaled badly across the vendor market: a tool maker who wanted to be reachable by Claude, ChatGPT, Cursor, and Copilot had to build four integrations. MCP collapses that to one. The tool maker writes one MCP server; every MCP-compatible host can use it.
This is also why the major AI vendors all adopted MCP rather than promoting competing standards: the alternative was each vendor maintaining its own integration ecosystem in parallel, which is operationally expensive and limits the universe of tools the AI can reach. A common standard creates a larger usable ecosystem for everyone, even competitors.
What MCP solves that custom integration didn’t
Three things changed when MCP became the default integration layer:
Tool portability. A workflow that works in Claude Desktop today can move to ChatGPT tomorrow without rewriting the tool integrations. The tools are MCP servers; the host is interchangeable. This breaks one of the major lock-in patterns AI vendors used to depend on.
Ecosystem network effects. Each new MCP server makes every MCP host more capable; each new MCP host makes every MCP server more valuable. The two-sided network effect kicked in around mid-2025 and is what drove the adoption acceleration.
Predictable security surface. Every MCP server exposes capabilities through the same structured interface. Security review is once-per-protocol rather than once-per-vendor-integration. Per-tool policy enforcement at the host level becomes tractable because the policy points are standardized.
The cost of the standardization is real but smaller than the benefits: MCP imposes a JSON-RPC surface that’s slightly heavier than a hand-rolled HTTP API for trivial integrations, and the protocol’s authentication story is still maturing (the 2026 roadmap names this as a top priority).
The growing pains in 2026
The 2026 MCP roadmap, published in early 2026, names four operational gaps that enterprise adopters keep hitting:
- Audit trails: enterprises need durable, tamper-evident logs of every tool invocation. The protocol surface doesn’t fully cover this; vendors are layering audit on top, but a standard audit-event format is on the 2026 roadmap.
- SSO-integrated auth: the OAuth 2.0 + PKCE pattern works for individual users but requires more standardization for enterprise SSO integration patterns.
- Gateway behavior: large enterprises want a single MCP gateway in front of multiple MCP servers, with centralized policy and audit. The gateway pattern exists today but isn’t standardized.
- Configuration portability: moving an MCP host’s configuration (which servers, which auth, which policies) between environments (dev to prod, on-prem to cloud) is harder than it should be.
CData’s analysis of enterprise MCP readiness frames 2026 as the year the protocol’s operational gaps close, not the year adoption begins. Adoption is already broad; what 2026 brings is the maturity that makes large-scale enterprise deployment less custom-glue-intensive.
What this means for organizations
For organizations building or evaluating AI integration in mid-2026:
Treat MCP support as a baseline requirement. Any AI vendor proposing an integration platform that doesn’t support MCP is asking you to bet against the industry default. Adoption breadth is already past the point where MCP support is optional.
Map your tool inventory to existing MCP servers first. Before building custom MCP servers, check the public MCP server ecosystem (5,800+ servers and growing). Many of the integrations your AI agents need probably already exist as a community or vendor-maintained MCP server.
Plan the auth and audit posture early. The 2026 roadmap will close the protocol-level gaps in SSO, audit, and gateway patterns, but your tenant-level governance work needs to start now. Microsoft’s Agent 365 is one example of a tenant-level governance layer that wraps MCP-aware agents.
Pick an MCP-capable host that matches your work pattern. Claude Desktop, ChatGPT, Cursor, Copilot Studio, custom agents on LangGraph or the OpenAI Agents SDK all support MCP at this point. The host choice depends on the work pattern more than on whether MCP is supported (it is, in all serious 2026 options).
For deeper context on the agent platforms that consume MCP, our Microsoft Copilot Studio April 2026 recap and AI agent frameworks comparison cover the major options.
Frequently Asked Questions
Who created the Model Context Protocol?
Anthropic introduced MCP as an open standard in November 2024, with the initial Python and TypeScript SDK implementations released alongside the protocol specification. Governance moved to the Linux Foundation in December 2025, making MCP a neutrally-stewarded open standard rather than an Anthropic-controlled one. The protocol is now jointly supported by Anthropic, OpenAI, Microsoft, and Google, among others.
What’s the difference between MCP and A2A protocol?
MCP handles “agent to tool” communication: how an AI assistant or agent talks to external systems (databases, APIs, files, services) to do work. A2A (Agent-to-Agent) handles “agent to agent” communication: how multiple AI agents coordinate with each other across vendor and platform boundaries. The two protocols are complementary. A typical 2026 production multi-agent system uses both: agents talk to each other via A2A; each agent uses MCP to reach its tools.
Is MCP open source?
Yes. The protocol specification and reference SDK implementations are open source. The Linux Foundation has governed MCP since December 2025, ensuring vendor-neutral stewardship. The 5,800+ public MCP servers in the ecosystem include both open-source community servers and commercial vendor-maintained servers; the protocol itself is unambiguously open.
Do I need a developer to build an MCP server for my company’s tools?
For custom internal systems, yes: building an MCP server is a developer task. The SDKs (Python, TypeScript, and increasingly others) make it relatively quick (a competent developer can build a working MCP server for a typical REST API in a few hours), but it’s still developer work. For common third-party tools (GitHub, Postgres, Slack, Google Drive, Notion, Linear, Salesforce, and many more), well-maintained MCP servers already exist. Always check the public ecosystem before building custom.
How does MCP relate to OpenAI’s plugin system or Microsoft’s Power Platform connectors?
OpenAI’s older plugin system (largely deprecated in favor of the Apps SDK) and Microsoft’s Power Platform connectors were vendor-specific integration mechanisms that predated MCP. Both vendors now support MCP as the industry-standard alternative. Existing OpenAI Apps and Power Platform connectors continue to work but new integration work increasingly defaults to MCP for portability across hosts. The pattern is similar to the shift from vendor-specific browser APIs to W3C web standards: the older vendor-specific paths still work but the standard is where new investment lands.
