97 million installs. That's where Model Context Protocol landed in March 2026.
When I first saw that number, I did the thing PMs do with infrastructure news — I noted it, filed it under "dev stuff," and moved on. That's the wrong reflex. And it's one I've been unlearning.
MCP is an open standard Anthropic released last year for connecting AI agents to external systems. The short version: AI agents need to reach into tools — calendars, databases, CRMs, file systems — to actually do things. Until now, every connection required custom-written integration code. Each AI tool, each external system, each combination built separately.
MCP defines a standard socket. If an AI agent supports MCP, it can connect to any system that runs an MCP server. No custom bridge required.
This is the REST API moment for AI agents. In the early 2000s, web services ran on SOAP, XML-RPC, and proprietary formats. REST arrived and flattened it into a standard. Every PM eventually had to understand REST — not to implement it, but to understand what it unlocked and what it foreclosed.
MCP is doing the same thing for the agent layer.
Here's the product strategy implication that most PM discussions miss.
If your SaaS doesn't offer an MCP server, AI agents can't use it. Not just "can't use it well" — actually can't connect to it. Tools like Claude Code, Cursor, and the wave of agent-native products coming after them discover what they can interact with through MCP. Products outside that list are invisible to the agent.
That sounds extreme. But remember: in 2013, mobile API support was "nice to have." By 2018 it was table stakes. Technology cycles are shorter than they look in a roadmap spreadsheet.
Not having MCP support isn't a gap you're aware of — it's a choice you haven't made consciously yet. Those are the worst kind.
I work on clinical SaaS products — dental, general practice, dietitian software. Healthcare is one of the heaviest integration environments you'll find. e-Prescription systems, Ministry of Health APIs, insurance connectors, device integrations. Every one of them is hand-built today. Custom code per system, custom maintenance when something changes upstream.
Whether MCP changes how those bridges get built is an open question. The infrastructure is still maturing. Enterprise adoption is slow. Security standards are being written in real time.
But. The question is now on the roadmap — not because of hype, but because 97 million installs is past the "experimental" threshold. Something is stabilizing.
And when my engineering team says "we're setting up an MCP server for this workflow," I want to be the PM who asks the next question: Does this mean our users will be able to access this product from any agent that supports MCP? And if not, what would that require?
PMs learned REST APIs. Learned GraphQL. Learned webhooks. Usually a bit late, but they learned.
The pattern is predictable. A new infrastructure standard emerges. Developers adopt it. Product teams treat it as plumbing. Then the standard quietly becomes the layer everything else is built on — and suddenly your product's integration story is either modern or it isn't.
MCP is in the early middle of that arc right now. You don't need to go deep on the spec. But you do need to stop nodding when your team mentions it and start asking what it actually means for the product.
The invisible plumbing has a way of becoming the thing that matters most.