Loading ToolBench
MQTT-based IoT data collection and publishing server with FastAPI HTTP interface
Single tool 'handle_prompt' has critical definition gaps. Tool name is generic and does not follow verb_noun pattern (should be 'publish_mqtt_message' or similar). Description is present but vague, does not explain WHEN to use it, what prerequisites exist, or what the return value means. Input schema exists but lacks parameter descriptions (prompt parameter has no guidance on format, length, or expected values). No output schema documented. No error handling guidance. Tool appears to be a simple HTTP endpoint wrapper around MQTT publishing, not a proper MCP tool with structured composition.
Handles MCP prompt requests by mapping prompt keywords to MQTT topics and publishing messages
Tool name 'handle_prompt' is generic and does not start with a clear action verb. Should be 'publish_mqtt_message', 'send_mqtt_request', or similar to reflect the actual operation.
Input parameter 'prompt' lacks description. LLM cannot infer what format is expected, what keywords trigger which MQTT topics, or what happens if the prompt is empty or malformed.
No output schema documented. Response returns {status, published_to} but LLM does not know the structure, field types, or what to do with the published_to value.
Tool description does not explain WHEN to use it or what prerequisites exist (e.g., MQTT broker must be running, namespace_config.json must exist). No guidance on error recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 25 | 2026-07-28+ | v2 |
Hardcoded topic mapping logic ('if temperature in prompt → site1/line1/motor1/temp') is brittle and not exposed as a parameter. LLM cannot control which topic receives the message.