The Model Context Protocol: A Strategic Reference for Technical Leaders

I get asked about the Model Context Protocol more than almost anything else right now, and the questions have changed. A year ago it was “what is this?” Today it’s “how fast should we adopt it, and how badly can it bite us?” Both are the right questions. This is the reference I wish I could hand people when they ask — written for the CTOs, architects, and senior engineers making the call, not as a step-by-step tutorial.

The short version: MCP is an open standard, introduced by Anthropic in November 2024, that defines a single consistent way for AI applications to connect to external tools, data, and systems — so any MCP-compatible client can use any MCP server without bespoke integration code. It’s a wire protocol (JSON-RPC 2.0) plus an architecture. The analogy everyone reaches for is “USB-C for AI”: one connector standard replacing a tangle of proprietary cables. And as of mid-2026 it has crossed the line from single-vendor experiment to vendor-neutral critical infrastructure — governed under the Linux Foundation, supported by every major AI provider, and the de facto integration layer for agentic systems.

That last point is why I think it’s worth your attention as a strategic decision rather than a tooling footnote. Let me walk through what it actually is, then where I’d put it in your architecture.

Why MCP exists: the N×M integration problem

Before MCP, every connection between an AI application and an external system was a bespoke integration. If you had M AI applications (Claude, ChatGPT, a custom internal agent, an IDE assistant) and N systems to connect to (GitHub, Postgres, Slack, your internal CRM), you faced up to M×N separate integrations to build and maintain — each with its own auth, schema, and failure modes. This is the same combinatorial explosion earlier protocols solved in their own domains; the Language Server Protocol (LSP) for editor/language tooling is the canonical precedent, and MCP deliberately reuses LSP’s message-flow ideas.

MCP collapses M×N into M+N. Each AI application implements the client side once; each system exposes a server once. Any client can then talk to any server. For an enterprise with a growing portfolio of AI surfaces and a growing portfolio of internal systems, that shift from multiplicative to additive integration cost is the entire strategic argument — and in my experience it’s the part that actually lands with a CFO.

The architecture: hosts, clients, servers

MCP is a client-server architecture with three precisely defined participants. Getting the terminology right matters, because “server” in MCP does not mean what most infrastructure people assume.

• MCP Host — the AI application that coordinates one or more MCP clients. Examples: Claude Desktop, Claude Code, Visual Studio Code, ChatGPT.
• MCP Client — a component inside the host that maintains a dedicated 1:1 connection to a single server and pulls context from it for the host to use.
• MCP Server — a program that provides context (tools, resources, prompts). Per the official docs, “MCP server refers to the program that serves context data, regardless of where it runs.” It can run locally on the same machine or remotely as a hosted web service.

The host creates one client per server. So VS Code acting as a host instantiates one client object for its connection to a local filesystem server, and a separate client object for its connection to a remote error-tracking server.

Two layers: data and transport

The spec splits MCP into two layers, and that separation is the source of most of its flexibility.

The data layer is the inner layer: a JSON-RPC 2.0 protocol defining lifecycle management (capability negotiation via an initialize handshake) and the core primitives. The transport layer is the outer layer: the mechanism that actually moves the messages, plus connection establishment, framing, and authorization. Because they’re decoupled, you write your tool logic once and expose it over whichever transport suits your deployment.

The primitives

Servers expose three primitives:

• Tools — executable functions the AI can invoke (API calls, database queries, file operations).
• Resources — data sources providing context (file contents, database records, API responses).
• Prompts — reusable templates that structure model interactions.

Clients can expose primitives back to servers, which is where the richer interactions live:

• Sampling — a server can ask the host for an LLM completion, so server authors stay model-independent.
• Elicitation — a server can request additional information or confirmation from the user mid-flow.
• Logging — a server can send log messages to the client.

The 2025-11-25 revision also added an experimental Tasks primitive — durable wrappers for long-running requests with polling and deferred result retrieval, which pushes MCP beyond purely synchronous tool calls.

Transports: stdio and Streamable HTTP

The current stable spec defines two official transports. Choosing between them is a deployment decision, not a capability decision.

One point of confusion worth resolving in any architecture review: the older HTTP+SSE transport (two separate endpoints, from the 2024-11-05 spec) is deprecated, replaced by Streamable HTTP from 2025-03-26 onward. New builds should default to Streamable HTTP for remote scenarios and only keep the legacy SSE endpoints alive for backwards compatibility with old clients. A common production shape is a gateway: a local stdio server handles local resources while routing upstream to remote Streamable HTTP servers. WebSocket transport has been discussed but isn’t part of the official set — the maintainers have said they’re “not adding more official transports this cycle.”

MCP vs traditional API integration

If you’re weighing whether MCP earns a place in your standard architecture, the comparison that matters is against the status quo: bespoke API clients and function-calling glue.

MCP is not a replacement for REST or gRPC between conventional services. It’s a layer designed specifically for AI-application-to-tool interaction, where the “client” is an LLM-driven agent that has to discover and reason about available capabilities at runtime. Don’t rip out your service mesh for it.

MCP vs agent-to-agent protocols (A2A)

A question I now field in nearly every architecture conversation is MCP versus A2A — the Agent2Agent protocol, announced by Google in April 2025 and also now under the Linux Foundation’s agentic umbrella. These are complementary, not competing.

The clean mental model: MCP connects agents to tools; A2A connects agents to each other. A travel-planning agent uses A2A to delegate to a flight-booking agent, and each of those agents internally uses MCP to call its own tools and APIs. Most non-trivial production systems will use both.

The security picture: please don’t skip this

I’ll be blunt here, because the upside is genuine but so is the security surface — and a credible treatment has to be honest about it. The protocol’s core design — loading server-provided tool descriptions straight into the model’s operational context — is also its primary attack vector. Several distinct, documented threat classes exist:

