Loading ToolBench
MCP Server for Kali Linux Docker container
This server defines 17 security tools with basic schemas and descriptions, but exhibits multiple critical gaps. While tool names are reasonably clear action verbs (run_, start_, stop_, install_, scan_, gather_), descriptions are present but minimal (averaging ~50-80 chars, well below the 194-char baseline for production tools). Most critically, output schemas are completely undocumented, the code shows no documentation of what these tools return, forcing LLMs to infer result structure. Parameter descriptions exist but lack depth: for example, 'kali_web_scan' accepts an 'options' string with no constraint on valid values, 'tool' parameters lack enums despite accepting specific tooling options (nikto, dirb, gobuster, sqlmap, etc.), and error handling is absent. No parameter types are explicitly validated. The 'run_kali_command' tool is particularly concerning, it accepts arbitrary shell commands with no sanitization, creating a direct injection vector if an LLM is prompted maliciously. Security-sensitive operations (password_crack, wireless_tools, web_scan) lack permission gates or audit declarations. Descriptions do not explain WHEN to use each tool vs. alternatives, making agent tool selection ambiguous. Per the hard rules: all tools have descriptions and schemas are present, but schema completeness is poor (no output documentation, no enums for tool/scan_type parameters, minimal constraint documentation).
Install a package in Kali Linux using apt
Check if Kali container is running
Cryptography and encoding tools
CTF-specific tools for capture the flag challenges
Digital forensics tools
Gather information about target (whois, dns, etc.)
Perform a network scan using Kali tools
No output schemas documented for any tool. LLMs cannot infer what these tools return (e.g., does kali_network_scan return port lists, service versions, or raw nmap output?), forcing agents to blindly chain outputs or attempt to parse unstructured data.
'run_kali_command' accepts arbitrary shell commands with no sanitization, validation, or input constraints. This is a direct command injection vulnerability if an LLM is prompt-injected to pass malicious payloads. No error messages guide recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Password cracking tools
Advanced reverse engineering and binary analysis tools
Scan for open services on target
Scan for vulnerabilities using Kali tools
Web application security scanning
Wireless network analysis tools
Execute a command inside the Kali Linux container
Start the Kali Linux container if not running
Stop the Kali Linux container
Update Kali Linux system packages
Parameters accepting specific tool names ('tool' in kali_web_scan, kali_password_crack, etc.) are declared as free-form strings instead of enums. LLMs will hallucinate invalid tool names (e.g., 'sqlmap2', 'hashpump') causing tool failures. Examples: 'tool' in kali_web_scan should enum ['sqlmap', 'dirb', 'nikto', ...]; 'scan_type' in kali_network_scan should enum ['nmap', 'masscan'].
No error handling or recovery guidance. The code provides no description of what errors are possible (e.g., container not running, command timeout, tool not installed) or what the LLM should do next.
Descriptions are too brief (average ~50-80 chars, baseline is 194 chars). They state WHAT the tool does but omit WHEN to use it, prerequisites, and how to distinguish it from related tools. Example: 'kali_information_gathering' says 'Gather information about target (whois, dns, etc.)' but does not explain when to use this vs. kali_vulnerability_scan or kali_web_scan, or that it requires internet connectivity.
Destructive/sensitive operations (password_crack, web_scan, wireless_tools) lack permission gates, security declarations, or audit guidance. No indication of what permissions an agent needs to invoke these tools, or that they should be logged for compliance.
Optional parameters lack clear guidance on defaults and side effects. Example: 'workdir' in run_kali_command defaults to '/root' but no description of what this means if omitted, or whether changing it affects state. 'options' in multiple tools is optional but undocumented, what happens if omitted?
No indication of which operations are idempotent vs. irreversible. Descriptions for container management and system updates do not state whether repeated calls are safe or destructive. Agents need to know this to plan retries safely.
No pagination or result limits documented. Tools like 'kali_network_scan' or 'kali_information_gathering' could return hundreds of results (open ports, DNS records, etc.). No limit param, no cursor/offset, no guidance on max result count. Large uncapped results blow context windows.