Manages the Kali Linux container environment via the Docker API, allowing for starting, stopping, and executing commands inside the container.
Provides access to a full Kali Linux environment, enabling AI agents to run security tools like nmap, sqlmap, and nikto for penetration testing.
Enables the execution of arbitrary shell commands and file management tasks within a containerized Linux environment.
Allows the use of the Metasploit Framework for security assessments and exploit development.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kali-mcp Run an nmap scan on 192.168.1.5 to find open ports"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI assistants access to a full Kali Linux environment running in Docker. Connect it to Claude Desktop, Claude Code, or any MCP-compatible client and let the AI run security tools like nmap, sqlmap, hydra, nikto, gobuster, and more.
Claude <--stdio--> MCP Server <--Docker API--> Kali Linux ContainerThe MCP server manages a Docker container running Kali Linux. It exposes tools that let the AI start/stop the container, execute commands, and transfer files — all through the Model Context Protocol.
Related MCP server: Kali MCP Server
Tool | Description |
| Start the Kali Linux container |
| Stop and remove the container |
| Check if the container is running |
| Run any shell command inside Kali |
| Write a file to the container |
| Read a file from the container |
| List directory contents |
nmap, nikto, gobuster, sqlmap, hydra, john, hashcat, metasploit-framework, dirb, enum4linux, curl, wget, python3, wordlists, and more.
Node.js v18+
Docker Desktop (must be running)
git clone https://github.com/Hannes221/kali-mcp.git
cd kali-mcp
npm install
npm run buildcd docker
docker compose build
cd ..This downloads and builds the Kali Linux image (~4GB). It takes a few minutes on the first run.
Open Settings > Developer > Edit Config and add the kali server to your claude_desktop_config.json:
{
"mcpServers": {
"kali": {
"command": "node",
"args": ["/absolute/path/to/kali-mcp/dist/index.js"]
}
}
}Replace /absolute/path/to/kali-mcp with the actual path where you cloned the repo.
Then restart Claude Desktop.
If you cloned the repo, the .mcp.json file is already included. Just open the project directory in Claude Code:
cd kali-mcp
claudeOr add it manually to your Claude Code config:
claude mcp add kali node /absolute/path/to/kali-mcp/dist/index.jsIn a conversation, ask the AI to:
Start the Kali container and run
nmap --version
It should call container_start, then execute_command with nmap --version and return the version output.
Once connected, you can ask the AI things like:
"Scan 192.168.1.0/24 for open ports"
"Run nikto against http://target.com"
"Use sqlmap to test http://target.com/page?id=1 for SQL injection"
"Crack these hashes with john"
"Enumerate SMB shares on 10.0.0.5"
The AI will use the appropriate Kali tools and interpret the results for you.
npm run dev # Run with tsx (auto-compiles TypeScript)
npm run build # Compile to dist/
npm start # Run compiled versionEdit docker/Dockerfile to add or remove tools, then rebuild:
cd docker
docker compose buildThe container runs with default Docker isolation (no --privileged flag)
Network mode is bridge by default
The container is ephemeral — no persistent volumes
Only use this for authorized security testing, CTF challenges, and educational purposes
MIT
Start the Kali Linux Docker container. Must be called before running any commands.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the action and a usage hint, omitting details on idempotency, error behavior (e.g., if already running), permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using a single sentence to convey the purpose and a key usage instruction with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simplicity (no parameters, no output schema, no annotations), the description covers the purpose and a usage hint. However, it lacks details on expected behavior (e.g., idempotency, error messages) that would make it fully informative for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% vacuously. Per the baseline guideline for 0 parameters, a score of 4 is appropriate as the description adds no parameter information but no additional info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts the Kali Linux Docker container, a specific verb+resource. It also distinguishes the tool from siblings like 'container_status' and 'container_stop' by implying it is a prerequisite for running commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Must be called before running any commands,' providing clear when-to-use context. However, it does not mention when not to use it (e.g., if container already running) or suggest alternatives like checking status first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of the Kali Linux Docker container.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only states 'Check the status' without addressing auth requirements, error handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveys the purpose without unnecessary words. Perfectly concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not explain what the status response contains. The tool is simple but contextually incomplete without return format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description does not add parameter-specific meaning, but baseline is 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Check' and resource 'status of the Kali Linux Docker container'. It clearly distinguishes from sibling tools like container_start and container_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid this tool. It does not mention alternatives or conditions, leaving the agent to infer from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop and remove the Kali Linux Docker container.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses the destructive stop-and-remove action but does not elaborate on idempotency, error behavior (e.g., if container doesn't exist), or safety. With no annotations, more details would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Front-loaded with the key action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool, the description covers the core functionality. However, it could mention the behavior if the container is already stopped or not present, and it lacks any note about graceful shutdown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so schema coverage is 100%. Baseline is 4 for zero parameters; description adds no param info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (stop and remove) and the target (Kali Linux Docker container). It distinguishes itself from sibling tools like container_start and container_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for stopping the container but provides no explicit guidance on when to use this tool versus alternatives, no prerequisites, or side effects. While the purpose is clear, it lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read/download a file from the Kali Linux container. Useful for retrieving scan results and output files.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path of the file inside the container |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'read/download' but fails to disclose output format, error handling for nonexistent paths, or permissions needed. For a tool with no output schema, this is a significant lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no fluff, and front-loaded with the core action. Every word is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description provides basic completeness but misses behavioral details like return format and error scenarios. It is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a description for 'path', so the baseline is 3. The description adds no extra meaning beyond the schema, which is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads/downloads a file from the Kali Linux container and specifies its usefulness for retrieving scan results and output files, differentiating it from siblings like upload_file and list_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving scan results and output files but does not explicitly state when not to use it or compare to alternatives like list_files (to locate files) or upload_file (to send files). The guidance is present but not thorough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a shell command inside the Kali Linux container. Use this to run security tools like nmap, sqlmap, hydra, nikto, gobuster, john, hashcat, dirb, enum4linux, and any other installed tool.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Shell command to execute inside the Kali container | |
| timeout | No | Timeout in seconds (default: 300) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions command execution and gives examples, but omits important details like the default timeout (300s via schema), potential destructive actions, error handling, or that commands run inside a container. This leaves significant gaps for an agent assessing safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long, front-loaded with the main action, and includes concrete examples. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 required parameters, high schema coverage, no output schema) and distinct sibling tools, the description is mostly complete. However, it lacks behavioral notes on container state requirements or error scenarios, which would round it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters. The description adds value by listing example tools and implying use cases, but does not clarify timeout semantics beyond the schema. Baseline 3 is appropriate since the description does not substantially exceed schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: executing a shell command inside a Kali Linux container. It names specific security tools as examples, which distinguishes it from sibling tools that handle container lifecycle and file operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool for security tools like nmap, sqlmap, etc., providing clear context. It does not explicitly state when not to use it or mention alternatives, but the sibling tools are sufficiently different, making the guidance adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files in a directory inside the Kali Linux container.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Directory path inside the container (default: /workspace) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden but only states the basic action. It omits details like recursion, hidden file behavior, output format, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loads the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter and no output schema, the description is minimally adequate. However, it doesn't convey what the output looks like (list of names vs. metadata).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter description in the schema already documents the default path. The tool description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies verb 'list files' and resource 'directory inside the Kali Linux container', effectively distinguishing from sibling tools like download_file or execute_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use list_files versus alternatives. For example, it doesn't advise using it before download_file to inspect available files, nor does it mention limitations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload/write a file to the Kali Linux container. Useful for uploading wordlists, scripts, or configuration files.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path inside the container where the file should be written | |
| content | Yes | File content to write |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention whether existing files are overwritten, what happens on invalid paths, or permission requirements. This leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. Every word adds value, and the most important information (verb+target+examples) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required string params, no output schema), the description covers the core functionality but omits important details like overwrite behavior and error handling. It is partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides good descriptions for both parameters (path and content), achieving 100% schema coverage. The description adds no additional meaning beyond what the schema supplies, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('upload/write a file'), the target ('Kali Linux container'), and provides concrete use cases ('wordlists, scripts, or configuration files'). It effectively distinguishes from sibling tools like download_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of prerequisites (e.g., container must be running) or exclusions (e.g., for large files use a different method).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0container_startcontainer_statuscontainer_stopdownload_fileexecute_commandlist_filesupload_fileScored across 7 tools
Each tool has a clearly distinct purpose with no overlap: container management (start/status/stop), file operations (download/list/upload), and command execution. The descriptions explicitly differentiate their functions, making misselection unlikely.
All tools follow a consistent verb_noun pattern with snake_case naming (e.g., container_start, execute_command, list_files). The naming convention is uniform across all seven tools, making them predictable and easy to understand.
Seven tools is well-scoped for managing a Kali Linux Docker container, covering essential operations like container lifecycle, file management, and command execution. Each tool earns its place without redundancy or bloat.
The toolset provides complete coverage for the domain: container lifecycle (start/status/stop), file operations (upload/download/list), and command execution. There are no obvious gaps, enabling agents to perform all necessary tasks for security testing workflows.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Paid remote MCP for LLM security scans, jailbreak checks, analytics, checkout, and readiness.
Persistent file storage for AI agents via MCP and curl. Upload, download, and version files.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
