The Model Context Protocol: A Strategic Reference for Technical Leaders

The useful MCP question is not “have we adopted it?” It is “which tool interactions are we willing to standardise, and who will own the trust boundary that comes with them?”

MCP is an open JSON-RPC protocol for connecting LLM applications with tools, resources, prompts, and related capabilities. It standardises the shape of an interaction. It does not make a server trustworthy, resolve authorisation, remove an API’s business rules, or turn a half-finished integration into a production service. The official 2026-07-28 specification makes that boundary unusually clear: tool descriptions should be treated as untrusted unless they come from a trusted server, and user consent remains an application responsibility. MCP specification (opens in a new tab)

That is why MCP belongs in an architecture discussion rather than a tooling demo. The protocol can reduce repeated integration work when clients and servers genuinely need to interoperate. The operating work—identity, scopes, review, observability, cost controls, and retirement—does not disappear.

Why MCP exists: the N×M integration problem

Before a shared protocol, every AI surface can require its own connector to every system. With M clients and N systems, the theoretical integration surface can approach M×N. Each connection brings its own authentication, schema translation, failure handling, and ownership.

MCP can move some of that work towards M+N: a client implements the protocol and a system exposes a compatible server. That is a planning model, not a saving you can book in advance. Compatibility has to include the protocol revision, transport, server capability, identity model, scope, network path, and the operator who handles failure. The arithmetic explains why a standard is attractive. It does not make every connection safe or free.

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 separates the protocol contract from the transport that carries it. The data layer defines JSON-RPC messages and the core primitives. The transport layer defines connection behaviour, framing, and authorisation. In the current 2026-07-28 revision, requests are self-contained and capability information travels with each request; a client may use server/discover when it needs a catalogue before acting. That makes scaling easier, but it also means the gateway still needs to identify, authorise, meter, and observe every request. Release note (opens in a new tab)

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 current specification also defines optional extensions. Tasks is now an opt-in extension for long-running work; a client and server must both negotiate it. Do not assume that a client which supports basic tools also supports every extension you want to use.

Transports: choose for the trust boundary

Transport choice is a deployment and security decision. It changes where a server runs, how identity is established, how traffic is routed, and how an incident is contained.

The older HTTP+SSE transport is deprecated. New remote implementations should use Streamable HTTP unless a compatibility requirement says otherwise. The 2026-07-28 release gives legacy features a minimum twelve-month deprecation window, which is a reason to plan migration—not a reason to postpone an inventory of old clients. A gateway can be useful, but only if it enforces server allow-listing, token validation, request logging, rate controls, and a clear escalation path when a tool action fails.

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 an agent to tools; A2A connects agents to each other. A travel-planning agent could use A2A to delegate to a flight-booking agent, while each agent uses MCP for its own tools and APIs. Use both only where the workflow has both problems. Adding a second protocol does not create autonomy; it creates another trust and operating boundary.

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.

What is stable enough to decide in 2026

MCP is now an Agentic AI Foundation project (opens in a new tab), and the 2026-07-28 specification is current. That governance and release activity make it reasonable to evaluate as a common integration contract. They do not settle an enterprise’s risk decision.

The 2026 revision removes protocol-level sessions and the earlier initialise handshake, introduces header-based routing for Streamable HTTP, formalises extensions, and hardens authorisation flows. Those are material operational improvements. They also create migration work for clients and servers that relied on sessions or older transports. Release note (opens in a new tab)

Do not use SDK download counts, vendor logos, or a foundation affiliation as a substitute for a production decision. The decision should rest on a small number of facts: do your target clients and servers support a compatible revision; can you constrain the identity and tool scope; can you log and reverse a high-impact action; and is there an accountable owner for the server after the pilot ends?

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 versus buy for tool integration. Standardise where several clients need the same capability and the server has a clear business owner. A bespoke connector can still be the lower-risk choice for one narrow workflow, an unsupported protocol revision, or an API whose permissions cannot be constrained safely. Build an MCP server for a proprietary capability only after the tool contract, authorisation, and support commitment are explicit.

2. Govern the server estate, not just the protocol. Do not let teams connect agents to arbitrary servers. Maintain a reviewed registry; pin and review versions; issue short-lived, scoped credentials; record tool calls and outcomes; and require a human approval path for irreversible actions. The official security guidance is clear that tool metadata should be treated as untrusted unless it comes from a trusted server, and that token audience and OAuth discovery handling are security boundaries. Security guidance (opens in a new tab)

3. Price the operating model. A shared protocol can lower connector duplication while increasing the need for gateway, identity, audit, and incident-response capability. That is a trade, not a free upgrade. Treat the server catalogue as version-controlled production infrastructure, and test an exit from any gateway platform before it becomes a dependency.

The adoption stance I’d recommend

• Pilot one bounded workflow: choose a reversible task, one server, one client, and a named operator. Measure the integration effort, latency, failure rate, and review burden.
• Before production: establish a reviewed server registry, purpose-bound identity, allow-listing, audit trails, rate limits, and an approval path for irreversible actions.
• Track compatibility deliberately: inventory clients and servers against the 2026-07-28 specification and plan the migration from deprecated transports or session-dependent behaviour.

MCP is useful when it reduces a real integration problem without obscuring the trust problem. The safe posture is neither “connect everything” nor “wait for perfection”. It is to standardise a bounded interaction, prove the controls, and widen the estate only when the operating model is ready.

---

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.