Loading ToolBench
MCP server for reading and controlling industrial devices — the USB-C interface for your plant floor
industrial-mcp has well-structured tool definitions with clear, detailed descriptions (avg 180+ chars) and proper parameter typing. All 5 tools follow verb_noun naming (list_devices, read_device, set_speed, start_device, stop_device). However, input schemas lack formal constraints (enums, ranges, patterns), parameter descriptions are present but could be more prescriptive about valid ranges and formats, and output schemas are not documented. Error handling guidance is absent, tools do not indicate what to do if a device_id is invalid or if a write operation fails. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels (READ_ONLY vs WRITE). Missing pagination for list_devices despite potential for large device counts.
List all registered industrial devices with their current status. Returns a summary of every device managed by this MCP server, including device ID, name, type, communication protocol, current operational status, and the latest telemetry snapshot (temperature, speed, pressure, vibration, etc.). Use this tool when you need an overview of the entire plant floor or when you want to discover which devices are available before reading detailed data from a specific device.
Read live telemetry data from a specific industrial device. Retrieves the full real-time data snapshot for the given device, including all sensor readings (temperature, pressure, speed, vibration, flow rate, power consumption, etc.) and the device's current operational status.
Set the speed / setpoint of an industrial device. For motor-type devices this sets the speed setpoint in RPM. For other devices (pumps, valves) it writes to the primary writable control register. The value is automatically clamped to the device's safe operating range (typically 0–3000 RPM for motors).
Start an industrial device. Sets the device's control register to its nominal operating value, which begins the physical simulation (motor spins up, pump starts flowing, etc.). The device transitions from STOPPED → STARTING → RUNNING.
Input schemas lack formal constraints. device_id is typed as string but has no enum, pattern, or format constraint. speed parameter has no min/max bounds despite description mentioning 0 - 3000 RPM clamping. LLMs cannot infer valid ranges from descriptions alone.
Output schemas not documented. list_devices returns list[dict[str, Any]], read_device returns dict[str, Any]. LLMs cannot plan downstream tool calls or extract specific fields without knowing the response structure (e.g., does read_device return 'temperature' or 'temp'? 'device_status' or 'status'?).
No error recovery guidance. Tools do not document what happens if device_id is invalid, if a device is offline, or if a write operation fails. Descriptions lack 'If device not found, call list_devices() first' hints. Agents cannot self-correct on failures.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Stop an industrial device. Sets all writable control registers to zero, causing the physical simulation to ramp down. The device transitions from RUNNING → STOPPING → STOPPED. Use this for normal shutdowns. For emergency situations, use the ``emergency_stop`` prompt template.
Tool annotations missing. set_speed, start_device, and stop_device are marked WRITE (destructive) but lack destructiveHint annotation. list_devices and read_device are READ_ONLY but lack readOnlyHint. Annotations enable clients to warn users before executing destructive operations.
list_devices lacks pagination. No limit, offset, or page_size parameters. If the plant floor has hundreds of devices, returning all in one response wastes tokens and risks context window exhaustion. Should accept limit (default 20) and offset/cursor.