# MCP Kali Server: an API bridge from MCP clients to a Kali terminal

> MCP Kali Server (MKS) exposes a Flask API that runs terminal commands and a fixed set of pentest tools on Kali, so an MCP client such as Claude Desktop can drive them. It is a thin bridge, and the security of the whole setup rests on how you bind and reach that API.

**Wh0am123/MCP-Kali-Server** — MCP configuration to connect AI agent to a Linux machine.

- Repository: https://github.com/Wh0am123/MCP-Kali-Server
- Stars: 829 · Forks: 169
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/wh0am123-mcp-kali-server

## What MCP Kali Server actually connects

MCP Kali Server (MKS) is a bridge, not a scanner. The README describes it as "a lightweight API bridge that connects MCP clients (e.g: Claude Desktop or 5ire) to the API server which allows executing commands on a Linux terminal." The MCP client is the AI side. The Kali machine is the execution side. MKS is the piece in between that turns a tool call from the model into a command on that machine and returns the output.

The audience is narrow and the README names it: red teamers, bug bounty hunters and CTF players who want an AI model to suggest and run commands instead of typing them by hand. The use case section lists the intended flow as letting the MCP interact with AI endpoints (OpenAI, Claude, DeepSeek, Ollama or any other model), exposing an API to execute commands on Kali, and using the AI to suggest and run commands to solve CTF challenges or automate recon and exploitation.

The tool list is fixed rather than open-ended: Dirb, enum4linux, gobuster, Hydra, John the Ripper, Metasploit-Framework, Nikto, Nmap, sqlmap and WPScan, plus raw command execution. That list matters because it tells you what the project has been shaped around. A tool that is not on it still has a path through raw commands, but it does not get a dedicated entry point.

## Two processes, one HTTP hop, and the SSH tunnel that stands in for auth

The architecture is visible in the repository layout: server.py, client.py, mcp-kali-server.json and requirements.txt at the top level. The server is a Flask application (Flask>=3.0.0 in requirements.txt) that listens on port 5000 by default and binds to 127.0.0.1 by default. The client is a separate process (client.py) that speaks to that server over HTTP and presents itself to the MCP client as the MCP server.

So the data flow is: MCP client calls the client process, the client process makes an HTTP request to the Flask server on the Kali machine, the server runs the command or tool, and the output travels back the same way. The MCP client never talks to Kali directly. That extra hop is what makes remote use possible, and it is also the part you have to secure yourself.

The README is explicit that when the client and server are on different machines, you are expected to create an SSH tunnel and then point the client at the local end of it: `ssh -L 5000:localhost:5000 user@LINUX_IP`, followed by `./client.py --server http://127.0.0.1:5000`. If you instead host the server openly on the network with `server.py --IP...`, the README says you do not need the tunnel, then adds "THIS IS STRONGLY DISCOURAGED. WE RECOMMEND SSH". Read that as the project's own position on its authentication story: the transport is plain HTTP, and the tunnel is the access control.

## Installing MCP Kali Server and running a first command

There are two install paths in the README, and the first one is a Kali package. On the Kali machine, the README gives:

```bash
sudo apt install mcp-kali-server
kali-server-mcp
```

If that package is not available in your release, the README's bleeding-edge path builds from source in a virtual environment:

```bash
git clone https://github.com/Wh0am123/MCP-Kali-Server.git
cd MCP-Kali-Server
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
./server.py
```

The three dependencies in requirements.txt are Flask, requests and mcp, all with minimum versions rather than pins, so a fresh install resolves to whatever is current at the time. The server defaults to 127.0.0.1 and port 5000. The README lists three command line options: `--ip` to choose the bind address, `--port` for the port, and `--debug` for verbose logging, with examples such as `./server.py --ip 192.168.1.100 --port 8080`.

On the client machine, the same-machine case is one command:

```bash
kali-server-mcp --server http://127.0.0.1:5000
```

or `./client.py --server http://127.0.0.1:5000` from a source checkout. For separate machines, the README's sequence is the SSH tunnel first, then the client against `http://127.0.0.1:5000` on the client side. To wire it into Claude Desktop, the README points at `claude_desktop_config.json` (under `~/Library/Application Support/Claude/` on macOS and `%APPDATA%\Claude\` on Windows) and references the repository's mcp-kali-server.json as the example. For 5ire, the README says to add an MCP with the command `python3 /absolute/path/to/client.py --server http://LINUX_IP:5000` and the application generates the configuration files itself. A first real use is then a prompt to the model that asks it to run nmap against a host you control, and watching the command output come back through the client.

## The bind address is the whole security model

The README's own descriptions of `--ip` are the clearest statement of risk in the project. `127.0.0.1` is called "secure, recommended". `0.0.0.0` is called "very dangerous; use with caution". Those are the project author's words, and they are accurate: the server executes terminal commands, so anything that can reach the port can ask it to execute terminal commands.

What the README does not describe is any authentication layer, any allowlist of commands, or any per-command confirmation step. The features section calls it a "controlled API", but the control described is the bind address and the tunnel, not a policy engine. If you expose the server on a network interface, you are relying on the network being trustworthy. That is a real limitation, not a documentation gap you can work around with a config key.

