The onset of artificial intelligence (AI) in the industrial world is driving different communications standards between clients and servers, between nodes, between agents. There are numerous ways to describe things, and the AI world is making its own language. One of the newest occurrences is model context protocol (MCP).

Before discussing MCP, let’s review what a protocol is. A basic definition of protocol is that it is a set of rules on how “things” communicate. Even people have a protocol when introducing themselves and sharing information, so machines would of course mimic their creators.

Core parts of a protocol include syntax, semantics, synchronization and error recovery. Thus, if AI is making its own language and concepts, it is only fitting that new protocols would be derived to set communication boundaries between AI applications and field equipment.

For instance, take the network knowledge you have and picture an AI interface at the cloud, and then imagine a middle layer that allows the operational industrial network to talk to the cloud applications. The AI agent is the traffic cop that uses MCP to decipher the inputs from the voice-command application and then sends the information to the PLC or robot for command execution (Figure 1).

The AI application layer is the client. The MCP and agent layer use JavaScript object notation remote procedure call (JSON-RPC) data to expose the PLC or robot capabilities to the AI. This allows the AI to have a PLC and robot as a tool in the AI toolbox, so to speak.

A non-robot example would be a text message: “Read oil temperature sensor 15” or “Stop motor 3.” The agent converts that message to explicit register addresses and I/O paths with structured data blocks. Then it can output to the OT side using OPC UA, MQTT, Modbus TCP or Ethernet IP.

What does that mean for machine builders and automation software providers? It adds another level of complexity. However, it also allows MCP mapping to allow edge clients to talk directly to Siemen S7, Rockwell ControlLogix, Beckhoff TwinCAT or Schneider over Modbus TCP. Another way to describe the network layers is context request from the IT layer where the AI application is, translation matrix for the middle layer where the MCP manager resides, and then Fieldbus dispatch is the third layer, on the operational floor.

The first question someone will ask about MCP is: “How fast is it?” The speeds will not be faster than the floor operations. The hardware loop still needs to stay below 10 milliseconds. The agent node adapter target response is 2 to 7 milliseconds. The overhead for the MCP layer is expected to be 10 to 100 milliseconds. Structured JSON-RPC overhead for text payloads and transport delay may be compensated with an optimized MCP architecture. In IT speech, this is a JSON-RPC.

JSON code example for reading a temperature probe:

{ "jsonrpc": "2.0",

 "method": "read_plc_sensor",

 "params”: {"sensor_id": "temp_probe_04" },

 "id": 1

}

Server to the client response:

{ "jsonrpc": "2.0",

 "result": { "temperature_celsius": 24.7 },

 "id": 1

}

Get your subscription to Control Design’s daily newsletter.

In the context of using the MCP with an AI agent to talk to PLCs, an operational loop might change to look like this (Figure 2):

1. The AI app speaks JSON-RPC to describe what it wants to accomplish conceptually—for example, "Read the temperature sensor."
2. The MCP server and agent receive this JSON-RPC text packet, parse the string data and translate it into high-level PLC logic.
3. The PLC compiler converts that logic into machine-language binary blocks.
4. The PLC processor runs those binary blocks at microsecond speeds to physically open a valve, read a voltage pin or turn a motor spindle.

In short, the AI generates a textual command, the agent parses the data to speak PLC, the PLC compiler changes it to a machine language and then the processor runs the binary blocks to read a voltage or amperage and then signal to turn on a motor spindle (Figure 3).

The next important question for control systems engineers is: Can the AI talk directly to the machine? Not without the MCP translation layer using an agent. The MCP cannot bypass the middleware layers. Why do we care? Cybersecurity, of course. Remember Skippy the sentient AI in Craig Alanson’s Expeditionary Force?

There are fail safes. The PLC can have safety checks to validate incoming AI parameters before outputting. Security firewalls can be implemented, as well. Regardless, MCP is a big addition for protocol technology. If AIs have their own paths to communicate, then they can be handled separately from safety and operations.

The same thoughts have been applied in the safety realm to verify safety conditions and to keep safety processing separate from machine actions, but with the ability to halt the machine if the safety system finds a problem. Picture being able to run machine systems with their own communications back to the brain, and then PLC processing can become a lot more efficient. As if sub-10 ms is not enough. Protocols make this possible. MCP is most likely just the start.