• Tool poisoning / indirect prompt injection. Malicious instructions embedded in tool metadata (descriptions, parameters) rather than user input. Because the spec doesn’t require clients to validate server-provided metadata, most accept it uncritically. The Queen’s University study “MCP at First Glance” (arXiv:2506.13538) found that across its sample, 7.2% of servers contained general vulnerabilities and 5.5% exhibited MCP-specific tool poisoning (detected via Invariant Labs’ scanner). One sample, not a census — but indicative.
• The “rug pull” / silent redefinition. A tool can mutate its own definition after you’ve approved it. CVE-2025-54136 (“MCPoison,” found by Check Point) demonstrated exactly this against config files: commit a benign config, get it approved once, then swap the payload.
• Confused deputy attacks. An agent with legitimately granted privileges is manipulated into using them on someone else’s behalf. Access controls don’t protect you within the scope of a legitimate grant — an analytics agent with query access can be injected into running a query it shouldn’t, because the grant doesn’t constrain the query.
• Cross-server exfiltration. With multiple servers sharing the model’s context, a malicious server can intercept or override calls meant for a trusted one. 2025 saw real proof-of-concept exploits, including extraction of a full message history and private-repository data exfiltration through a popular code-hosting MCP server.
• Command injection / RCE. CVE-2025-6514 enabled remote code execution on client machines via server configuration; CVE-2025-49596 covered an authentication gap in the MCP Inspector proxy.

The consensus in the security community — articulated bluntly by Simon Willison and echoed by OWASP’s work on the convergence of prompt injection, supply-chain risk, and confused-deputy failures — is that MCP security is an architectural concern; it can’t be bolted on after deployment. The mitigations are maturing fast: the 2025-11-25 revision introduced a much stronger authorization model (OAuth 2.1, OpenID Connect Discovery, Client ID Metadata Documents replacing dynamic client registration, incremental scope consent). But my practical guidance hasn’t changed: treat any MCP server with shell or credential access as tier-0 supply chain, vet servers the way you vet dependencies, scope credentials tightly, run a gateway with audit logging, and keep humans in the loop for high-impact actions.

Where MCP sits in 2026: standard, governance, adoption

The trajectory is the strongest signal of MCP’s strategic durability. Anthropic open-sourced it in November 2024. OpenAI adopted it across its Agents SDK, Responses API, and ChatGPT desktop in March 2025 — a genuine inflection point, because a primary competitor adopting a rival’s standard signals “infrastructure,” not “competitive advantage.” Microsoft shipped it across Copilot; Google adopted it via Gemini; AWS added MCP-compatible tooling.

On 9 December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. For enterprise risk assessment, this answered the one outstanding concern — vendor lock-in. The governing board controls strategic investment and budget, while MCP keeps full autonomy over its technical direction, with decisions still made by the existing maintainers through a public proposal process.

Adoption at the one-year mark, per Anthropic’s December 2025 figures: over 97 million monthly SDK downloads (combined Python and TypeScript), around 10,000 active servers, and first-class client support across ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and VS Code.

On the spec itself: the current stable revision as I write this is 2025-11-25. A large release candidate, 2026-07-28, was locked in late May 2026 and is scheduled to finalise on 28 July 2026 — described by the maintainers as the biggest revision since launch: it makes the protocol stateless at the protocol layer, promotes Tasks and MCP Apps to first-class extensions, and hardens authorization. If you’re planning 2026 builds, design against 2025-11-25 but track the RC’s breaking changes — notably the removal of the initialize handshake and session IDs, and the migration path for the experimental Tasks API.

Where I’d put MCP in your strategy

For a technical leader, the decision is rarely “should we use MCP” in the abstract. It’s where MCP sits in three concrete decisions.

1. Build vs buy for tool integration. MCP shifts the economics decisively toward “adopt the standard, build only the servers you uniquely need.” Building bespoke connectors for each AI surface is now the expensive, legacy path. The pragmatic posture: adopt MCP as the integration contract, consume existing community/vendor servers for commodity systems (code hosting, chat, observability), and build custom servers only for your proprietary systems — where you’d have had to build something anyway. (I’ve written separately on the wider build-vs-buy framework this slots into.)

2. Centralised governance via a gateway. Don’t let teams wire agents directly to arbitrary MCP servers. The enterprise pattern emerging across vendors is a governed control plane: a vetted server registry, scoped credentials, OAuth-based auth, audit logging, and cost controls, ideally inside your own network boundary. This is where the 2025-11-25 OAuth model and the 2026 roadmap’s audit-trail and enterprise-managed-auth items become procurement criteria.

3. Avoiding new lock-in. Linux Foundation governance materially de-risks MCP as a standard. But lock-in can re-enter through vendor-specific gateway platforms. Favour portable, open implementations and treat your MCP server catalogue as a first-class, version-controlled asset.

The adoption stance I’d recommend

• Now (low regret): standardise on MCP as the integration contract for internal AI tooling. Pilot with one narrow, high-value use case rather than connecting everything at once.
• Before production: stand up an MCP gateway with auth, allow-listing, and audit logging. Treat servers as supply-chain dependencies with review and version pinning.
• Track: the 2026-07-28 final spec (stateless core, extensions, MCP Apps) and its breaking changes; plan SDK upgrades accordingly.

MCP isn’t speculative any more. For anyone building agentic systems, the strategic question has shifted from “if” to “how safely and how fast” — and my answer is to adopt the standard, govern it centrally, and treat its still-maturing security model with the scepticism it deserves.

---

For the interactive, diagram-led version of this — the client-server model and the N×M maths as visual explainers — see the MCP strategy insight. For the orchestration layer that sits on top, see agentic AI patterns.