Loading ToolBench
Industrial IoT service that provides MCP tools for reading points from industrial controllers via multiple transport protocols (HTTP, NATS PubSub, and MCP)
IIoT MCP server exhibits significant gaps in definition quality. While 5 tools are present with basic descriptions and input schemas visible in code, the quality is below production baseline. Tool naming follows verb patterns (CheckConnection, ListDrivers, Schema, Instruction, ReadPoints) but lacks clarity in some cases. Descriptions are present but brief (10-45 chars), falling below the 50-200 char optimal range. Input schemas are defined but parameters lack comprehensive type information in several tools. Error handling is marked as present but not evidenced in source code. No tool annotations visible. Parameter descriptions are minimal, most rely on single short phrases rather than actionable guidance. The server is STDIO-only, which is a hard transport cap of 50.
Checks connection to a network address
Retrieves usage instructions for a specified driver
Lists all available drivers in the IIoT service
Reads data points from an industrial controller via a specified driver
Retrieves the JSON schema for a specified driver
Tool descriptions are critically brief (10-45 chars), far below the 50-200 char baseline. Descriptions like 'Retrieves the JSON schema for a specified driver' (48 chars) lack WHEN to use, actionable context, and dependency hints that LLMs need for tool selection.
Tool names 'Schema' and 'Instruction' are ambiguous nominals without action verbs. 'Schema' could mean retrieve, validate, or generate. Should be 'get_driver_schema' and 'get_driver_instruction' to make intent self-evident.
Parameter 'ctx' in ListDrivers is typed as generic 'object' with nested 'edge_id' property, but lacks type constraint and actionable description. LLM cannot infer whether edge_id is required, an opaque UUID, or natural identifier.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
ReadPoints tool has complex nested schema (array of objects with name+value pairs). Description does not explain the semantics: does 'value' represent desired state, current reading, or a constraint? For IIoT context, this ambiguity is critical.
No output schemas documented for any tool. ReadPoints, Schema, Instruction, and ListDrivers do not specify what fields agents should expect in responses. LLMs cannot plan downstream operations without knowing return structure.
Error handling marked as present (errorReporting=true) but no error response schemas, recovery guidance, or error classification visible in source code. Tools likely return generic errors without actionable hints to guide LLM recovery.
No tool annotations present (toolAnnotations=false). ReadPoints and CheckConnection should declare readOnlyHint='true'. If delete/modify operations exist in future versions, destructiveHint and idempotentHint will be required for agent safety.
Parameter 'network' in CheckConnection lacks enum constraint or format specification. Description is just 'The network type', LLM cannot infer valid values (TCP? UDP? HTTP? websocket?). Should either list valid enums or provide regex/format constraint.