MCP server for controlling Kali Linux Docker container from Claude Desktop
This server defines 4 tools with basic MCP structure, but has significant quality gaps. All tools have descriptions and visible schemas, but descriptions are generic and lack actionable guidance. Parameter descriptions are minimal. Output schemas are not documented, the response structure is defined inline but not formalized. Error handling is absent, callers get raw stdout/stderr or generic errors with no recovery guidance. The run_kali_command tool is particularly risky: it accepts arbitrary shell commands with minimal validation, poses command injection risks, and lacks any warning in the description about destructive capabilities. Tool naming follows verb_noun pattern (good), but descriptions are too brief (average ~60 chars, below the 194 char baseline) and lack WHEN/WHY context. No per-parameter descriptions for critical inputs like 'command' and 'filename'. No documentation of response structure, pagination, or error cases. Overall, this reads as a proof-of-concept rather than a production-grade tool suite.
Check if the Kali Docker container is running and get status information
Retrieve results from previous scans stored in /root/scans
List available VAPT tools installed in the Kali container
Execute a command in the Kali Linux Docker container. Use this to run VAPT tools like nmap, sqlmap, metasploit, etc.
run_kali_command accepts arbitrary shell commands with no input validation, sanitization, or injection protection. Description does not warn about destructive capability (e.g., 'rm -rf /', container termination). This violates secure tool design patterns.
Output schemas are not documented. Tools return text content inline, but callers cannot determine field structure, expected data types, or how to chain results to subsequent tools. This violates response-shaper pattern.
No error handling or recovery guidance. Raw errors (stderr, Docker command failures, file not found) are returned as plain text with no classification, actionable next steps, or suggestion of alternative tools to try.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Descriptions are too brief (30-70 chars) and lack WHEN/WHY context. Average baseline is 194 chars. E.g., 'Execute a command in the Kali Linux Docker container' does not explain when to use run_kali_command vs list_kali_tools, what prerequisites exist, or what happens on failure.
Parameter 'command' in run_kali_command has minimal description and no constraints or format guidance. Description should specify: 'Enter a valid Kali command (e.g. nmap, sqlmap). Avoid destructive commands (rm, dd, etc). Paths are relative to /root. Commands run as root.'
Parameter 'filename' in get_scan_results has no format guidance, path constraints, or error indication for file-not-found. Should specify: 'Name of file in /root/scans. Relative paths only (no ../ traversal). Returns 404 if missing.'
container_status tool returns no schema definition. Response structure (status field, boolean running flag, etc.) is not documented, forcing callers to infer output format from trial.
No pagination or result-limiting for list_kali_tools. If this tool were to query a large registry, it could return thousands of tools and blow the context window. Should document 'Returns up to 100 tools per category. Use category filter to narrow results.'