The Industrial IoT Blog

For a long time, “chat with your factory data” felt like a demo trick.

You know the kind. Someone types “What’s my OEE today?” and a bot answers with a nice sentence. It looks impressive. Then someone asks a real question, like “Which filler caused the last three micro-stops, and what changed right before it?” and the illusion collapses.

Most of those demos never survived contact with the real shop floor.

What changed for me recently was MCP. Not because it is magic. But because it finally made the chat part behave like an engineering interface, not a toy.

Let’s unpack that in plain terms.

What MCP Actually Is

MCP stands for Model Context Protocol. It is an open standard that allows AI systems, such as large language models, analytics engines, or automation assistants, to connect to external systems in a structured and predictable way.

Think of MCP as a translator between an AI model and the messy industrial world.

Factories run on a mix of systems. PLCs, historians, MES platforms, lab systems, edge gateways, MQTT brokers, OPC UA servers. Each system has its own protocol, its own model, and its own quirks.

Before MCP, building a “chat with your factory” interface usually meant writing custom connectors for every system. Those connectors broke often, required maintenance, and rarely scaled beyond a demo.

MCP introduces a consistent structure. Instead of guessing what exists, the AI interacts with three defined concepts:

• Resources, data sources such as sensor readings, asset attributes, batch data, alarms, or logs
• Tools, actions that can be executed, like retrieving data, triggering workflows, or sending commands
• Prompts, structured interaction templates that guide how the AI asks questions and interprets responses

The result is simple. The AI is no longer improvising. It is operating inside a defined toolbox.

The Real Problem. Factory Data Is Messy by Design

Anyone who has worked around manufacturing systems knows the problem is not getting numbers. The problem is making sense of them.

Industrial data is messy on purpose:

• Tag names are inconsistent.
• Units are missing or wrong.
• Timestamps do not line up between systems.
• “State” means five different things depending on the line.
• Every site has an asset model that is “almost the same.” Almost.

This is why “just let people ask questions in natural language” often fails. The AI does not know what anything actually means.

If the underlying data structure is a swamp of tags, the AI is just swimming in mud.

The Moment It Started Feeling Different

The first time MCP felt real was when we stopped treating AI like a brain with opinions and started treating it like a user with a toolbox.

Instead of the model guessing answers, the workflow looked more like how engineers actually work.

1. Discover what data exists

Not guessing. Actually listing assets, data points, and how the system names them.

2. Pull the data with the correct scope

Not vague human concepts like “today.” Instead, a precise time window, site, asset, and sampling rule.

3. Show the full trail

Where did the answer come from.
Which system.
Which tags or attributes.
Which query.

This last point matters more than people realize.

In regulated environments, “because the AI said so” is not an answer. It is a compliance issue.

Traceability is not optional.

A Small Example That Built Trust

One example made the difference very clear.

An operator reported that a line felt slow. The dashboard looked normal. The usual argument started. Operations said the line was sluggish. Engineering said the metrics looked fine.

Using an MCP-driven assistant, the conversation shifted.

First the system asked which line. Then it listed the available assets.

Then it clarified what “slow” meant. Speed loss. Stops. Quality holds.

It pulled the last eight hours of state data. It showed the top three stop reasons by duration. It highlighted a period where the line speed dropped. That drop aligned with a mode change.

The AI did not magically solve the root cause.

But it did something more valuable. It gave everyone the same timeline and the same facts.

That is engineering. Not storytelling.

An Architectural Example

In an environment, MCP can connect to a plant’s Unified Namespace.

The Unified Namespace, often implemented through MQTT or event streaming platforms, acts as a real-time data layer for the plant. PLC tags, MES events, equipment states, alarms, and batch information all flow into this structured namespace.

The architecture can look like this:

1. An engineer asks a question, for example:
   “Show me the last hour of alarms on packaging line 4.”
2. The language model determines which resource is required.
3. The MCP client translates the request into a structured query.
4. The MCP server retrieves the data from the appropriate system. A historian, MES platform, or edge gateway.
5. The response returns to the user. Along with the data source, query scope, and timestamp.

Everything is logged. Everything is permission-checked.

That structure changes everything. The assistant becomes predictable.

Predictive Maintenance Without the Hype

One of the first real use cases involved predictive maintenance.

A production line had recurring unplanned downtime. Sensors were already collecting vibration and temperature data, but engineers had to manually analyze the trends.

With MCP connected to the sensor streams, the assistant monitored those signals continuously.

When a vibration anomaly appeared, the system triggered an alert. It also created an MES event and logged the anomaly in the maintenance system.

Engineers could then ask questions like:

“Show me the vibration pattern before the last three failures.”

Or:

“What equipment parameters changed before the anomaly?”

The assistant did not replace engineers. It simply reduced the time needed to investigate.

That shift matters.

My Not-So-Popular Opinion

A lot of AI initiatives in manufacturing fail for a simple reason.

We try to make them impressive before we make them dependable.

Personally, I would rather ship a boring assistant that:

• only answers 20 percent of questions
• always shows its work
• never hallucinates a tag

Instead of a flashy assistant that answers everything confidently and is wrong twice a day.

In manufacturing, confident mistakes create operational noise. Once trust is lost, the entire system becomes useless.

The Conditions for This to Work

For “chat with your factory data” to work in real operations, a few conditions must exist.

Asset models and naming conventions need to be decent. Not perfect, just consistent enough.

Units and time zones must be treated as first-class citizens.

The assistant must be able to say “I don’t know.”

Every answer must be traceable back to a source and query.

Access control must be strict and boring.

None of these things are glamorous. But they are the difference between demos and production systems.

Final Thought

The first time I saw an operator diagnose a real process issue through a chat interface, and then follow the trail of data back to the source system, something clicked.

Not science fiction.

Just practical engineering.

Not “talk to your factory.”

More like. Finally ask questions about your plant the way engineers actually work.