MCP for production
Talk to the plant instead of reading logs
A line stops, and the answer to why is spread across the controller, the control system and a paper shift log. Anyone who wants to bring it together today needs three people and half a day. An MCP server for production turns this into a question.
The connection
The standard route is OPC UA, because it is available in most modern plants and comes with a clean information model. Where that is not enough, Modbus, MQTT or a direct route to the controller are added, for example with Siemens S7 or Beckhoff. On the analysis side, we connect MES and control systems so that the order and batch context is preserved.
The MCP server is never located directly at the plant level. It reads via the designated interface and is the only component reachable from outside. The network separation between office and production networks remains in place.
Reading is the normal case
Most of the benefit arises without a single write access: downtime analysis across several shifts, development of overall equipment effectiveness, changeover times compared between lines, quality data in relation to the batch. Questions that nobody asks today because the analysis takes longer than the benefit is worth.
- Fault analysis
- “What happened on line 3 yesterday between 2 and 3 pm?” — with the controller messages, the preceding process values and the order context in one answer.
- OEE and availability
- Development over weeks, broken down by cause group, without anyone building a new report.
- Changeover and retooling times
- Comparison between shifts, products and plants, as a basis for concrete improvements rather than assumptions.
- Quality and traceability
- Process values in relation to the batch, when a complaint comes in and the question is what distinguishes this batch from the others.
Control: possible, but not in passing
A language model with write access to a plant is a safety decision, not a feature. We implement it, but only under three conditions, and without these three not at all.
- Allowlist instead of general authority
- Only explicitly approved operations can be called at all, with fixed value ranges. Whatever is not on the list does not exist for the model.
- Confirmation by a human
- Every write operation is displayed and must be approved by an authorised person. The model proposes; it does not act alone.
- Complete audit log
- Who, when, which operation, which values, which approval. Traceable and analysable, independently of the MCP server.
Why someone from engineering should build this
The difference between a connection that works in the lab and one that can hold up in running production does not lie in the AI. It lies in the question of which cycle times a query may tolerate, how a connection loss behaves and what happens if someone switches the plant to manual mode in the meantime.
Schady Hamid is an electrical engineer, IT/OT project manager at an industrial company in the canton of Aargau and a lecturer at the ABB Technikerschule (ABBTS) in Baden. The connections are built from the plant side, not from the software side.
Limits we state up front
- No safety-related functions. Emergency stop, safety circuits and everything under functional safety remain outside the scope.
- No automatic intervention without human approval.
- No removal of the network separation between office and production networks.
- No connection to plants whose manufacturer does not approve the interface.
Frequently asked questions
Can the AI actually control our machines?
Technically yes, and we implement it. However, there is always an allowlist of permitted operations with fixed value ranges, confirmation by an authorised person and a complete audit log. Safety-related functions such as emergency stop always remain outside the scope.
Which protocols and controllers are supported?
The standard route is OPC UA. In addition, Modbus and MQTT as well as direct connections to common controllers such as Siemens S7 and Beckhoff. On the analysis side, we connect MES and control systems so that the order and batch context is preserved.
Does this put load on our plant?
Queries are designed so that they do not affect the controller's cycle times. As a rule, we read via the designated interface or a historian, not directly from the process image. We define the load limits together with your maintenance team before implementation.
Does the production network have to be opened for this?
No. The separation between office and production networks remains in place. The MCP server is the only component reachable from outside and, for its part, communicates with the plant level only via the designated interface.
Is it worthwhile even without an MES?
Yes. Access to controller and process values alone answers questions about stoppages, changeover times and availability that today can often only be answered via shift logs. An MES mainly improves the order and batch context.
Let’s check whether it holds up for your systems.
The feasibility study takes one to two weeks and ends with a document you can keep working with even without us. If an interface cannot meet your requirement, it says so.
Request a first call