Explaining the Model Context Protocol

After more than three decades building data integration software, I have learned to be sceptical of new acronyms. The technology industry produces them at a rate the rest of us struggle to keep up with, and most fade within a year or two. A small handful, however, become so foundational that we forget they once needed explaining at all. HTTP is one of many great examples, and Model Context Protocol, or MCP, is on track to be the next.

 

When Anthropic introduced MCP in November 2024, it described the protocol as a "USB-C for AI": a single, open standard for connecting artificial intelligence agents to the resources they need to do useful work. The framing was deliberately humble, and that humility was the point. MCP is plumbing. Like all good plumbing, its value is only obvious when it is missing.

 

Eighteen months on, those humble beginnings have completely shifted the narrative for how technology should be built. A January 2026 study by Stacklok found that 77% of senior technical leaders considered MCP adoption as either important or a high priority entering 2026, with more than half of software organisations already experimenting in pilot or limited production. For nearly half of software firms surveyed, MCP now ranks in the top five technology priorities, a remarkable position for a standard barely a year old.

 

 

What MCP does

To understand the excitement, it helps to picture the problem MCP solves. Until very recently, every AI agent that wanted to take real action, such as opening a support ticket, querying a database or drafting an email, needed a custom-built connection to each system it touched. Across a typical enterprise, with dozens of AI tools and hundreds of systems, this turned into the kind of integration sprawl that has been a subtle tax on IT budgets for forty years.

 

MCP collapses that problem by standardising the conversation. A developer, or a vendor, creates an MCP tool that exposes a system’s capabilities once, in a defined format. Any software system (AI or not) that speaks MCP can then call those capabilities without further customisation. The calling system asks; the server responds. MCP is open and vendor-neutral. It works the same regardless of which system or AI is on the other end, whether built by Anthropic, OpenAI, Google, Meta or others.

 

If there is one thing to take away about MCP, it is that it is not merely an AI protocol.  If you think MCP is about AI, you have missed the bigger picture.  It is an integration protocol.   There is no requirement that either the MCP Client or the MCP Tool being called have anything to do with AI. 

 

There is a strategic story here too. MCP turns an agent from a chatbot into a colleague. A large language model on its own can only describe what it would do. MCP is not about data access, and in fact MCP tools can perform all the CRUD (Create, Read, Update, and Delete) operations.  Equipped with MCP, the model can thus act, observe the result, and decide what to do next. That feedback loop is the difference between a clever demo and a system that clears a queue overnight.

 

 

Why not just keep building bespoke connectors?

Before MCP, every system had its own way of plugging into the rest of an enterprise’s software. The practical consequence was duplication: integration teams ended up building the same connection to a data warehouse or HR system four or five times, once for each system or AI tool, and rebuilding it every time either side changed. The cost in engineering hours, ongoing maintenance and missed productivity was huge for organisations moving seriously on AI.  

 

The good news is that organisations that already have data integration platforms may need to start from zero, as they may find that their existing workflows can become MCP tools easily. 

 

MCP works because it absorbs that variability into a single layer. Build the connection once, and any AI tool that speaks MCP can use it. In practical terms, new AI capabilities can be deployed in days rather than months, integration teams are freed from rebuilding the same pipes for each new model, and the business is no longer tied to the pricing, roadmap or limitations of a single AI vendor. For a CTO weighing AI investments in an unsettled market, that flexibility is the headline benefit. 

 

 

The challenges nobody is hiding

The story is far from finished, as the same Stacklok survey found that 64% of software leaders cite security as the leading obstacle to adoption, followed closely by legacy system integration and the cost of running MCP in production. Letting an AI agent reach into systems of record is exactly as risky as it sounds. The controls required to manage who can do what, keep an audit trail, and meet regulators’ expectations aren’t trivial. Some MCP tools ensure that the raw data is never exposed; every tool call is logged, with tight control over what data AI actually sees. 

 

Each of these obstacles is solvable with planning. Every previous integration standard, from EDI to REST, went through the same maturity curve: a period of enthusiastic but messy adoption, followed by the emergence of governance patterns that made the protocol safe at enterprise scale. MCP is moving through that curve unusually quickly, partly because the security community engaged early and partly because the stakes (letting an AI agent touch production systems) concentrate the mind.  

 

 

Becoming the new baseline

Two predictions feel reasonable at this point. First, within eighteen months, asking whether an enterprise tool "supports MCP" will sound as quaint as asking whether a website "supports HTTPS". It will simply be table stakes. Second, the organisations that treat MCP as infrastructure now, investing in the catalogue of internal servers, the governance model, and developer education, will move materially faster than those waiting for the dust to settle.

 

Getting a machine to do useful work has historically meant a person learning to speak its language. Each generation of business technology, from mainframes to spreadsheets to cloud applications, has narrowed that gap a little. MCP is the step where the machine begins to meet us most of the way.

 

For decades, the hard part of most technology projects has been getting one system to talk to another. From here on, the hard part will be working out what we actually want them to achieve together. A great many organisations are about to discover that they were better at the first problem than the second

 

---

 

Don Murray is the CEO and co-founder of Safe Software

 

Main image courtesy of iStockPhoto.com and TU IS