26 March 2026 · Nick Finch
MCP won. Now build something with it.
The protocol war many predicted never happened. MCP is becoming invisible infrastructure, and the real story is what you can build when agents compose multiple types of intelligence through simple, modular servers.
The protocol war many predicted never happened. The Model Context Protocol has 97 million monthly SDK downloads, over 10,000 active servers, and first-class support from every major AI platform. OpenAI, Google, Microsoft, Amazon, Cloudflare, Bloomberg. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, co-founded with OpenAI and Block. There is no competing standard. Nobody wants one.
MCP is becoming boring. And boring infrastructure is the only kind that matters.
The interesting question is no longer whether MCP will succeed. It is what becomes possible now that a universal interface exists between AI agents and everything they need to talk to. We have been building on MCP at inmydata for months, and the answer, it turns out, is more than most people realise.
The USB moment
USB did not win by being technically superior to every serial and parallel port it replaced. It won by being good enough and everywhere. REST APIs won the same way. So did HTTP. The pattern is always the same. A standard interface emerges, it absorbs the complexity of what came before, and the per-integration cost drops to near zero. The protocol itself becomes invisible.
MCP is following the identical trajectory, just faster. What took USB a decade, MCP has done in eighteen months. The protocol is not perfect. The spec is still maturing. But it is already the default, and the default always wins.
The real value, though, is not the protocol. It is the architectural pattern the protocol enables.
Composability is the unlock
When every data source, knowledge base, and workflow exposes the same interface, you stop building monolithic agents with embedded logic for every possible integration. You start building composable systems from focused, modular MCP servers. Each server does one job well. The agent orchestration layer composes them together.
This is a fundamental shift in how you design agentic systems. Instead of a single fat agent that knows how to query your ERP, search your knowledge base, and manage your workflows, you build thin agents that talk to specialised servers. The servers are the intelligence. The agent is the conductor.
At inmydata, this is not a theoretical position. We run three distinct MCP servers in production today, each serving a fundamentally different type of intelligence to our enterprise agents.
Three servers, three types of intelligence
Operational data. Our inmydata analytics platform connects to ERPs, CRM systems, and business applications. Structured data flows in, gets processed, and sits in inmydata ready to be served. An MCP server exposes this operational data to agents. When an agent needs to understand revenue by region, stock levels, or customer churn, it talks to this server. This is the operational reality layer. Hard numbers, structured data, the ground truth of the business.
Expert knowledge. Alongside the analytics platform, we run our agentic RAG platform. This captures and serves a completely different kind of intelligence. Think thirty years of database administration expertise. Or the accumulated knowledge of specialist coffee buyers who can assess quality, origin, and pricing from experience that no structured dataset contains. This is institutional wisdom. It lives in people’s heads, in documents, in years of accumulated judgement. Our second MCP server makes that knowledge available to agents through retrieval-augmented generation. When an agent needs context that goes beyond the numbers, it talks to this server.
Knowledge generation. This is the one that surprises people. When an agent asks a question and identifies a gap in the knowledge base, something the RAG platform simply doesn’t have an answer for, it doesn’t stop. It uses a third MCP server to generate an interview request. Another agent then interviews the relevant expert in the business, captures the new knowledge, chunks it up, and feeds it back into the RAG knowledge base. The gap is filled. The system gets smarter.
This third server does not retrieve information. It requests it. That distinction matters. MCP is not just a protocol for connecting agents to existing data. It is a protocol for composing intelligent workflows where agents can actively expand the knowledge available to them.
The architecture is the strategy
These three servers work together because each one is simple, focused, and independent. The operational data server knows nothing about expert interviews. The RAG server does not care where its knowledge comes from. The interview server’s only job is to capture new information and put it in the right place. The agent orchestration layer composes them into something far more capable than any single system.
This is our strategy at inmydata. We will continue building modular pieces of functionality, each exposed through MCP, each doing one thing well. The protocol is the glue that makes these pieces composable. The architecture is what delivers value to our clients.
And this scales. Every new MCP server we build, whether it serves financial data, manages approval workflows, or connects to a new class of enterprise system, plugs into the same architecture. The cost of adding capability drops with every server. The compound returns are real.
A word on security
You will have seen the headlines. Security researchers found nearly 2,000 MCP servers exposed on the internet with zero authentication. That sounds alarming until you look at what those servers actually are. The vast majority are experimental deployments, people playing with the technology without implementing proper auth because it is optional and friction-free to skip.
The protocol supports OAuth 2.1 and proper authentication. The frameworks are maturing fast. Any organisation implementing MCP seriously puts in proper authentication and security layers, the same way you would with any production API. The security headlines reflect the pace of experimentation, not a fundamental protocol problem.
Build now, or catch up later
MCP is no longer interesting because it is new. It is interesting because it is becoming invisible, and invisible infrastructure is the kind that reshapes industries.
The organisations building composable MCP architectures today are learning patterns that their competitors will eventually need but won’t yet have. They are solving the edge cases, building the institutional knowledge, and accumulating advantages that compound over time. We see this every day at inmydata, where each new MCP server we build makes the next one faster and the overall platform more capable.
Waiting for the specification to be perfect before committing is the riskiest move available. The protocol that everyone adopts is the one that becomes the standard, and the standard is already here. The only question is whether you are building on it or planning to catch up.