Loading ToolBench
The server implements 4 tools with basic structure but significant quality gaps. Tool naming follows verb_noun pattern (get_*, clear_*, search_), which is good, but descriptions are minimal and lack context. Input schemas are present for all tools but lack depth, no descriptions for most parameters, missing validation constraints. Output schemas are entirely absent from tool definitions; the code returns JSON text rather than structured typed objects. Error handling is minimal with no recovery guidance. The server's actual domain challenge, browser console log capture, is undermined by a flawed architecture: the STDIO MCP server cannot directly access browser logs; it relies on a separate WebSocket listener (port 8765) that a browser extension must connect to. This two-component design is undocumented in tool descriptions, making it unclear to LLMs how the tools actually work. No tool describes this dependency or provides guidance for setup.
Limpia todos los logs almacenados
Obtiene todos los logs de la consola del navegador
Obtiene estadísticas sobre los logs capturados
Busca logs que contengan un texto específico
Output schemas completely absent. Tool definitions lack any documented return type or field structure. Code returns JSON strings, not typed objects. LLMs cannot plan downstream operations or validate what they'll receive.
Input parameter descriptions missing or minimal. 'query' in search_console_logs has description but 'level' lacks explanation of what it filters. 'limit' in get_console_logs has a description but no min/max bounds (e.g., is 1000000 allowed?). clear_console_logs and get_log_stats have no parameters described.
No error recovery guidance. If a tool fails (e.g., WebSocket not connected, logs unavailable), there is no actionable error message. Code silently catches errors (e.g., 'Error parsing log') and logs to stderr, but tool responses provide no context to the LLM on what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Destructive operation (clear_console_logs) lacks confirmation or dry-run support. No pattern:confirmation-request. Agent could irreversibly clear all logs without user approval. Description does not warn that this is destructive or irreversible.
Hidden dependency on external WebSocket server undocumented in tool descriptions. Tools require a browser extension to connect to ws://localhost:8765, but tool descriptions never mention this prerequisite. LLMs will invoke tools with no logs available and receive empty results, with no guidance on why or how to set up the dependency.
Tool descriptions lack context on when to use each tool. 'Obtiene todos los logs' (Get all logs) vs 'Busca logs que contengan un texto específico' (Search logs for specific text), descriptions do not explain why an LLM should prefer one over the other or in what sequence to call them.
No input validation or constraint documentation. 'limit' parameter has no documented min/max (baseline should be 1 - 1000 based on MAX_LOGS=1000). 'query' in search_console_logs has no length or character constraints. LLMs may pass invalid values without guidance.
Result limits not enforced or documented in tool descriptions. get_console_logs defaults to limit=100 but code enforces no upper bound on the limit parameter (could request all 1000 MAX_LOGS in one call, bloating response). Description should state 'limit: 1 - 1000, default 100'.