Loading ToolBench
MCP server for SRE operations across multiple platforms via SSH
This MCP server defines 7 tools with READ_ONLY risk profiles across SRE/DevOps domains (Docker, monitoring, health, logs, Unraid). Tool names follow verb_noun patterns (container_topology, docker, health, log, monitoring, performance, unraid) which is good. However, schema documentation is inconsistent: the container_topology tool has explicit Zod schema definitions visible in source, but docker, health, unraid tools are registered only in package.json without visible schema definitions in the provided source snippets. Descriptions are present but terse (7 - 15 words), below the 50 - 200 char baseline for A-grade tools. Parameter descriptions exist but many are minimal (e.g., 'Container', 'Device', 'Action'). Output schemas are not documented, callers cannot predict response structure. Error handling is mentioned (errorReporting=true) but no recovery guidance is visible in the code samples. Overall, the server is functional and reasonably organized, but lacks the depth of description and output documentation expected for production-grade agent tools.
Container topology ops.
Docker ops.
Health ops.
Log analysis ops.
Monitoring ops.
Performance ops.
Unraid array/storage ops. Actions: array_status (state), smart (drive diag), temps (all temps), shares (list), share_usage (disk usage), parity_status/parity_history (parity info), sync_status (rebuild), spin_status (spin state), unclean_check (shutdown), mover_status/mover_log (mover), cache_usage, split_level (share cfg).
Missing input schemas for 6 of 7 tools (docker, health, log, monitoring, performance, unraid). Schema definitions not visible in provided source code; only tool names and descriptions appear in package.json. Cannot verify parameter types, constraints, defaults, or validation.
Tool descriptions are terse (7 - 15 words). Baseline for A-grade tools is 50 - 200 chars. Current descriptions like 'Docker ops.', 'Health ops.', 'Monitoring ops.' lack context for when to use each tool and what data is returned. LLMs cannot infer dependencies or error recovery paths.
Parameter descriptions are minimal and generic. Examples: 'Container', 'Device', 'Action', 'Filter'. Do not explain what values are valid, format constraints, dependencies, or when each parameter is required vs optional. LLMs will guess, leading to invalid invocations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
No documented output schemas. Tools return structured text or JSON parsed from shell commands, but the expected response format is not declared. Agents cannot plan downstream tool calls or extract specific fields without trial-and-error parsing.
No error handling guidance visible. Tools execute shell commands via SSH with no documented recovery paths. If a command fails (e.g., 'docker: command not found', permission denied), agents have no fallback strategy.
container_topology has a complex schema with conditional parameters (type, host, fromContainer, dnsServer only valid for network_test action), but these dependencies are not documented in parameter descriptions. LLMs may pass invalid parameter combinations.
Unraid tool description is unusually long (250+ chars) and written as a comma-separated action list rather than prose explaining when/why to use the tool. Tool name 'unraid' is not verb_noun; 'manage_unraid_storage' or 'query_unraid_array' would be clearer.