Loading ToolBench
MCP server for unified control of IoT devices (ESP8266, Raspberry Pi) with support for local development and Hostmidia production deployment
This MCP server exhibits critical deficiencies across naming, descriptions, and schemas. Tools are written in Portuguese with minimal documentation. Most parameter descriptions lack detail about constraints, ranges, or expected formats. Input schemas are present but many parameters are under-described. The codebase is fragmented across legacy files with no single canonical tool registration visible. Tool names like 'hello', 'test_connectivity' lack action-verb clarity. Critical issues include: (1) trivial descriptions like 'Diz olá' (Says hello) providing no context; (2) parameters with enum constraints but no descriptions explaining why those values matter; (3) no visible output schemas; (4) no error handling or recovery guidance; (5) inconsistent tool registration across multiple Python files suggesting incomplete refactoring. The server appears to be a learning project rather than production-ready.
Descobre dispositivos na rede
Para todos os dispositivos (emergência)
Pisca LED do ESP8266
Controla LEDs do ESP8266 (ligar, desligar)
Obtém status completo do ESP8266
Lê sensores do ESP8266
Status completo do sistema IoT
Critical: Most tool descriptions are under 20 characters and provide zero actionable context. 'Diz olá' (hello) and 'Teste de conectividade' (connectivity test) do not explain WHAT the tool does, WHEN to call it, or what it returns. Per the rubric, descriptions under 20 chars must score 0-20.
High: Parameter descriptions are missing or insufficient across all tools. Tools like 'esp8266_control_led' have enum values (on/off, red/green/blue) but no descriptions explaining what those enums control or why. LLMs cannot reason about parameter purpose without explicit descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Diz olá
Lista dispositivos disponíveis
Controla LEDs do Raspberry Pi (simulação)
Lê estado do botão do Raspberry Pi (simulação)
Lê sensores do Raspberry Pi (simulação)
Teste de conectividade com ESP8266
Critical: No output schemas documented for any tool. The rubric requires that 100% of A+ tools have documented return types. Without output schema, LLMs cannot plan downstream tool calls, extract fields for composition, or understand what data will be returned.
High: Weak tool naming. 'hello', 'test_connectivity', 'get_system_status' lack clarity. 'hello' does not convey an action; 'test_connectivity' is vague (test what? return success/failure?). The baseline shows 90% of A+ tools start with action verbs like get, list, create, search, update. These tools do not follow that convention.
High: No error handling or recovery guidance visible. No tool describes what to do if a device is unreachable, if a sensor read fails, or if an emergency stop is already active. The rubric requires error responses to say 'what to do next'. Current state: LLMs have no recovery path.
Critical: Tool definitions are scattered across legacy files (legacy/verify_mcp_tools.py, legacy/mcp_fastmcp2_correct.py) with no single canonical registration visible in source. The rubric penalizes inferred tool definitions (cap at 50). Without seeing explicit tool registration (e.g., @mcp.tool decorator or server.add_tool() calls), tool scores are capped at 50.
High: 'emergency_stop' is a destructive tool with no confirmation step, dry-run, or recovery guidance. The rubric requires irreversible operations to support confirmation. This tool should either (a) require a 'confirm=true' parameter, (b) document a 'revert_emergency_stop' tool, or (c) describe what exactly it stops and how to undo it.
Medium: Inconsistent naming convention across device-specific tools. 'esp8266_control_led' vs 'raspberry_control_led' follow a pattern, but 'hello', 'test_connectivity', and 'device_discovery' break the convention.