Sometimes the future shows up wearing yesterday’s jacket. That’s exactly what the Model Context Protocol (MCP) looks like right now. It’s clean. It’s extensible. It’s open. And it’s being embraced by AI labs like Anthropic, OpenAI, Google, and Microsoft as the connective tissue between agents and tools.
If you remember the rise of SIP (Session Initiation Protocol) in the early 2000s, this moment should feel familiar. SIP was supposed to be the universal signaling protocol for real-time communications. It still is, technically. Your VoIP call, Zoom session, or softphone app likely rides over SIP in some form. RFC 3261 is still the standard.
But what happened to the promise?
SIP became fragmented. Vendors layered on their own implementations, leading to interoperability headaches. “SIP-compatible” often meant “sort of compatible.” While SIP survived, it required SBCs (Session Border Controllers), gateways, and interop teams to make it work across domains. Still, SIP has stood the test of time. It powers everything from Twilio to Microsoft Teams (via Direct Routing) and remains a workhorse in VoIP and UCaaS.
🔍 Back in 2011, I wrote:
“SIP has been promising compatibility since day one… until vendors broke it by adding their own takes.” — from “SIP Signaling Still Needs Work”
Now, along comes MCP, positioned as the new universal layer for AI agents to discover and interact with tools. Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation (AAIF) to keep it neutral, which was a smart move to avoid lock-in. And Google just rolled out fully managed MCP servers for Maps, BigQuery, and GCP services, turning these into plug-and-play agent endpoints. TechCrunch covered it here.
This is a powerful idea, but also a familiar one.
Back in 2012, Google helped launch WebRTC as a native browser-based standard for real-time communications. It promised a plugin-free future for voice and video. Google open-sourced their media engine, contributed heavily to the spec, and eventually folded it into Chrome. But adoption was uneven. Apple dragged its feet. Microsoft built workarounds. Vendors layered their own implementations on top of the standard, just like with SIP.
🧠 In 2017 I postulated that:
“Amazon’s Chime feels like a Me-Too platform, but it’s really about owning the experience stack by running it all on AWS.” — in my Chime launch commentary, comparing it to Zoom, BlueJeans, and WebRTC flavors
Google’s MCP rollout strategy mirrors its own earlier WebRTC push. Standardize the interface, seed adoption with developer tools, then optimize the experience on your own infrastructure. It worked with WebRTC, where Google Meet now runs a highly tuned flavor. MCP could follow the same path.
That’s the opportunity. But the risk is that MCP becomes another “standard” in name only, with agents requiring tailored wrappers and SDKs depending on which MCP endpoint they call. That is precisely how SIP fell into complexity.
🛡️ But to me, it’s Deja Vu all over again from 2008:
“We thought SIP would make things easier. Instead, we got SPIT, eavesdropping, and call hijacks. Security always lags the protocol.” — from “Cisco, Skype and the Cost of SIP Security”
Another concern is security. Back when VoIP started booming, we saw threats like SPIT (Spam over IP Telephony) and call spoofing emerge as open protocols invited bad actors. With MCP, the attack surface grows wider. Now, agents can not only discover tools but also execute operations. That means prompt injection, tool impersonation, and unauthorized access if IAM and logging are not tightly enforced. Google outlines some early mitigation strategies here.
So is MCP the new SIP? In spirit, yes. It solves the same problem: connecting intelligent endpoints across domains.
But if we want it to succeed where SIP stumbled, it needs more than enthusiasm and adoption. It needs guardrails, consistent implementations, and cross-vendor enforcement.
Otherwise, we’ll be building toolchains on shaky ground. Again.