Everything your team needs to know about MCP in 2026

Architecture, auth, ecosystem, and the 2026 roadmap for the protocol that connects AI to everything.

The Model Context Protocol (MCP) is an open standard that gives AI models a universal way to connect to external tools, data sources, and services. Anthropic introduced it in November 2024, and it has since become the de facto protocol for connecting AI to the real world, adopted by OpenAI, Google DeepMind, Microsoft, and thousands of development teams. The Python and TypeScript SDKs alone see roughly 97 million monthly downloads. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, making it a vendor-neutral, community-governed standard.

This article covers everything your team needs to evaluate, adopt, and build with MCP: how the protocol works as a complete system, how authentication has evolved, where the ecosystem stands, what the 2026 roadmap prioritizes, and where the real gaps remain.

Why MCP exists

Before MCP, every AI application that needed to talk to an external system had to build its own custom connector. Want Claude to access Google Drive? Build a custom integration. Want ChatGPT to query your Postgres database? Build another one. Want Cursor to read your Jira tickets? That's yet another bespoke connector.

This is the N×M problem. If you have N AI applications and M tools or data sources, you need N × M custom integrations. Each one has its own authentication approach, its own data format, its own error handling. Fragile, expensive, and impossible to scale.

MCP eliminates this by defining a single protocol that any AI application can use to talk to any tool. Build an MCP server once, and every MCP-compatible client (Claude, ChatGPT, Gemini, Cursor, VS Code, a custom agent) can use it. The integration count drops from N × M to N + M. That isn't just a developer convenience; it's the difference between an ecosystem that compounds and one that fragments.

How MCP works today

MCP is built around three roles.

• The host is the AI application the user interacts with: Claude Desktop, Cursor, ChatGPT, or a custom app.
• The client lives inside the host and manages connections to MCP servers. Each client maintains a one-to-one relationship with a single server, but a host can run many clients simultaneously.
• The server exposes capabilities to the AI through the protocol.

When the user makes a request:

1. The AI model inside the host decides which tools to invoke and with what parameters.
2. The appropriate client routes the request to the right server.
3. The server executes the action against its underlying system (an API, a database, a SaaS platform) and returns the result.
4. The model incorporates that result into its response.

A single user request can involve multiple servers working in concert. Ask your AI assistant to "summarize the Slack discussion about the Q3 roadmap and create a Linear ticket for the top action item," and the host routes requests to both a Slack and a Linear server, composing the results seamlessly.

What servers expose

MCP servers present their capabilities through three primitives:

• Tools are actions the AI can take: send a message, create a record, run a query, trigger a deployment. Tools are the write side of MCP. The user can approve or deny tool calls depending on the host's configuration.
• Resources are data the AI can read: files, database rows, API responses, documents. Resources are the read side of MCP.
• Prompts are reusable templates that guide the AI's behavior for specific tasks, helping standardize how it interacts with a particular domain.

MCP is not a replacement for APIs . Your existing APIs still do the work. MCP is the protocol layer that gives AI a standardized way to discover and use them.

Transport

MCP supports two transport mechanisms.

• The stdio transport runs servers as local subprocesses of the host, communicating through standard input/output. This is the simplest setup and works well for desktop applications and development tools.
• Streamable HTTP supports remote servers deployed anywhere on the internet, using standard HTTP and Server-Sent Events for real-time streaming.

Connections are stateful. Unlike REST APIs, the client and server maintain a session, so the server can remember context across multiple requests within a workflow. This matters for multi-step operations like database transactions or multi-file code refactoring.

The wire format is JSON-RPC 2.0, the same lightweight protocol used in many developer tools.

Async tasks

Not every operation completes in milliseconds. Before tasks, MCP requests were synchronous: the client calls a tool, blocks, and waits. That model breaks for anything that takes more than a few seconds.

Tasks introduce a "call-now, fetch-later" pattern. Any request can return a task handle immediately while the real work continues in the background. Clients can poll or subscribe for progress updates. Tasks move through defined states (working, input_required, completed, failed, cancelled), giving agents and users visibility into long-running operations like ETL jobs, large file conversions, or multi-step provisioning.

Sampling and elicitation

MCP's original design was strictly one-directional: the model calls, the server answers. The current spec introduces collaboration patterns that let servers participate more actively in workflows.

• Sampling allows servers to request completions from the AI model during execution. Instead of the model unilaterally deciding everything, a server can ask the model to reason about intermediate state, validate assumptions, or generate content as part of a multi-step process. The user can review and edit sampled output before it goes back to the server, keeping humans in the loop for accuracy-sensitive workflows.
• Elicitation lets servers pause execution and request input from the user. URL-mode elicitation handles interactions that must happen outside the MCP client for security reasons: OAuth flows, credential entry, payment setup.

These patterns shift MCP from a pure command-execution protocol to something closer to a collaboration framework. Servers are no longer passive; they can think (via sampling), ask questions (via elicitation), and coordinate multi-step work (via tasks).

Server-side agent loops

Servers can include tool definitions in sampling requests, specify tool choice behavior, and implement multi-step reasoning internally. A research server can spawn agents, coordinate their work, and deliver a coherent result using standard MCP primitives, without custom orchestration code.

MCP Apps: the UI layer

Until January 2026, every MCP interaction was text-based. MCP Apps changed that by extending the protocol into interactive user interfaces. Tools can now return rich HTML interfaces that render in sandboxed iframes within the chat experience.

