Mechanically it is three hops: get the tags off the PLC, turn them into something with stable names and units, and expose that to the model. The first and third hops are well-trodden. The middle one is where projects stall.
Getting tags off. A Siemens S7 is reachable over S7comm on TCP 102 or over the OPC UA server in newer firmware. A Rockwell Logix controller exposes named, typed tags over EtherNet/IP. A generic PLC almost always speaks Modbus TCP. All three are solved by existing libraries; none of them requires anything clever.
The middle hop. What comes off the PLC is DB100.DBD24 or Tag_47 or register 40071. A model cannot reason about that, and neither can a person six months later. Worse, the same physical measurement on the machine next to it is called something else, so anything the model learns about one machine does not transfer. This is the actual work: stable names, declared units, and a value you can trust — the sign convention right, the scaling applied, and out-of-range readings rejected instead of stored.
Exposing it. Once the data is canonical, an agent can reach it over a normal API, or over MCP if you want the model to call it as a tool. Forge exposes both — a REST API and an MCP endpoint with 32 tools — so an assistant can ask for a fleet's spindle load without knowing that four of those machines are Fanuc and three are Siemens.
One caution worth stating plainly: frontier models are good at decoding public protocols on their own. Handed a raw Marlin or Modbus payload, they will often work out what it is. The argument for normalizing is not that the model cannot read the data — it is that a model spending its attention on byte order is not spending it on your problem, and that nothing it concludes about one machine transfers to the next one.
Often yes — frontier models decode public protocols like Modbus or Marlin unaided. The problem is not comprehension, it is that raw tags do not transfer between machines, so nothing the model learns about one asset applies to the next.
Read-only, through a normalization layer, never directly onto the control network. MTConnect is read-only by design; for anything else, mediate through a service that cannot write.
No — a REST API works. MCP is useful when you want the model to discover and call the capability as a tool rather than you writing the call.