The second limitation is the trust direction. The AI model chooses the commands. The README frames the project as educational and ethical testing only, and states that unauthorized access, exploitation or malicious activity is strictly prohibited and that the author assumes no responsibility for misuse. Whatever guardrails exist are in your MCP client and in your own supervision, not in MKS. If you would not hand a shell on that machine to the model's operator, do not hand it to MKS either.

## Where MCP Kali Server is the wrong tool

This is the wrong tool for anything that needs an audit trail or least privilege. There is no user model, no per-tool permission, and no record of which command came from which session described in the README. If your environment requires proof of who ran what, MKS cannot give it to you.

It is also the wrong tool if your goal is a stable, versioned interface. The only release listed is tagged security and dated 2025-04-08; the last push to the repository was on 2026-03-17. The requirements are minimum-version, not pinned, so the dependency set can shift under you between installs. For a lab machine you rebuild often, that is tolerable. For a long-lived environment, it is a reason to pin your own lockfile.

And it is the wrong tool if you want the AI to reason about findings without executing anything. MKS exists to execute. A workflow that only needs a model to read scan output can use a plain file or a database, with no command execution surface at all.

## How MCP Kali Server differs from a general MCP shell server

The obvious alternative is a generic MCP server that exposes shell execution, of which several exist in the MCP ecosystem. The difference in approach is the tool surface. A generic shell server gives the model one capability: run a command. MKS gives it that plus named entry points for Dirb, enum4linux, gobuster, Hydra, John the Ripper, Metasploit-Framework, Nikto, Nmap, sqlmap and WPScan.

That matters for how the model behaves. Named tools carry their own parameter descriptions, so the model can call nmap with structured arguments rather than composing a shell string and hoping the flags are right. The cost is that MKS is tied to that list. If your work centers on a tool outside it, you are back to raw commands and the named-tool advantage disappears.

The other difference is deployment shape. MKS splits into a server on Kali and a client wherever the MCP client runs, with an SSH tunnel as the recommended link between them. A single-process shell server that runs on the same host as the MCP client has a smaller footprint but cannot drive a separate Kali box. The split is the reason MKS can serve a Windows or macOS client against a remote Kali machine at all, and it is the reason you have a port to defend.

## Maintenance, licensing and what the project does not document

The repository is not archived, and the last push was on 2026-03-17. The single listed release is tagged security and dated 2025-04-08, so the release cadence visible in the repository is sparse. Practically, that means upgrade cost is low in one sense (there is little to keep up with) and uncertain in another: with three minimum-version dependencies and no pins, `pip install -r requirements.txt` is the upgrade mechanism, and it will pull newer Flask, requests and mcp packages whenever you run it. If you need reproducibility, freeze the resolved set yourself.

The licence is MIT. That is permissive: it allows use, modification and redistribution with the licence and copyright notice retained. It does not carry a patent grant and it comes with no warranty, which is standard for MIT. None of that changes the operational risk, because the licence governs the code, not what you point the tool at. The README's disclaimer separates educational and ethical testing from misuse and places responsibility on the user.

Several things are simply not documented. The README does not describe rollback, does not describe logging or audit output, and does not describe how the server validates or sanitizes the commands it receives. The mcp-kali-server.json file is referenced as an example for Claude Desktop but its contents are not reproduced in the README. Treat those as open questions to answer from the source before you rely on the tool.

## Conclusion

MCP Kali Server suits people who already run Kali in a lab or CTF environment and want an MCP client to drive nmap, sqlmap or raw commands without building their own bridge. It is not for production hosts or anyone who needs per-command authorization, because the README does not document one. Before adopting it, verify the install path that applies to you: the README's first option is `sudo apt install mcp-kali-server`, and the RELATED SEARCHES include people hitting 'Unable to locate package mcp kali server', so check whether that package exists in your Kali release and fall back to the git clone path if it does not.

## FAQ

### how to use mcp kali server

The README's flow is to run the server on the Kali machine and the client on the MCP client machine, then let the model call tools. On the same machine that is `./server.py` in one terminal and `./client.py --server http://127.0.0.1:5000` in another, after which the model can run commands and tools such as Nmap or sqlmap.

### what is mcp kali server

It is a lightweight API bridge that connects MCP clients such as Claude Desktop or 5ire to an API server that executes commands on a Linux terminal. It can run raw commands and interact with tools including Nmap, sqlmap, Nikto, gobuster and Metasploit-Framework.

### How do I run an MCP server?

For MKS, start `./server.py` on the Kali machine (it binds to 127.0.0.1 on port 5000 by default) and then start the client with `./client.py --server http://127.0.0.1:5000` or `kali-server-mcp --server http://127.0.0.1:5000`. For separate machines the README has you open an SSH tunnel first.

## Sources

- [Issues](https://github.com/Wh0am123/MCP-Kali-Server/issues)
- [License: MIT](https://github.com/Wh0am123/MCP-Kali-Server/blob/main/LICENSE)
- [README](https://github.com/Wh0am123/MCP-Kali-Server/blob/main/README.md)
- [Releases](https://github.com/Wh0am123/MCP-Kali-Server/releases)
- [Wh0am123/MCP-Kali-Server on GitHub](https://github.com/Wh0am123/MCP-Kali-Server)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wh0am123-mcp-kali-server