Why We Built a Factory MCP Instead of Letting Models Touch Raw Data
Large models are good at language, not at safely navigating factory data. We built a bounded factory MCP layer so agents ask better questions, use the right abstractions, and stop taking dangerous shortcuts.
The naive version of industrial AI sounds simple:
connect the machines, dump the data somewhere, give a model access, start asking questions.
That works just well enough to be dangerous.
The problem is not that the model lacks intelligence. The problem is that raw factory data is a terrible interface.
A model exposed directly to raw tables, ad hoc endpoints, or giant blobs of telemetry will do what models usually do under pressure: take shortcuts. It will query the recent past because that is faster than looking at the full trend. It will grab the easiest metric instead of the right one. It will confuse a machine’s classification with physical truth. It will answer before it has actually understood the operation.
That is why we built a Factory MCP layer.
Not because “MCP is trendy.” Because models need a better contract with reality.
Raw data is not the same as usable truth
Traditional operations produce data in awkward shapes.
The measurements come from different layers of the process:
- sorters classify
- weighers portion
- packers count finished bags
- ERP systems describe the commercial world
- people hold the missing interpretation in their heads
If you hand all of that to a model as raw access, the model still has to answer questions like:
- which source is authoritative for this question
- what time window matters
- what level of aggregation is safe
- which metric is only a machine decision, not real-world ground truth
- how this stage of the line affects the next one
That is not a data-access problem. That is an interface problem.
What the bounded layer does
The idea behind the Factory MCP is straightforward:
do not ask the model to improvise its own path through factory data if we already know the safe and meaningful ways to query it.
So instead of exposing raw internals, we expose bounded tools shaped around real operational questions:
- current factory status
- production over a range
- hourly behavior for a day
- quality behavior
- downtime and microstops
- shifts and comparisons
- machine comparison
- baseline and normal-range context
- alerts and runtime state
Each tool does several things at once:
- narrows the problem into a safe query pattern
- chooses the right source or merged sources underneath
- returns data at the right grain for reasoning
- keeps the access read-only
- preserves client scoping
That means the model spends less effort spelunking and more effort interpreting.
Why this matters in a factory specifically
A lot of AI infrastructure writing assumes data is already semantically clean.
Factory data usually is not.
A reject rate is often the machine’s decision to divert product, not objective truth about quality. A bag count is not a guarantee of good output. A machine stop is not just a status bit if it means another station will run dry twenty minutes later.
The model should not have to rediscover all of this from scratch on every query.
The bounded query layer lets us bake in the domain shape:
- what a metric really means
- which sources belong together
- where the blind spots are
- what must never be writable
- what “normal” even means in this operation
That is a much better starting point than “here are some tables, good luck.”
Why MCP, specifically
We like MCP for one practical reason: it makes the bounded layer portable.
Once the factory data is wrapped as a set of safe, domain-shaped tools, any MCP-capable consumer can use it:
- a conversational interface
- a studio-side debugging session
- an external AI client
- a future partner tool
That matters because we are not trying to build a sealed black box.
We want a world where the intelligence layer is composable. The client should not be trapped inside one UI just because the data interface is proprietary or fragile.
MCP gives us a standard way to expose the safe layer without exposing the raw guts.
The deeper idea is bigger than the protocol
The protocol is not the most important part.
The important part is the discipline behind it:
- models should see bounded tools, not unlimited internals
- domain meaning should be encoded into the interface
- the system should privilege safe read paths over improvised access
- different consumers should be able to share the same shaped understanding
That principle still matters even when an internal runtime talks to the data more directly than an external connector does.
The point is the same either way:
do not let the model invent its own understanding of the factory every single time.
Give it a better interface.
What this changes
Once you have a bounded data layer, the model stops acting like a tourist in the system.
It can still make mistakes. But the mistakes become narrower, more inspectable, and easier to correct. The reasoning gets anchored to the real operational questions instead of whatever shortcut was most convenient in the moment.
That is the real value of the Factory MCP.
It is not “AI access to data.”
It is a way to make models ask better questions, over better abstractions, with less room to drift away from the actual operation.
And in real industrial environments, that difference is not cosmetic. It is the difference between a clever demo and a system you can trust.