MCP Servers for Industrial Manufacturing: The Complete Guide (2026)
The Model Context Protocol (MCP) servers that let an AI agent reach into the plant floor — read live machine state, write setpoints, fire automations, audit work — without you writing a custom integration for every OEM stack. What MCP actually is for industrial, which servers are real today, which protocols matter, and what's still missing.
What MCP means on the plant floor
Model Context Protocol is a small, model-agnostic standard for how an AI client (Claude Desktop, Cursor, an agent framework) talks to a "tool server." The server advertises a set of tools, the client calls them, the server returns structured results. In a web context that's "search my notes" or "send an email." On the plant floor, those tools become read_register, activate_trigger, get_alarm_history, set_part_count_target, browse_opcua_tree. The protocol gives every agent the same surface; the server hides the OEM-specific gore.
The reason this matters now: every industrial integrator has built the same 15 connectors a hundred times — Fanuc FOCAS, Siemens S7, Haas NGC, Modbus over RTU, OPC UA, Mitsubishi MELSEC, MTConnect. MCP doesn't replace those drivers; it standardizes how a language-model reaches them. The unit of work shifts from "write a custom REST API per machine" to "wrap an existing driver as MCP tools, once." That's why this directory exists.
The protocols that matter (and the servers that speak them)
OPC UA — the modern lingua franca
Every PLC vendor shipped in the last decade exposes OPC UA either natively or through a gateway. It's the standard for cross-vendor industrial data exchange. The two servers worth pasting today are kukapay/opcua-mcp (Python, MIT, the most active community option) and the OPC UA pieces of midhunxavier/OPCUA-MCP (Python + Node, with an npm-published variant). Both expose read / write / browse against the OPC UA address space. If your DCS or SCADA already publishes via OPC UA, this is the highest-leverage starting point — one server, all your equipment.
Modbus — still half the world's equipment
Modbus TCP, UDP, and serial (RTU) still run an enormous fraction of installed PLCs, drives, energy meters, and retrofit panels. kukapay/modbus-mcp is the cleanest implementation — set MODBUS_HOST and MODBUS_PORT, point it at a gateway, and an LLM can read coils and registers without learning function codes. Realistic use cases: investigating an old field bus from a chatbot, retrocommissioning, energy-meter aggregation, brownfield migration audits.
OEM-specific stacks — Fanuc, Siemens, Haas, DMG Mori, …
The OEMs each ship their own SDKs: Fanuc FOCAS, Siemens S7 / TIA Portal, Haas NGC, DMG Mori Celos, Mazak SmoothLink, Okuma OSP-API. Some of these are showing up as community MCP servers (the T-IA Connect server for Siemens TIA Portal, for example, currently in PR against the awesome-mcp-servers list). The cross-OEM angle is what FoundryNet Forge takes — one MCP server that normalizes raw telemetry from 16 OEM families into a canonical schema, so an agent writes against one set of field names regardless of who built the machine.
Cloud-managed asset stacks — AWS IoT SiteWise
For teams standardized on AWS for OT data, the official AWS Labs MCP server for IoT SiteWise closes the loop. Asset modeling with built-in domain validation, time-series ingestion, anomaly detection, S3 bulk import/export, TwinMaker bridging. Auth is standard AWS IAM, which means access control reuses your existing posture and CloudTrail audit trail — the easiest "I already use AWS" path into an industrial AI workflow.
FoundryNet Forge — the cross-OEM option
Most servers in this category bind to a single protocol or OEM. FoundryNet Forge is the cross-manufacturer normalization layer: 11 tools wrapping a v1 API that handles identity (mint a stable machine ID across OEM serials), normalize (translate raw OEM column names like Spindle_Speed, servo_load_x, CoolantTemp into canonical spindle_speed_rpm, axes.x_load_pct, sensor_readings.coolant_temp from a corpus of 18,000+ field mappings), history queries, plain-English automations, and Solana-anchored on-chain settlement.
Pay-per-use metered billing — one CNC at 30-second sampling lands around $13/month, every 10s ~$40, every 1s ~$260; halve the cadence to halve the bill. A free fnet_ key gives 100 tool calls/month plus 10 fire_sandbox demos lifetime (full watch→fire→settle loop with real Solana settlement, no card). SSE transport, Bearer-key auth.
What's still missing
- Native MTConnect MCP servers. MTConnect is the dominant North American CNC data standard; there's no first-class MCP wrapper yet that exposes
SampleStream/EventStream/ConditionStreamidiomatically. - EtherCAT / Profinet bridges. Both are realtime, both ubiquitous, neither has a community MCP server. Likely a gateway-over-OPC-UA pattern is the practical workaround today.
- MES + ERP write paths. Reading from SAP or Oracle MES via MCP is plausible; writing back (creating work orders, posting completion) is unsolved in any production-quality way.
- Vibration / spectral analysis tools. Predictive-maintenance vendors (SKF, Brüel & Kjær) haven't published MCP wrappers; a community implementation against open formats (.cwa, .dat) would be high-leverage.
Picking one to start with
If your shop is OPC UA-friendly: kukapay/opcua-mcp, 10 minutes. If you're on legacy Modbus: kukapay/modbus-mcp. If you're on AWS for OT data: awslabs aws-iot-sitewise-mcp-server. If you have a mixed-OEM fleet and want one normalized view: FoundryNet Forge. Each takes <30 minutes from "git clone" or "uvx install" to a real machine answering a live LLM question.