MCP and UK manufacturing: the standard that finally lets AI talk to your shop floor
A new open protocol is changing how AI systems plug into engineering and operational data. Here is what UK manufacturers need to know, and how to get ready for it without throwing money at hype.
Every AI tool needs context. Every integration to give it that context is bespoke. That is the bottleneck.
Look at almost any UK manufacturer right now and you will find the same pattern. The CAD system holds the design intent. The PLM holds the engineering change history. The MES holds what actually ran on the line. The ERP holds the commercial reality. The quality system holds the deviations. None of these systems were designed to talk to each other in real time, and the integrations that exist were built one custom interface at a time.
Now layer AI on top. Every AI tool you adopt — a copilot in the design office, a scheduling assistant in production, a quality classifier on the line — needs context to be useful. Each one needs its own bespoke integration into the same underlying systems. Multiply ten AI tools by ten data sources and you have a hundred custom integrations. The cost is not the AI. The cost is the wiring.
"The reason AI feels generic on your shop floor is not the model. It is that the model has no idea what your shop floor looks like."
Why this matters now: a standard has arrived
Late in 2024, Anthropic published an open specification called the Model Context Protocol — usually shortened to MCP. It is, in plain English, an agreed way for AI applications to ask for data and to call tools, no matter what system that data or tool lives in. Think of it as USB for AI context. One side speaks a standard language, the other side speaks the same standard language, and a long list of one-off custom integrations becomes unnecessary.
Within twelve months the standard has been adopted by Anthropic's own products, by major IDE vendors, and by a fast-growing ecosystem of open-source servers that wrap everything from databases to ticketing systems to industrial historians. For UK manufacturers, the relevance is straightforward: if your existing systems can speak MCP, then any AI assistant you adopt can use them without a custom integration project.
This does not solve every problem. It does not magically fix bad data. But it does change the economics of putting AI to work in the business, and that is worth paying attention to before the next round of vendor pitches lands on your desk.
What MCP actually is, in three plain-English pieces
You do not need to be technical to follow this. The whole protocol has three roles, and each one does a specific job.
The host. The AI application your team actually uses. A desktop assistant, an IDE, a Copilot-style tool inside a CAD or ERP product. This is what your engineer or operator interacts with.
The client. The bit inside the host that knows how to talk MCP. You do not see it. It manages the connections to one or more servers, asks them what they can offer, and routes the AI's requests to the right one.
The server. A small adapter that sits in front of a real data source or system. It speaks MCP outwards, and it speaks the system's native language inwards. There can be one server per system: an MCP server for your PLM, one for your MES, one for your ticketing tool. Each one publishes what it can do — for example "list open engineering change orders," "fetch the bill of materials for a part number," or "raise a deviation in the quality system."
The genius of the design is that the AI never needs to know the internals of any of those systems. It only needs to know how to speak MCP. The server takes care of translation, authentication, and pagination on the system side. That is what turns a hundred custom integrations into one.
What this looks like on a real UK shop floor
Picture a mid-sized precision manufacturer in the Midlands. They run a PLM for engineering, an MES for production tracking, a quality system for non-conformances, and a maintenance system for the line. The four systems exchange data via a fragile collection of nightly batch jobs and a few keenly maintained spreadsheets.
The scenario. The production manager asks an AI assistant on her laptop, "show me every open engineering change order that affects parts running on Line 3 this week, and flag any that have an outstanding quality deviation."
Without MCP. That question requires three custom integrations and an analyst to bridge the gap. It takes a week. By the time the answer arrives, the production schedule has moved on.
With MCP in place. Three small MCP servers — one in front of the PLM, one in front of the MES, one in front of the quality system — already exist. The AI assistant queries all three through the standard protocol, joins the results, and returns the answer in seconds. The production manager makes the decision in the same conversation she asked the question in.
What has actually changed. The underlying systems have not been ripped out or replaced. The data quality has not been transformed. What has changed is that the friction between "I need to know X" and "X is on my screen" has collapsed from days to seconds. That is the unlock.
Why this matters specifically for manufacturing
Most of the AI conversation in industry right now centres on either chatbots or generative design. Both are valid, neither is the headline. The bigger story for manufacturing is operational AI: AI that helps the people running the business make better daily decisions, faster, by looking across systems that used to be siloed.
That use case has always existed in theory. What blocked it in practice was the integration cost. A custom integration project for every new AI capability is unaffordable for a mid-sized UK manufacturer, and rarely a sensible bet for a large one either. A standard protocol changes the cost curve. Once your existing systems have MCP servers in front of them — and many of the major vendors are now publishing first-party MCP servers themselves — the cost of adding the next AI capability is the cost of the AI assistant, not the cost of the integration.
The other thing it changes is portability. If the AI assistant you pick today is replaced by a better one in 18 months, your MCP servers and your data foundations carry over. You are not buying lock-in. You are buying a foundation that survives the next vendor cycle.
One of our recent discovery sessions surfaced eight separate "we'd love AI for that" wishes from a single management team. Six of them shared the same underlying data needs: engineering change history, current production status, and open quality issues. The traditional plan would have been six integration projects. The MCP plan is three small servers and six light AI applications on top. The cost difference is an order of magnitude.
What we would tell you if we were sat across the table
If MCP is on your radar but you are not sure what to do about it, these five directives are how we are advising UK manufacturing clients right now.
Do not buy more AI. Map your data sources first. Before you add MCP servers, know what you have, where the gaps are, and which data sources are actually reliable. AI cannot reason over a mess and pretend it is signal.Ask your existing software vendors whether they publish MCP servers. The serious vendors already do or have a roadmap. If yours does not, that tells you something about how they will age over the next five years.Pick one workflow as a proof of value, not "the platform." Engineering change to production. Quality issues to design. Maintenance to scheduling. Pick the one with the most painful friction today, wrap MCP around it, and ship a useful AI capability inside 90 days.Treat security and access control as a day-one design decision. An MCP server with no permissions model is a data leak waiting to happen. Decide who can ask what, and which actions require human approval, before the first server goes live.Plan the AI layer separately from the data layer. Your data layer (the systems and the MCP servers in front of them) should outlive any specific AI assistant. Design it that way and you stop buying vendor lock-in by accident.Thinking about MCP for your business?
We run discovery sessions with UK manufacturing teams to map the data sources, pick the highest-value workflow, and design the right MCP foundation before anyone buys an AI tool. Half a day, your team, a whiteboard, and a credible plan at the end of it.
Further reading
If you want a deeper technical introduction to MCP from an industrial-automation perspective, Inductive Automation (the company behind the Ignition SCADA platform) has published a useful explainer: What Is MCP? Understanding the Model Context Protocol. It covers the same standard from the operational technology side and is worth the read alongside this article.
For the formal specification, the protocol is published openly by Anthropic at modelcontextprotocol.io, including the reference servers and SDKs in multiple languages.