Model Context Protocol (MCP) for enterprise: when it pays off

Last updated: July 2026

Model Context Protocol went from experimental spec (November 2024) to enterprise-default in about eighteen months. As of mid-2026, 78% of enterprise AI teams have MCP-backed agents in production, the ecosystem holds more than fourteen thousand servers, and governance has moved to the Linux Foundation's Agentic AI Foundation, co-founded by Anthropic, Block, and OpenAI with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. That is the fastest a technical protocol has crossed the enterprise threshold in recent memory. The question for a CTO in 2026 is no longer "should we look at MCP" — it is "for which of our agent surfaces does MCP pay off, and where does custom REST wiring still win." This post is the decision framework we apply. It is a cluster child of our pillar on agentic AI workflow services.

Key takeaways

• MCP pays off when the agent needs to call many tools with governance in the middle. One agent, many servers, an approval and audit layer between them. Custom REST wiring gets brittle past three or four tools; MCP normalises the shape.
• MCP does not pay off on the latency-critical path. MCP adds 600ms to 3 seconds of baseline latency. For anything real-time (checkout, fraud scoring, live conversation) keep the direct call.
• The trust boundary is the server, not the tool. A poisoned tool description can hijack an agent's behaviour across every other server it has access to. Enterprise MCP deployments require a registry, a review gate, and per-server allowlists.
• OAuth 2.1 is the auth default. Dynamic Client Registration, Protected Resource Metadata, Resource Indicators — the 2026 spec raises the bar beyond conventional web login. If your identity stack does not do OAuth 2.1 yet, MCP forces you to fix that first.
• Registry and observability are inseparable from the protocol. The Linux Foundation registry is not a nice-to-have; it is what makes an enterprise MCP deployment auditable. Every tool call needs to be logged with parameters, identity, and result hashes.

What MCP actually is (in one paragraph)

MCP is a protocol that standardises how an agent calls tools that live outside its own process. The agent (the "client") talks to one or more servers, each of which exposes a set of tools with typed inputs, typed outputs, and metadata. The wire format is JSON-RPC; the transport is either standard input/output (for local servers) or HTTP with Server-Sent Events (for remote servers). What it replaces is the pattern where every agent stack invented its own tool-calling convention against a hand-wired set of internal REST endpoints. What it does not replace is the underlying APIs — MCP servers wrap existing APIs; they do not become them.

The three deployment shapes

Enterprise MCP deployments settle into three shapes. Each has different economics.

Intelligence layer. MCP servers sit adjacent to critical paths. The agent uses them to read state, summarise, plan — but the actual write or transactional call goes through the classical, low-latency path. This is where MCP pays off most reliably. The latency cost of MCP does not sit on the customer-facing action, and the observability and governance benefit sit on every read.

Sidecar. MCP wraps a specific system (a data warehouse, a ticketing system, a CI pipeline) and exposes it to any agent that needs it. One team owns the server, many teams consume it. This is the shape that generalises fastest inside an enterprise — the Cloudflare directory of 13 remote servers, Anthropic's directory of 200-plus Custom Connectors, and the GitHub/Stripe/Notion/Linear vendor-operated servers are all sidecar shapes at the vendor level.

Batch. MCP for offline, high-volume, non-latency-sensitive work. Overnight reconciliation, weekly reporting, bulk enrichment. The latency cost does not matter; the write governance and audit trail do.

The pattern that fails, consistently, is putting MCP on the synchronous, customer-facing hot path. The 600ms-3s baseline shows up as a support ticket. Every enterprise pattern that shipped successfully in 2026 keeps MCP one hop off that path.

When MCP pays off vs custom REST wiring

The economic question. Custom REST wiring is faster in a sprint. MCP pays back over a fleet.

MCP pays off when:

• The agent needs to call five or more distinct tools. Below three or four, custom wiring is quick and clean. Above that, the ceremony of maintaining tool schemas, authentication, retries, and cost tracking per tool starts to dominate the delivery cost. MCP standardises the shape, which lets one governance layer sit on all of them.
• Multiple agents will call the same tool. Sidecar pattern. Write the server once, consume it from every agent that needs the capability. Without MCP, every agent invents its own client for that endpoint.
• You need auditable governance on the tool layer. Regulated industries. Any workload where the audit says "prove which agent called which tool with which arguments and what the result was." MCP servers make this a first-class thing to instrument; custom wiring makes it a per-endpoint retrofit.
• The vendor already ships an MCP server. GitHub, Stripe, Cloudflare, Linear, Notion, Atlassian — the vendor-shipped servers are typically better maintained than a hand-rolled client for the same API. Consuming the official server is usually the winning move.

MCP does not pay off when:

• The agent calls one internal endpoint. Direct call. The MCP layer adds latency and complexity for no fleet benefit.
• The path is latency-critical. Anything under a second of round-trip budget. Keep the direct call and use MCP for observability only.
• The workload is a single-agent, single-team artefact. No fleet, no governance surface. Wrapping it in MCP is protocol overhead that never pays back.

