Loading ToolBench
A Model Context Protocol server for executing commands in a persistent Kali Linux Docker container
The Kali Linux MCP server has 4 tools with reasonable naming and basic descriptions, but significant gaps in parameter documentation, schema completeness, and error handling. Descriptions are present but minimal (14-127 chars), and while input parameters are visible with types, they lack clarity on validation rules, constraints, and error recovery guidance. No output schema documentation. No tool annotations (destructive/read-only hints) despite managing irreversible operations. Average tool score: 52/100.
Restart the persistent Kali Linux container (useful if it becomes unresponsive).
Check the status of the persistent Kali Linux container.
Stop the persistent Kali Linux container to free up system resources.
Runs a shell command inside the persistent Kali Linux Docker container and returns the captured output.
No output schema documentation. Tools return string responses but do not declare the structure, format, or fields of the returned data. LLMs cannot reliably parse unstructured text or plan chained calls.
Missing tool annotations despite high-risk operations. kali-exec is marked IRREVERSIBLE (arbitrary command execution) but has no destructiveHint annotation. kali-container-restart and kali-container-stop modify state but lack idempotentHint/destructiveHint metadata. Agents cannot assess operation risk.
Minimal parameter descriptions lack validation constraints. 'The shell command to execute inside the container' does not warn about shell injection, quoting rules, or unsafe characters. Parameters accept arbitrary strings without documented boundaries or format rules.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error handling guidance in tool definitions. Descriptions do not explain what happens on invalid commands, missing containers, Docker daemon failures, or permission errors. Code throws exceptions (e.g., ArgumentException for empty command) but LLMs receive no recovery hints.
Short, generic tool descriptions (14 - 60 chars). 'Check the status of the persistent Kali Linux container' (59 chars) lacks context on WHEN to call it or what to do with the result. Descriptions should be 50-200 chars explaining purpose and typical usage.
Default parameter values could cause unintended side effects. removeContainer defaults to false in kali-container-stop (safe), but image defaults to 'kalilinux/kali-rolling' silently in kali-exec and kali-container-restart. If an agent passes a custom image, then re-calls without specifying it, behavior may diverge from intent.
No documented output fields or pagination. kali-exec returns 'captured output' but does not declare max length, encoding, or structure. Status commands return 'Container Status:\n{output}' (plaintext) without fields. Large outputs could exhaust context windows.