How MCP got here

MCP's adoption arc has been remarkably fast.

November 2024. Anthropic open-sources MCP. At launch, it's primarily a developer tool for improving AI-assisted coding.

March 2025. The spec launches its second version, introducing Streamable HTTP and OAuth 2.1. And OpenAI announces full MCP support across the Agents SDK, Responses API, and ChatGPT desktop app.

April 2025. Google DeepMind confirms MCP support for Gemini.

June 2025. The spec formalizes MCP servers as OAuth Resource Servers and mandates Resource Indicators (RFC 8707) to prevent token misuse.

September 2025. The MCP Registry launches. It grows to nearly 2,000 server entries within months.

November 2025. The 2025-11-25 spec release ships the largest set of changes since launch: async tasks, enhanced sampling, elicitation, server-side agent loops, Client ID Metadata Documents, client security requirements, and the extensions system.

December 2025. Anthropic donates MCP to the Agentic AI Foundation under the Linux Foundation. OpenAI and Block join as co-founders, with AWS, Google, Microsoft, Cloudflare, GitHub, and Bloomberg as supporting members.

January 2026. MCP Apps launches as the first official extension.

March 2026. The 2026 roadmap is published, making enterprise readiness a top priority.

Authentication and authorization

Auth is the area of MCP that has evolved the most, and it's the top concern for any organization evaluating the protocol.

How it works

For local servers running via stdio, authentication is handled by the host application's permissions. The security boundary is the user's own machine.

For remote servers, MCP specifies an OAuth 2.1 flow. The server points to an authorization server, the client goes through a consent flow, and receives scoped tokens.

How it has matured

The auth story has tightened considerably across three spec revisions.

March 2025 introduced OAuth 2.1 as the foundation, but client registration relied on Dynamic Client Registration (DCR), which required every authorization server to maintain a database of known clients.

June 2025 formalized MCP servers as OAuth Resource Servers and mandated Resource Indicators (RFC 8707). This prevents a token issued for one server from being reused to access a different server.

November 2025 shifted the default from DCR to Client ID Metadata Documents (CIMD). With CIMD, a client's identity is a URL pointing to a JSON document the client controls.

Session-scoped authorization

One emerging pattern for organizations concerned about agent access is session-scoped authorization. Rather than granting agents persistent access via long-lived OAuth tokens, access is time-limited to the duration of a specific task. When the session ends, access ends automatically. The agent cannot renew the session on its own. A human must explicitly approve a new session.

The enterprise auth gap

The 2026 roadmap acknowledges that static client secrets remain common in production and calls for paved paths toward SSO-integrated flows.

The ecosystem

Adopters

On the client side: Claude, ChatGPT, Gemini, Microsoft Copilot, GitHub Copilot, Cursor, Windsurf, VS Code, and Zed all support MCP.

On the server side: Slack, GitHub, Google, Salesforce, Stripe, HubSpot, Shopify, Notion, Linear, Sentry, Figma, Webflow, Cloudflare, Postman, WooCommerce, and many others have built official or community-maintained servers.

The registry and server discovery

The MCP Registry is the central index for discovering servers. The 2026 roadmap includes work on MCP Server Cards, a proposed standard for exposing server metadata via .well-known URLs so browsers, crawlers, and registries can discover capabilities without connecting.

Governance

MCP is governed through the Agentic AI Foundation under the Linux Foundation. Development is organized around Working Groups (Transports, Auth, Registry, and others) and Interest Groups, with changes proposed through Specification Enhancement Proposals (SEPs).

What's working and what's not

Where MCP is strong today

• Developer tooling and coding assistants. This is where MCP sees the deepest adoption.
• Single-user, interactive workflows. Asking your AI assistant to check your calendar, summarize a Slack thread, and file a ticket works reliably.
• Read-heavy integrations. MCP servers that expose data as resources are straightforward to build and deploy safely.
• Ecosystem breadth. Close to 2,000 servers in the registry, major platform adoption, and active community development.

Where the gaps are

• Enterprise observability. No standardized audit trail. Teams building production MCP deployments are inventing their own logging, tracing, and compliance infrastructure.
• Multi-tenancy. SaaS providers building MCP servers need to isolate tenant data and enforce tenant-specific policies.
• Rate limiting and cost attribution. When agents invoke tools autonomously, organizations need to cap usage and attribute costs.
• Configuration portability. Setting up an MCP server in one client means starting from scratch in another. No portable config standard exists yet.

The 2026 roadmap

The 2026 roadmap, published in March 2026, organizes development around four priority areas.

• Transport evolution
• Agent communication
• Enterprise readiness
• Governance maturation

How MCP compares

• ‍ MCP vs. regular APIs . APIs are point-to-point connections. MCP is a protocol layer on top of APIs that standardizes how AI models discover and use them.
• MCP vs. function calling. Function calling is the AI model's ability to decide to invoke a tool. MCP is the protocol that connects the model to the tool.
• MCP vs. Google's A2A . MCP standardizes how AI connects to tools and data. A2A standardizes how agents communicate with each other.
• MCP vs. IBM's ACP. ACP, developed by IBM Research for the BeeAI platform, focuses on orchestrating communication between multiple agents in a local-first environment.

MCP auth with WorkOS

The roadmap makes it clear that enterprise-managed auth is a priority, but the spec work is still ahead. If you're building MCP servers today and need to move past static client secrets now, WorkOS already solves this.