Loading ToolBench
AI-to-hardware gateway. WoT Thing Description → MCP tools. Let AI agents safely control sensors and actuators.
ThingWire compiles WoT Thing Descriptions into MCP tools with reasonable naming (verb_noun pattern: read_*, do_*) and basic descriptions. However, critical gaps undermine production readiness: (1) Most tool descriptions are extremely brief (10-30 chars), well below the 50-200 char LLM-optimized baseline. (2) Input schemas are present but minimal, parameters lack detailed descriptions explaining constraints, formats, or dependencies. (3) No output schema documentation, LLMs cannot infer what fields to expect from tool responses. (4) Error handling is absent, no guidance on retryability, user-fixable vs fatal errors, or recovery paths. (5) Security considerations (audit logging, permission gates) are mentioned in code but not surfaced in tool definitions. The tool_compiler.py shows thoughtful design (safe/idempotent flags, dangerous action prefixes), but this metadata is not exposed to the LLM via tool annotations.
⚠️ PHYSICAL ACTION — Turn relay on or off. Controls a physical device connected to the relay.
Get recent command audit log entries.
Get detailed status for a specific device.
List all discovered ThingWire devices and their status.
Read humidity. Returns number in percent.
Read motion. Returns boolean.
Read temperature. Returns number in celsius.
Tool descriptions are critically brief (10-30 chars). Baseline for LLM-optimized descriptions is 50-200 chars. Short descriptions lack context for tool selection and force LLMs to guess when to call each tool.
No output schema documentation. LLMs cannot infer what fields read_temperature, read_humidity, read_motion, or list_devices return. This forces agents to guess field names and types, increasing errors and wasting tokens on trial-and-error.
Input parameter descriptions are missing or minimal. do_set_relay has a 'state' parameter with a description, but other tools with optional parameters (get_audit_log: device_id, limit) lack guidance on format, range, or constraints. LLMs cannot infer valid values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | <=2025-11-25 | v2 |
No error handling guidance. Tool definitions do not indicate which errors are retryable, which are user-fixable, or what recovery steps to take. Agents will not know how to respond to failures.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not exposed in MCP tool definitions. The tool_compiler.py tracks safe/idempotent flags internally, but these are not surfaced to the LLM via MCP protocol, limiting agent reasoning about side effects.