Provides tools to run Kali Linux security testing tools within a Docker container, enabling tasks like network scanning, port scanning, and service discovery via an AI assistant.
Click on "Install 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 scan open ports on 192.168.1.1"
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.
kali-mcp lets an AI assistant work with a Kali Linux Docker setup for security testing. It gives the assistant a safe, isolated place to run common Kali tools. That makes it easier to test systems, check for weak spots, and work through security tasks from one place.
This project is made for local use on Windows. You run it on your own computer, and it uses Docker to start the Kali Linux environment.
Related MCP server: Kali MCP Server
Before you start, make sure you have:
A Windows PC
Admin access on your computer
Internet access
Docker Desktop for Windows
An AI assistant that supports MCP
At least 8 GB of RAM
Around 10 GB of free disk space
If your system is older, the app may still run, but Docker can use a lot of memory. More RAM gives a smoother result.
Go to the download page here:
Use that page to get the files you need, then follow the setup steps below.
Follow these steps in order.
If Docker Desktop is not on your PC, install it first.
Open the Docker Desktop website
Download the Windows version
Run the installer
Restart your PC if asked
Open Docker Desktop and wait until it says it is running
Docker is what starts the Kali Linux environment on your computer.
Open the repository link
Download the project files to your PC
Save them in a folder you can find again, such as Downloads or Documents
If the files come as a ZIP, right-click the ZIP file and choose Extract All
After this, you should have a folder named kali-mcp.
Open File Explorer
Go to the folder where you saved the project
Open the kali-mcp folder
You should see files for the project inside that folder.
The project uses Docker to start a Kali Linux container.
Open Docker Desktop and make sure it is running
Open a command window in the kali-mcp folder
Run the startup command that comes with the project files
Wait while Docker downloads the Kali image
Let the setup finish
The first start can take a few minutes. Later starts are faster.
Once the Docker setup is ready, connect your MCP-compatible AI assistant.
Open your AI assistant app
Go to its MCP or server settings
Add the kali-mcp server
Use the local path or command from the project files
Save the settings
Restart the assistant if needed
After that, the assistant can use the Kali environment for supported security tasks.
When the server is running, you can ask the assistant to help with things like:
Basic network checks
Port scans with tools like nmap
Service checks
Simple security testing
Reviewing system details in the Kali container
Keep your use within systems you own or have permission to test.
Here are a few simple ways people use kali-mcp:
Check which ports are open on a test machine
Look for common service banners
Run basic network discovery
Test a local lab setup
Use Kali tools without installing a full Kali system
Because the tools run in Docker, your main Windows system stays separate from the testing environment.
kali-mcp acts as a bridge between your AI assistant and a Kali Linux Docker container.
The AI assistant sends a request
The MCP server passes the task to the Kali container
The container runs the tool
The result goes back to the assistant
This setup keeps the workflow simple. You do not need to open Kali by hand each time.
Use this tool only on systems you own or have clear permission to test. Security tools can scan networks, check services, and gather data. That can affect systems if used the wrong way.
A safe setup is:
Your own PC
A home lab
A test VM
A training environment
A system where you have written permission
Learning how security tools work
Testing a home lab
Checking a small server before launch
Exploring how an AI assistant can run CLI tools
Doing repeatable checks in a Docker sandbox
Check that Docker Desktop is installed
Restart your PC
Open Docker Desktop as admin
Make sure virtualization is on in BIOS or UEFI
Close other heavy apps
Give Docker more memory in settings
Make sure you have free disk space
Check the MCP config path
Make sure the server is running
Restart the AI assistant
Confirm the project folder has not moved
Wait a few minutes on the first run
Check your internet connection
Look at Docker Desktop to see if it is pulling images
Try again after restarting Docker
The project files usually include:
Server files for MCP
Docker setup files
Start scripts
Config files
Documentation
Keep all files in the same folder so the setup stays simple.
Use a folder with a short path, such as C:\kali-mcp
Keep Docker Desktop open while you use the server
Do not move the folder after setup unless you update the path
If Windows asks for permission, allow it for Docker and the project files
This project helps you use Kali Linux tools without setting up a full virtual machine. It also lets an AI assistant help with tasks that need command-line tools. That can save time when you do repeatable security checks in a lab or test setup
Name: kali-mcp
Type: MCP server
Platform: Windows with Docker
Purpose: Security testing with Kali Linux tools
Topics: AI tools, Claude, cybersecurity, Docker, ethical hacking, Kali Linux, MCP, nmap, pentesting, security
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. Dates show when Glama detected each change.
v1.0.0container_startcontainer_statuscontainer_stopdownload_fileexecute_commandlist_filesupload_fileEach tool has a unique purpose: container lifecycle management, file transfer, command execution, and file listing. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to understand.
With 7 tools, the set is well-scoped for managing a Kali container and running tools. Slightly compact but sufficient for core workflows.
Covers container lifecycle, file transfer, file listing, and command execution. Minor gap: no tool for container logs or interactive session, but typical use cases are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
Exposes FEDLIN's public security scanners as agent-callable tools over Streamable HTTP.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Unaacceptable297/kali-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
