Why MCP + everything else for tool integration in 2026

The MCP-everywhere argument is louder than it should be in early 2026. The protocol won. I graded the calls last month and the bet that it would become the integration layer held up cleanly. The follow-on argument that every tool integration should therefore be MCP-shaped is a category error, and it's the kind of error that produces architectures with the wrong rough edges in the wrong places.

The honest position for 2026 is MCP for the bulk of tool integration plus a small, deliberate set of escape hatches for the cases where the protocol shape genuinely doesn't fit. Not pure-MCP-everywhere; not the patchwork-of-everything that MCP was meant to replace; the disciplined middle that takes the standardization win and refuses to let the standardization become a religion.

What I argued before, restated honestly

Last October I wrote about MCP-only agent architectures and made the case that the discipline pays back, cleaner runtime, smaller lock-in surface, uniform observability. That piece holds up for the cases it covered, which were the cases that fit the MCP shape well. What it didn't say loudly enough is that the MCP-only constraint is an architectural endpoint for some workloads and an architectural mistake for others.

The piece nodded at this in the trade-offs section, long-running streaming, sub-10ms latency, awkward impedance matches. Six months on, those nods are the part of the piece that needs amplifying. The MCP-only architecture is right when the workload fits MCP. It's wrong when it doesn't, and pretending otherwise produces ugly adapter layers that bury the problem rather than solving it.

So this piece is the recalibration of the recalibration. MCP won. MCP-everywhere lost on the merits even as the protocol won. Worth being plain about where the lines actually fall.

Where MCP is the right answer

The cases where MCP is straightforwardly the best choice in 2026, no asterisks needed:

Standard tool integration. Search, retrieval, structured queries, CRUD against a known surface, well-bounded read and write operations. The MCP request-response shape fits these natively. The portability and lock-in benefits compound. The use cases I tracked in December are mostly this category, and they're table stakes now.

Cross-vendor portability matters. When the same tool needs to work across Claude, GPT, Gemini, and whatever ships next. MCP is the only credible answer. Building anything else is a deliberate bet against the standardization.

Multi-agent surfaces. Agents calling agents, coordination between platforms, the multi-vendor tools story, all of this needs a common protocol. MCP is the protocol.

Memory, policy, audit. The infrastructure layer for any serious agent platform (memory access, policy decisions, observability) fits MCP cleanly and benefits from the uniformity. The routing layer makes this operationally tractable.

New tool development. When you're building a tool from scratch, building it MCP-shaped is the right default. The activation energy is small; the future-proofing is real; the alternative is to write something you'll wrap in MCP later anyway.

This is the 80%. Most tool integration in 2026 should be MCP and most teams should default to it without thinking too hard.

Where MCP doesn't fit

The cases where forcing MCP produces worse architecture than the honest escape hatch:

Long-running tasks with progress streaming. MCP's request-response shape fights any workload where the agent kicks off something that takes minutes-to-hours and needs to stream progress back. The workarounds (polling, callback registration, faux-streaming via repeated calls) all degrade the user experience and complicate the agent code. A proper async task protocol is the right answer; MCP wrapped around it is the wrong answer.

True streaming workloads. Real-time audio, video, sensor data, market feeds, anything where the model needs a continuous stream rather than discrete tool calls. WebSocket or gRPC streaming is the right protocol shape. MCP servers that pretend to stream by chunking into requests produce latency and complexity for no architectural gain.

Certain enterprise systems. SAP, mainframe interfaces, legacy ERP, anything where the existing integration surface is SOAP-and-XML-with-mandatory-session-state, or where the auth model is so intertwined with the protocol that wrapping it in MCP requires reimplementing half the system. The honest path is a thin adapter that the agent calls via MCP for the operations that fit and via a direct connector for the ones that don't.

High-throughput inline workloads. When the agent needs to make hundreds of small tool calls in a tight loop and the latency budget is sub-10ms per call, the MCP overhead matters. Direct integration is the right answer; the architectural cost is small and the performance gain is real.

Bidirectional or push-driven surfaces. Webhooks, server-sent events, anything where the external system initiates the interaction rather than the agent. MCP's pull-shaped model fights this; the honest answer is an event bus or webhook handler that the MCP layer reads from.

Cases where the type system carries the weight. Some integrations benefit from rich typing, generics, algebraic data types, strict schema evolution. MCP's JSON-shaped surface is fine for most cases and awkward for these. When the typing matters, gRPC or a typed RPC layer is the right answer.

This is the 20%. It's not negligible; it's not the majority either. The discipline is to recognize which category a given integration falls into rather than reflexively defaulting one way.

The escape-hatch pattern that actually works

The pragmatic architecture I keep ending up with on real projects in early 2026:

MCP is the default tier. New tools, standard integrations, cross-vendor surfaces, all go in as MCP servers. The agent talks MCP for the bulk of its tool calls. The routing layer handles the server population.

A small, named escape-hatch tier for non-MCP integrations. Each one is a deliberate decision with a written justification. The list is short (usually 2-5 integrations on a given platform) and reviewed periodically to see if any have moved into a category where MCP would now fit.

Adapter MCP servers wrap the escape-hatch surfaces where it makes sense. For the parts of a non-MCP integration that are MCP-shapeable (the request-response operations even on a SOAP system, say), a thin MCP adapter exposes them. The agent uses MCP for those; falls through to the direct connector for the parts that don't fit.