The trust boundary — where every enterprise deployment gets it wrong

The single most-misunderstood property of MCP: the trust boundary is the server, not the tool. A malicious or compromised MCP server can serve tool descriptions that hijack the agent's behaviour on subsequent tool calls — including calls to other, unrelated servers the same agent has access to. Invariant Labs demonstrated a scenario where a poisoned tool description silently exfiltrated a user's message history through an apparently benign tool invocation.

The implication for enterprise deployment. Every MCP server the agent can talk to has to be a server the enterprise trusts. Not the vendor's marketing page — the actual code, the actual hosting, the actual update path. That means three surfaces:

A registry. The Linux Foundation registry gives public servers signed metadata and version tracking, but enterprises need a private registry for their own servers plus an approval gate for public ones they consume. No agent connects to a server that is not on the enterprise registry.

A review process for third-party servers. Before a public MCP server hits the agent's allowed-servers list, someone has read the code, checked the update mechanism, and verified the identity of who ships it. This is the same review that already exists for third-party libraries in most enterprises. The bar for MCP servers has to be at least that high.

Per-server allowlists at the agent level. A given agent has access to a specific list of servers, not "any server the platform offers." Cross-server prompt injection is a real failure mode; the mitigation is scope reduction. This surface lives in the production agent governance reference and gets exercised on every MCP-backed workload.

The auth and identity story

The 2026 MCP spec settles authentication on OAuth 2.1. What that means practically for the enterprise:

Dynamic Client Registration. MCP clients register with the authorization server at runtime. The enterprise's identity provider has to support DCR; if it does not, this becomes the blocking work.

Protected Resource Metadata. The client discovers the authorization server from the resource server's own metadata. This makes the wiring lighter but also means the metadata itself becomes a trust surface — the discovery endpoint has to be authenticated.

Resource Indicators. Tokens are bound to a single resource server and cannot be replayed elsewhere. This is what stops a token issued for the ticketing MCP server from being usable against the finance MCP server.

Session-scoped authorization. For write actions, the emerging pattern is a session-scoped token that expires when the human-defined session ends. The agent cannot renew the session on its own; a human explicitly approves a new session. This is the mechanism that lets an enterprise say "yes, agents can write to production" without giving them permanent write credentials.

For enterprises whose identity stack still lives in older SAML-and-basic-auth territory, MCP forces a modernisation conversation. That conversation is a Phase 1 architecture item, not a Phase 3 surprise.

Observability is not optional

Every enterprise MCP deployment we have seen ship successfully in 2026 has full trace-level observability on every tool call. The parameters, the identity of the calling agent, the identity of the human on whose behalf it acts, the result, and (where feasible) a cryptographic hash of the response. This is the OpenTelemetry GenAI pattern from our observability post applied to MCP specifically — execute_tool spans with MCP-specific attributes, the protocol got its own trace layer in the 2026 spec.

The reason this matters is not just debugging. Between January and February 2026 alone, security researchers filed more than thirty CVEs targeting MCP servers, clients, and infrastructure components. The highest-severity finding scored 9.6 on CVSS. Trace-level observability is what lets an enterprise say, after an incident, exactly which agents ran which tools and what they returned. Without it, incident response on an MCP-related issue is a forensic archaeology exercise.

The pattern for shipping MCP into an enterprise

The sequence we run when an enterprise adopts MCP for the first time:

Phase 1 — Identity modernisation. OAuth 2.1 support in the enterprise IdP. Dynamic Client Registration. Resource Indicators enforced. If this is already there, this phase is a review; if not, it is the biggest single piece of preparatory work.

Phase 2 — Registry and review gate. Stand up the private registry. Define the review criteria for both internal and third-party servers. Assign the review owner. No server connects to an agent until this is running.

Phase 3 — First sidecar server. Pick one internal system with high agent demand and expose it as an MCP server. Typically the ticketing system, the code repository, or the data warehouse. Ship the server, ship the observability, ship the review.

Phase 4 — Fleet the pattern. Add servers to the registry. Add agents that consume them. The economics of MCP show up here — a new agent that needs the ticketing system reuses the sidecar server, not a new client. The governance layer already exists; the new agent inherits it.

Phase 5 — Public server consumption. With the review gate mature, begin consuming public servers from the Linux Foundation registry. GitHub, Stripe, Cloudflare — the ones where the vendor operates the server and the enterprise's job is trust review, not implementation.

Phases 1 and 2 are what stop MCP from becoming a security incident later. The temptation is to skip them and go straight to Phase 3 because the sidecar shows the fastest value. That temptation is what created the 2026 CVE surge.

The decision, in one sentence

MCP pays off when you need one governance layer over many tool calls and can afford the latency to get it. When either half of that sentence is false, keep the direct call. Everything else in the enterprise MCP conversation — the registry, the OAuth 2.1 stack, the observability, the review gate — flows from getting that decision right.