MCP just got a rival enterprise protocol: the portability playbook I run before teams pick a side

Introduction

I got three Slack messages the same morning the enterprise-protocol story circulated. Version A: "Pause the MCP migration." Version B: "We should wait for Google and Microsoft." Version C: "Delete our MCP servers before we get locked in." All three are the wrong move twelve days before MCP 2026-07-28.

MCP already has eighteen months of SDK downloads, server inventory, and client wiring. A rival coalition does not erase that. It does change the buyer conversation. The question is no longer "is MCP real?" It is "how do we keep optionality when incumbents ship an alternative?"

What actually changed (and what did not)

I am not dismissing the coalition. Salesforce, Snowflake, and ServiceNow sit on a lot of enterprise data. Google and Microsoft sit on the clouds. When those five say "shared protocol," IT buyers hear vendor relationship risk, not JSON-RPC details. That is the real fight.

The portability stack I insist on

Portability is not "support every protocol." Portability is making the expensive part (business tools, auth policy, evals) survive a transport swap.

1. 01
   Keep tool contracts above the wire

   Your registry of atomic, typed tools with honest failure modes is the asset. MCP, A2A-style agent messaging, or a vendor gateway should call the same functions. If business logic lives inside an MCP SDK adapter, you already lost. See tool registry design and your tools are the contract.
2. 02
   Put authorization in the IdP, not in the client consent UX

   Enterprise-Managed Authorization (EMA) and IdP group policy travel better than a pile of per-connector OAuth screens. Whatever protocol wins procurement, identity still decides who can call finance tools. Walk MCP EMA now so you are not redoing consent when a second protocol lands.
3. 03
   Govern at the gateway

   Rate limits, audit logs, allowlists, and header redaction belong in one place. Databricks-style AI gateways and homegrown MCP proxies already prove the pattern. A second protocol should plug into the same control plane, not invent a second shadow IT stack. See Unity AI Gateway MCP governance.
4. 04
   Finish the July 28 MCP work anyway

   Stateless handles, Mcp-Method routing, and cacheScope verification are operational hygiene even if you later dual-run another protocol. Pausing week-3 handle migration because of a press cycle is how you get 502s on GA day. Continue week-three handle sprint and the header security checklist.
5. 05
   Write an exit clause into the architecture decision record

   Document which layer is protocol-specific (transport adapters, health checks) and which layer is forbidden to be (pricing engines, CRM writes, PII redaction). Review that ADR every time procurement waves a new logo.

How I talk to buyers this week

• MCP has a dated GA (July 28) and a public RC. Ask rivals for an equivalent public timeline before you stall.
• Ask whether the shared protocol covers agent-to-tool (MCP's job), agent-to-agent (closer to A2A), or both. Mixing those layers in one RFP creates messy RFPs.
• Demand a dual-run plan: existing MCP connectors for coding agents, vendor protocol for CRM/ERP agents, shared tool service underneath.
• Price the switching cost of re-authoring tool descriptions twice. That cost usually exceeds the license delta.

What not to do

• Freeze the MCP July 28 migration "until the dust settles." Dust does not settle on protocol wars. Specs do.
• Rewrite every Claude Code and Cursor MCP config into a vendor SDK because a blog post said so.
• Assume foundation membership means interoperability. You still need conformance tests and shared schemas.
• Treat protocol choice as a model choice. You can keep Claude or Gemini as the brain and still swap how tools attach.

Where this meets security and observability

Two protocols means two places for poisoned tool results and confused-deputy bugs unless you normalize untrusted inputs at the gateway. The Agentjacking pattern does not care which logo is on the connector. Same for spend: attribute cost per completed task in the unified agent spend dashboard, not per protocol brand.

Conclusion

A rival enterprise protocol is a signal that MCP mattered enough to scare incumbents. Ship the July 28 migration. Keep tools, IdP policy, and gateway controls portable. Pick a side only when you have a public spec, a dual-run plan, and an ADR that says what you refuse to rewrite twice.

Sources: MCP 2026-07-28 release candidate at MCP blog; mid-July 2026 industry reporting on the Google/Microsoft/Salesforce/Snowflake/ServiceNow shared enterprise agent protocol (The Information via secondary digests). Treat coalition details as provisional until a public specification ships.