Observability and audit cover both tiers uniformly. The escape-hatch integrations emit into the same observability and audit MCP servers as everything else. The trade-off is on the call protocol, not on the operational surface.

Policy enforcement covers both tiers uniformly. Whatever calls the escape-hatch makes still pass through the policy layer. The discipline that makes the MCP-only architecture safe doesn't get abandoned for the escape hatch; it gets enforced at the adapter boundary.

This is the architecture that respects the standardization win without pretending the protocol fits every shape. It's also the architecture that survives contact with the messy enterprise integrations that exist regardless of how clean we'd like things to be.

A note on the labor side

Worth a brief note since this kind of architectural piece often skips it. The MCP standardization absolutely changes the integration-engineer job, fewer person-months spent on bespoke adapter code, more spent on the policy and routing layers above it. Some of that productivity gain shows up as faster delivery; some of it shows up as smaller integration teams.

The displacement is real and it's accelerating faster than I expected. The pace is the issue, not the reality. The companies cutting integration headcount in early 2026 are responding to the productivity narrative as much as to the actual capability shift; the cuts are running ahead of where the tooling can absorb them. The sustainable model is human-plus-AI integration teams that ship faster and better, not headcount reduction as the goal. The headcount will still shrink, collaboration shrinks it less and shrinks it well, but it shrinks.

That's the labor backdrop on architectural choices like this one. The choice of MCP-plus-escape-hatches versus pure-MCP versus patchwork doesn't change the labor dynamics much; the tooling getting better changes them whether the architecture is clean or not.

How to tell which tier an integration belongs in

A few questions that resolve the categorization quickly:

Does the integration fit a request-response shape? If yes, MCP. If it's truly streaming or push-driven or long-running, escape hatch (with MCP wrapping the request-response parts).

Is cross-vendor portability valued for this tool? If yes, MCP, full stop. If the integration is single-vendor and will stay that way, the case for MCP is weaker but usually still positive.

Is the latency budget compatible with MCP overhead? For the vast majority of agent tool calls, yes. For the small set where it isn't, escape hatch.

Does the existing system require session state or transactional semantics that MCP doesn't model? If yes, escape hatch with an adapter that handles the state and exposes the operations cleanly.

Would building it MCP-shaped require reimplementing significant pieces of the underlying system? If yes, escape hatch, wrap what fits, adapter the rest.

These five questions resolve most categorization decisions in a few minutes. Worth running them deliberately rather than defaulting either way.

What the pure-MCP-everywhere argument gets wrong

The argument shows up regularly in the late-2025 / early-2026 discourse and it's worth naming what it gets wrong:

It treats the protocol win as an architectural mandate. The protocol won the integration-layer argument. That's a different question from "should every integration use this protocol." The first is settled; the second is per-case.

It dismisses the escape hatches as architectural failure. The escape hatches aren't failure; they're acknowledgment that no protocol fits every shape. The architectures that pretend otherwise produce worse outcomes than the architectures that are honest about it.

It overestimates the cost of mixed-protocol architectures. The cost is real but smaller than the pure-MCP advocates suggest. With proper observability and policy uniformity, the mixed architecture isn't materially worse to operate than the pure one. The lock-in story is slightly worse; the operational story is comparable.

It underestimates the cost of forcing the wrong shape. The MCP wrappers around fundamentally non-MCP integrations are themselves complexity. The "we wrapped it in MCP so it counts" claim hides the wrapping complexity rather than getting rid of it.

The honest read is that MCP won the protocol argument decisively and won the architecture argument substantially-but-not-completely. Both halves matter.

What this means for new platform work

A few takes for teams starting agent platform work in 2026:

Default to MCP. Justify the escape hatches. The default reverses what it was a year ago, non-MCP integrations need a written reason, not the other way around. But maintain the list of justified exceptions; don't pretend they don't exist.

Build the routing layer early. With both MCP and non-MCP integrations in the mix, the routing-and-observability layer carries more weight. Investing in it early pays back across both tiers.

Don't ship MCP wrappers around fundamentally non-MCP systems just to claim MCP-only. The wrapping debt accumulates and the architecture-on-paper diverges from the architecture-in-practice. Be honest about the escape hatches.

Plan for the escape-hatch list to shrink. As MCP matures, as streaming gets better-specified, as long-running tasks get protocol patterns, as more enterprise systems get MCP front doors, some current escape hatches move into the MCP tier. Review the list quarterly.

Treat the discipline of the categorization as the load-bearing skill. The architecture is fine if the tier each integration belongs in is debated honestly. The architecture rots if either side wins by default.

The honest summary

MCP won the integration layer. The follow-on claim that every integration should therefore be MCP-shaped is a category error that produces worse architectures than the honest mixed pattern. The right shape for 2026 is MCP for the 80% it fits cleanly plus a deliberate escape hatch tier for the 20% where it doesn't.

The discipline is in the categorization. The architecture works when teams call each integration honestly. It fails when ideology wins on either side, pure-MCP-everywhere produces ugly wrappers, patchwork-everywhere wastes the standardization win.

I'd rather be wrong about the escape-hatch list being durable than be caught with an architecture that pretends MCP fits everything when the operational reality is different. The pragmatic middle is the right place to be in 2026. Worth being plain about; worth defending against the purity arguments on both sides.

The protocol won. The architecture argument is more nuanced. Both true; both worth being honest about.