The Model Context Protocol is an open standard for connecting AI applications to data and tools. It turns an integration matrix into a set of interfaces.
The problem underneath
An assistant is only useful when it can reach something real: the maintenance history, the parts database, the ticketing system. Each of those connections has historically been bespoke — written for one assistant, against one API, with its own authentication and its own idea of how a tool is described.
The arithmetic gets bad quickly. Five internal systems and three AI clients is fifteen integrations to write and maintain, and each new client on either axis multiplies rather than adds.
What the protocol does
The Model Context Protocol standardises that connection. You expose a system once, as an MCP server, describing what data it offers and what actions it permits. Any client that speaks the protocol can then use it, without knowing anything about your implementation.
The comparison the specification makes is to a USB-C port, and it is a fair one: a single physical standard replaced a drawer of proprietary connectors, and nothing about what the devices do changed. Fifteen integrations become eight, and the next client to arrive costs nothing.
Standardising the connector does not standardise the judgement about what should be plugged into it.
Servers, clients, and the boundary between them
A server wraps a system and publishes three kinds of thing: resources the model can read, tools it can invoke, and prompts that encode a known-good way of asking. A client is the AI application that connects to it. The protocol handles discovery — a client asks a server what it offers and gets a machine-readable answer.
Support is broad. The mainstream assistants and several development environments already speak it, which is what makes "build once" a real claim rather than an aspiration.
Where the engineering effort actually goes
The protocol makes connection easy. It makes none of the following easier, and these are what a deployment stands or falls on.
Deciding what to expose. A server that publishes every table in the ERP is not an integration; it is an incident waiting for a prompt. Expose the specific queries and actions that a defined task needs.
Authorisation. The model acts on behalf of a person, and it must inherit that person's permissions rather than the server's. Getting this wrong turns a convenience feature into a route around your access controls.
Write operations. Reading is recoverable; writing is not. Anything that changes state — raising a work order, updating a record — needs the same confirmation and audit trail you would demand of any other automated actor, plus a way to tell afterwards what was done and why.
That last point is worth sitting with. The protocol is new; the discipline it needs is not. It is the same discipline you would apply to any system granted credentials to your plant.
Written by the software delivery team. Published articles carry a named author once attribution is confirmed.
