Loading ToolBench
A comprehensive DevOps diagnostic and monitoring MCP server providing system information, resource monitoring, process management, network diagnostics, and cloud provider integration (AWS, Azure, GCP, Kubernetes, Docker).
This DevOps diagnostics server has 9 tools with mixed quality. Naming is generally sound (verb_noun pattern: get_*, validate_*, list_, check_), but several critical issues emerge: (1) Descriptions are present but often generic and lack specificity about when to use a tool vs. alternatives. (2) Input schemas are visible for most tools, but many lack parameter descriptions or proper typing details. (3) Output schemas are NOT documented at all, tools return unstructured text strings rather than structured JSON, severely limiting agent composition and chaining. (4) Error handling is present but basic, errors are returned as plain strings without guidance on recovery steps. (5) The basic_greeting_test tool is a test/dummy tool that adds no business value. Overall, this is a functional server for system diagnostics but falls short of production-grade agent tool quality.
Test tool so I can test that this can properly be called from the client. (Claude Desktop)
Checks if a specific port is listening/open on the system. Returns whether the port is open and which process is using it. Essential for troubleshooting network services.
Checks if a specific process is currently running. Returns whether the process is running and lists matching PIDs. Helpful for verifying service status.
Monitors CPU usage and provides detailed CPU metrics. Returns per-CPU core usage percentages and overall CPU usage. Useful for identifying CPU bottlenecks and performance issues.
Analyzes disk usage for a specified path or mount point. Returns disk space statistics including total, used, and free space. Critical for preventing disk space issues.
Retrieves detailed memory usage statistics including RAM and swap. Returns total, available, used memory and percentages. Essential for diagnosing memory leaks and capacity issues.
No output schemas documented for any tool. All tools return unstructured text strings instead of structured JSON. This prevents downstream tool chaining and forces LLMs to parse text output, increasing errors and token waste.
Parameter descriptions are minimal or missing for several tools. For example, check_port_listening's 'port' parameter lacks range constraints (1-65535 implied but not stated). Descriptions do not explain format expectations or valid ranges.
Descriptions are generic and do not explain WHEN to call each tool or how it differs from similar tools. For example, get_cpu_usage lacks guidance: should an agent call this after get_system_info? How does it complement list_processes?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Retrieves comprehensive system information including OS, version, architecture, hostname, and uptime. Returns detailed system metrics useful for diagnostics and troubleshooting.
Lists currently running processes sorted by CPU usage. Returns top processes with PID, name, CPU%, and memory usage. Useful for identifying resource-intensive processes.
Validates a Dockerfile and checks for best practices. Uses 'hadolint' to validate the given Dockerfile. This looks for security risks and best practices in the actual Dockerfile.
Error handling is basic (plain text errors) and provides no recovery guidance. For example, validate_dockerfile returns 'hadolint' not installed error without suggesting remediation. Errors should guide the LLM on next steps.
basic_greeting_test is a test/placeholder tool with no production value. It should be removed to reduce cognitive load and improve signal-to-noise ratio for agent tool selection.
No enumeration constraints on parameters that accept discrete values. For example, validate_dockerfile path parameter could benefit from file existence validation upfront, and no enum guidance is provided.