AI assistants can decompose multi-step workflows, but they do not natively speak industrial protocols such as Modbus, MQTT/Sparkplug B, or OPC UA, so this paper presents INDUSTRICONNECT, a prototype suite of Model Context Protocol (MCP) adapters that expose industrial operations as schema-discoverable AI tools while preserving protocol-specific connectivity and safety controls; the system uses a common response envelope and a mock-first workflow so adapter behavior can be exercised locally before connecting to plant equipment, and a deterministic benchmark covering normal, fault-injected, stress, and recovery scenarios evaluates the flagship adapters, comprising 870 runs (480 normal, 210 fault-injected, 120 stress, 60 recovery trials) and 2820 tool calls across 7 fault scenarios and 12 stress scenarios, where the normal suite achieved full success, the fault suite confirmed structured error handling with adapter-level uint16 range validation, the stress suite identified concurrency boundaries, and same-session recovery after endpoint restart is demonstrated for all three protocols, with results providing evidence spanning adapter correctness, concurrency behavior, and structured error handling for AI-assisted industrial operations.
Figures & tables
Fig. 1: IndustriConnect adapter architecture. An AI assistant issues MCP tool calls through a common JSON-RPC interface. The adapter layer handles protocol translation and safety guards, returning a shared response envelope. Each protocol adapter targets either a local mock (dashed) or real plant equipment.
Field
Role in the adapter contract
success
Reports whether the requested protocol action reached the expected outcome.
data
Carries the protocol-specific payload such as registers, node values, or publish metadata.
error
Preserves a machine-readable failure reason, including guarded denials and transient endpoint failures.
meta
Records wall-clock latency, endpoint details, attempts, and protocol-specific trace context.
TABLE I: Shared response-envelope fields used across the benchmarked adapters.
Protocol
Tools
Mock
Status
Rep. operation
Modbus
17
TCP device
flagship
register/coil I/O
MQTT + SB
15
broker sim.
flagship
pub/sub + DDATA
OPC UA
7
UA server
flagship
browse + node R/W
BACnet/IP
7
BA device
scaffold
object properties
DNP3
8
outstation
scaffold
point poll/control
EtherCAT
14
slave
scaffold
PDO/SDO access
TABLE II: Repository protocol inventory. Tool counts come from registered handlers in the benchmark pass. 2 2 2 Protocols below the mid-rule are not evaluated in this paper.
Fig. 2: Repository protocol landscape with the three evaluated flagship adapters highlighted. This figure is supporting context, not evaluation evidence.
Fig. 3: MCP Manager UI used to register adapters and issue operator-style prompts. This figure is supporting context, not benchmark evidence.
Publish to empty topic (FQ1); subscribe with invalid QoS (FQ2)
TABLE III: Benchmark matrix for the deterministic evaluation.
Family
Mock endpoint
Recovery semantics
Modbus
TCP mock at 127.0.0.1:1502
Same-session via pymodbus auto-reconnect, then fresh session
MQTT/SB
Local broker at 127.0.0.1:1883
Same-session via paho reconnect_delay_set , then fresh session
OPC UA
Local OPC UA endpoint
Same-session via _ensure_connected() liveness probe, then fresh session
TABLE IV: Benchmark runtime configuration used in the paper.
Family
Tasks
Task
Tool
Med.
p95
Rec.
(%)
(%)
(ms)
(ms)
(%)
Modbus
4
100.0
100.0
1.4
3.1
100.0
MQTT
4
100.0
100.0
1.7
2.5
100.0
OPC UA
4
100.0
100.0
7.3
105.2
100.0
Cross-protocol
4
100.0
100.0
6.7
8.7
—
TABLE V: Family-level results from the normal benchmark suite (30 repetitions). Cross-protocol rows aggregate the four multi-adapter tasks.
ID
Family
Operation
Median (ms)
p95 (ms)
M1
Modbus
Ping the adapter and confirm the TCP mock is reachable.
1.1
1.4
M2
Modbus
Read a four-register sensor block from the Modbus mock.
1.5
1.7
M3
Modbus
Write a holding register and read it back for verification.
2.7
3.3
M4
Modbus
Attempt a write with writes disabled and expect a guarded rejection.
1.3
1.6
Q1
MQTT
Inspect broker connectivity through the MCP adapter.
1.8
2.1
Q2
MQTT
Subscribe to the mock sensor topic namespace.
1.7
2.7
TABLE VI: Per-task latency breakdown from the normal benchmark suite (30 repetitions).
Fig. 4: Per-task latency distributions across 30 repetitions. Box plots show median, interquartile range, and outliers.
ID
Family
Fault scenario
EH%
Med. (ms)
Error class
FM1
Modbus
Read invalid register address (9999) and expect a structured protocol error.
100.0
1.3
protocol error
FM2
Modbus
Write overflow value (70000 ¿ uint16 max) and expect adapter rejection.
100.0
1.0
range overflow
FQ1
MQTT
Publish to empty topic string and expect a structured invalid-input error.
100.0
1.6
invalid input
FQ2
MQTT
Subscribe with invalid QoS (5) and expect a structured invalid-input error.
100.0
1.6
invalid input
FO1
OPC UA
Read non-existent node (ns=2;i=99999) and expect a structured read-failed error.
100.0
2.7
illegal address
FO2
OPC UA
Write wrong type (string to float node) and expect a structured write-failed error.
100.0
2.5
protocol error
TABLE VII: Fault-injection task results (30 repetitions). Error-handling rate measures how often the adapter returned a well-formed structured error.
Fig. 5: Error class distribution across the seven fault-injected tasks (30 runs each). Each color represents a distinct error category returned by the adapter.
Fig. 6: Recovery success rates over 60 restart trials per flagship adapter, comparing same-session recovery (adapter reconnects transparently) versus fresh-session recovery (new MCP session).
Fig. 7: Recovery-phase breakdown per flagship adapter.
The Model Context Protocol (MCP) standardizes how AI agents discover and invoke external tools, with over 10,000 active servers and 97 million monthly SDK downloads as of early 2026. Yet MCP does not yet standardize how agents safely operate those tools at production scale. Three protocol-level primitives remain missing: identity propagation, adaptive tool budgeting, and structured error semantics. This paper identifies these gaps through field lessons from an enterprise deployment of an AI agent platform integrated with a major cloud provider's MCP servers (client name redacted). We propose three mechanisms to fill them: (1) the Context-Aware Broker Protocol (CABP), which extends JSON-RPC with identity-scoped request routing via a six-stage broker pipeline; (2) Adaptive Timeout Budget Allocation (ATBA), which frames sequential tool invocation as a budget allocation problem over heterogeneous latency distributions; and (3) the Structured Error Recovery Framework (SERF), which provides machine-readable failure semantics that enable deterministic agent self-correction. We organize production failure modes into five design dimensions (server contracts, user context, timeouts, errors, and observability), document concrete failure vignettes, and present a production readiness checklist. All three algorithms are formalized as testable hypotheses with reproducible experimental methodology. Field observations demonstrate that while MCP provides a solid protocol foundation, reliable agent tool integration requires infrastructure-level mechanisms that the specification does not yet address.
AI for Industrial Asset Lifecycle Management aims to automate complex operational workflows, such as condition monitoring and maintenance scheduling, to minimize system downtime. While traditional AI/ML approaches solve narrow tasks in isolation, Large Language Model (LLM) agents offer a next-generation opportunity for end-to-end automation. In this paper, we introduce AssetOpsBench, a unified framework for orchestrating and evaluating domain-specific agents for Industry 4.0. AssetOpsBench provides a multimodal ecosystem comprising a catalog of four domain-specific agents, a curated dataset of 140+ human-authored natural-language queries grounded in real industrial scenarios, and a simulated, CouchDB-backed IoT environment. We introduce an automated evaluation framework that uses three key metrics to analyze architectural trade-offs between the Tool-As-Agent and Plan-Executor paradigms, along with a systematic procedure for the automated discovery of emerging failure modes. The practical relevance of AssetOpsBench is demonstrated by its broad community adoption, with 250+ users and over 500 agents submitted to our public benchmarking platform, supporting reproducible and scalable research for real-world industrial operations. The code is accesible at https://github.com/IBM/AssetOpsBench .
Dhaval Patel, Shuxin Lin, James Rayfield +7
IBM · University of South Carolina · Steel Authority of India +1
We ask whether AI agents powered by locally deployed large language models can reliably automate expert-defined hardware design workflows in an industry-realistic tool-calling setting. In these environments, engineers issue repetitive, dependency-ordered operations---such as creating components, adding ports, and wiring connections---through specialised tools. Confidentiality constraints on component specifications and naming conventions often preclude hosted proprietary APIs, motivating the use of locally deployed models. To study this setting, we build a Model Context Protocol (MCP) server that reproduces the state and dependency logic of a proprietary hardware design tool used in embedded system development and construct a benchmark covering single-operation edits, multi-step dependency chains, invalid requests, misspelled prompts, and multi-server tool contexts. We evaluate seven open-source models comparing pipeline choices including system prompts, tool-description detail, context scope, and single-agent versus multi-agent architectures. Results show that strong models can achieve near-complete expected-call coverage on the benchmarked workflows, but reliability depends strongly on both task structure and agent configuration. Comprehensive tool descriptions consistently reduce failures, few-shot prompting can cause severe inaction for some models, cumulative context harms constrained models, and multi-agent decomposition helps weak workers or long sessions at the cost of additional calls. These findings provide practical guidance for deploying local LLM agents in stateful hardware design environments.