MCP, and Why Integrations Stopped Being Bespoke
The Model Context Protocol did something unglamorous and valuable: it made the connection between an AI agent and your tools a standard instead of custom glue.
The Problem It Solves
An agent is only useful if it can reach your systems. Before MCP, every one of those connections was bespoke. Connecting an agent to a CRM meant writing an adapter, and connecting a different agent to the same CRM meant writing it again, because each framework defined tools its own way.
That work was pure overhead. It was not where the value sat, it was the tax you paid before reaching the value, and it had to be paid per tool and per framework.
The Model Context Protocol is an open standard for that connection. A tool is described once as an MCP server, and any MCP-speaking client can use it. Write the integration once, use it from anything.
It Actually Became the Standard
Protocols get proposed constantly and mostly go nowhere, so the adoption numbers are the interesting part. As of March 2026 MCP had crossed 97 million monthly SDK downloads, with more than 10,000 public MCP servers in production.
More importantly, the vendors converged. Anthropic, OpenAI, Google, Microsoft, and Amazon all adopted it, which is a rare degree of agreement in this industry. It is now governed by the Agentic AI Foundation, with Anthropic, Block, and OpenAI as co-founders and AWS, Google, Microsoft, Cloudflare, and Bloomberg among the platinum members.
Governance sounds like a footnote and is not. A protocol owned by one vendor is a risk you inherit. A protocol run by a foundation the major players all sit on is something you can build against for years.
What Changed for Production Systems
The 2026 work has been about making it enterprise-safe rather than adding capability: audit trails, single sign-on, gateway patterns, and portable configuration. The new Streamable HTTP transport was standardised, which matters if you are running servers behind normal infrastructure rather than on a developer laptop.
The practical effect is that the integration layer is no longer the interesting risk in an agent project. It is closer to plumbing you can assume works, which moves the difficulty back to where it always belonged: deciding what the agent should do and what happens when it gets something wrong.
Where It Does Not Help
MCP standardises how an agent talks to a tool. It does nothing about tools that have no API at all, and that is still the normal case for a lot of business software: vendor portals and internal systems with a web interface and nothing behind it. For those, browser automation remains the route in, and no protocol changes that.
It also does not make an agent good. A standard connection to your CRM is not the same as an agent that knows what to do with it. The hard parts, grounding, escalation, and knowing when to stop, are unchanged.
What MCP removed was the boring, expensive part that used to sit in front of them. That is worth having, and it is enough.
Seen in our work
More insights
From idea to system
Want this built for your business?
We turn the ideas in these articles into systems that run in production. Start with a free discovery call.
Start a project