Loading ToolBench
MCP server for read-only Linux system administration, diagnostics, and troubleshooting
The Linux MCP server demonstrates solid foundational quality with 22 well-organized read-only tools. Strengths: consistent verb-noun naming (get_*, list_, read_*), all tools have descriptions, comprehensive parameter schemas with types, and thoughtful composition across system info, services, processes, logs, network, and storage domains. Weaknesses: descriptions are uniformly terse (averaging ~40-50 chars, well below production baseline of 194 chars), most parameter descriptions are minimal, output schemas are not explicitly documented, error handling guidance is absent from tool descriptions, and there is no indication of pagination support for tools that return lists (list_processes, list_services, list_connections could easily exceed context limits). The validate_script and run_script tools lack detail about gatekeeper approval flow and token expiration. Tool composition is clean (one responsibility each), but several discovery tools (list_*) need richer descriptions to guide agent behavior.
Get CPU information
Get disk usage information
Get the system hostname
Get the kernel version
Get memory and swap information
Get operating system information
Get detailed information about a process by PID
Get detailed status for a systemd service
Get system uptime
Descriptions are uniformly terse (40-60 chars). Production baseline is 194 chars. Terse descriptions lack context for LLM tool selection, especially for similar tools (e.g., list_processes vs get_process_info, read_journal vs read_log_file). LLMs cannot infer when to use which tool.
List tools (list_processes, list_services, list_connections, list_directory, list_block_devices) have no documented pagination, limit, or result-cap parameters. Without explicit limits, these tools can return unbounded results, exceeding context windows and degrading LLM reasoning. Production tools cap results at 20-50 items and offer pagination.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
List block devices on the system
List active network connections
List files and directories in a path
List ports listening for connections and their associated processes
List network interfaces and their configuration
List running processes
List systemd services with their state
Read the contents of a file
Read systemd journal logs with optional filters
Read a log file from the system (restricted to allowlisted paths)
Run a validated read-only script on the target system
Run a validated script that modifies the system (requires gatekeeper approval and needs_confirmation=true)
Validate a Python or Bash script via gatekeeper for security and policy compliance. Returns a token and needs_confirmation flag.
Output schemas are not explicitly documented for any tool. LLMs need to know what fields to expect in responses to plan downstream tool calls and extract relevant data. E.g., does list_services return [{ name, state, enabled }]? Does read_journal return { entries: [], total_count }?
No error handling guidance. Tool descriptions never mention what errors can occur, what to do if a resource is not found, or whether the tool is retryable. E.g., read_log_file says nothing about allowlisted path restrictions or what happens if the path is invalid. validate_script omits details about gatekeeper rejection scenarios.
Parameter descriptions are minimal or missing for most tools. E.g., 'host' parameter appears on every tool but is barely explained (just 'Optional remote host to execute on via SSH'). Does host accept IP, hostname, or SSH config name? What if the host is unreachable? What authentication is assumed?
validate_script and run_script tools lack clarity on the gatekeeper approval flow. Does validate_script always return a token, or can it reject the script? What does 'needs_confirmation' mean operationally? Can run_script_with_confirmation be called without explicit user approval, or does it block until approval arrives? Token expiration is not documented.
Tool naming inconsistency: run_script vs run_script_with_confirmation. The second tool name is compound and could be split into run_script (with optional 'confirm' param) or the naming convention for read-only vs write operations should be clearer (e.g., run_script_readonly vs run_script_write).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in schema. Modern MCP servers should mark tools with these hints so agents understand safety and retry semantics. All tools here are marked risk:READ_ONLY except run_script_with_confirmation (risk:WRITE), but this metadata is not exposed in the MCP schema.