MCP Kali Server: an HTTP bridge between an MCP client and a Kali shell

The gap MCP Kali Server fills: a shell an MCP client can call

An MCP client such as Claude Desktop or 5ire speaks the Model Context Protocol to its configured servers. A Kali box speaks SSH or a local terminal. Nothing in either protocol connects the two, so a model asked to enumerate a host cannot run Nmap on your behalf unless something translates tool calls into process execution. MCP Kali Server is that translation layer. The README describes it as a lightweight API bridge that connects MCP clients to an API server which allows executing commands on a Linux terminal. The audience named in the README is red teamers, bug bounty hunters and CTF players, plus anyone automating recon or exploitation steps. The listed tool surface is broad but fixed: Dirb, enum4linux, gobuster, Hydra, John the Ripper, Metasploit Framework, Nikto, Nmap, sqlmap and WPScan, alongside a raw command path. That last item is what makes the bridge useful for tools the author did not wrap, and it is also where the security argument lives.

Architecture: two Python processes and one HTTP hop

The repository splits into server.py, which runs on the Kali machine and binds an HTTP listener, and client.py, which runs wherever your MCP client lives and speaks MCP outward while calling the server inward. The default bind is 127.0.0.1 on port 5000, which means the server is reachable only from the Kali host itself until you change it. For a remote setup the README does not ask you to expose the port. It asks you to forward it: run ssh -L 5000:localhost:5000 user@LINUX_IP in one terminal, then start client.py --server http://127.0.0.1:5000 in another. The tunnel terminates on the Kali side, so the HTTP listener never leaves loopback. The README does document the alternative, server.py --ip 0.0.0.0, and labels it very dangerous in the flag description and strongly discouraged in the remote section. That is an unusually blunt warning for a project README, and it is accurate: an HTTP endpoint that runs terminal commands has no meaningful authentication story in what the README describes. Treat the SSH tunnel as part of the architecture, not as an optional hardening step.

Install paths: apt package versus git checkout

The README gives two install routes and they are not equivalent. The packaged route is sudo apt install mcp-kali-server followed by kali-server-mcp, which starts the server. The bleeding edge route clones the repository, creates a virtual environment with python3 -m venv .venv, activates it, runs pip install -r requirements.txt and then executes ./server.py. The server accepts --ip, --port and --debug. The client takes a single documented flag, --server, pointing at the base URL. On the same Kali box you can run either kali-server-mcp --server http://127.0.0.1:5000 or the checkout's ./client.py --server http://127.0.0.1:5000. For Claude Desktop the README points at claude_desktop_config.json under ~/Library/Application Support/Claude/ on macOS or %APPDATA%\Claude\ on Windows, and the repository ships an example file named mcp-kali-server.json. For 5ire you supply the command python3 /absolute/path/to/client.py --server http://LINUX_IP:5000 and the application writes its own config. Note the mismatch in that last example: the client URL uses the Kali IP directly, which only works if the server was bound beyond loopback. If you followed the tunnel instructions, that URL should be 127.0.0.1.

What the raw command path means for blast radius

The wrapped tools are the advertised feature. The raw command execution is the one that determines what this software can do to you. Once an MCP client can ask the server to run arbitrary terminal commands, the model's output becomes an execution path on a real host. The README acknowledges the direction of that risk in its disclaimer, which restricts the project to educational and ethical testing and states that the author assumes no responsibility for misuse. That is a legal framing, not a technical control. Nothing in the supplied material describes a command allowlist, a confirmation prompt, an audit log or a per-session token. If you want to know whether any of those exist, the source is the only place to look, and the README does not claim they do. The practical consequence is that the security boundary is the host itself. Run MKS inside a VM or container you are willing to rebuild, keep it off any network segment that reaches production, and assume that a prompt-injected page, a malicious CTF target or a hallucinated flag can turn into a shell command.

Where the bridge is the wrong tool

MCP Kali Server is a poor fit when you need reproducibility. A run driven by a model produces a sequence of commands chosen at inference time, and the README's evidence for it working is two screen recordings, one solving a web CTF challenge from RamadanCTF and one attempting the Hack The Box machine code. Recordings show that a session happened; they do not show that the same prompt produces the same commands twice, and the README makes no claim that it does. If you need a pentest that another engineer can re-run and diff, a scripted toolchain or a framework with saved project files will serve you better. It is also the wrong tool for scoped professional engagements where every action must be attributable to a named operator, because the README documents no logging or identity layer. And it is the wrong tool for anyone who wants a managed, supported product: this is a single-maintainer MIT project with no homepage listed, so support means reading the code.

Alternatives and the difference in approach

The clearest contrast is Metasploit Framework, which appears in the README's supported tool list and can also be driven by MKS. Metasploit is a self-contained exploitation framework: modules, payloads, sessions and a database of results live inside one tool, and its console records what ran. MCP Kali Server takes the opposite position. It does not implement any offensive capability. It wraps whatever binaries are already on the Kali host and hands the choice of which to run to a language model. So Metasploit gives you a bounded, auditable toolset with its own state, while MKS gives you an unbounded shell with the model as the operator. A second comparison is the plain SSH session you would otherwise open. SSH gives a human operator a terminal and a shell history; MKS gives a model a terminal and, per the README, no described history. If the value you want is a human at the keyboard with a model suggesting commands, the tunnel plus a normal shell already covers most of it, and you keep the judgement step.

Maintenance, licence and what to check before trusting a checkout

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice travel with the code. That is the standard permissive position and it says nothing about whether running the tool against a system you do not own is lawful; the README's disclaimer puts that responsibility on you. Maintenance signals are thin. The repository is not archived, the default branch is main, and the most recent push recorded is 2026-03-17, with a single release tagged security dated 2025-04-08. A release named security is worth reading before you install, because the README does not summarise what it changed. There is also a packaging question the README leaves open: the apt route and the git route may not track the same commit, so if you install with apt you cannot tell from the README which version you received. Upgrade cost is low in the sense that there is no schema, no database and no migration path to manage. It is higher in the sense that the interface is a live shell, so a behaviour change between versions can change what your model is able to run.

A concrete first run, and the boundary to hold

A defensible first run looks like this. Build a Kali VM with no credentials for anything you care about, install via the apt package, and start the server with no flags so it binds 127.0.0.1:5000. Confirm with a local client invocation, ./client.py --server http://127.0.0.1:5000, that the MCP handshake completes before you touch claude_desktop_config.json or 5ire. Then read server.py and client.py to answer the one question the README does not: whether the raw command path validates anything at all. If it does not, the boundary you are holding is the VM, and the moment you pass --ip 0.0.0.0 or point a client at http://LINUX_IP:5000 without the SSH tunnel, you have published a remote command execution endpoint to your network. The project's own README calls that strongly discouraged. Take it at its word.

Editorial conclusion

Adopt MCP Kali Server if you already run Kali in a disposable VM or container and you want an MCP client to drive Nmap, gobuster, sqlmap, Nikto, Hydra, John, Metasploit, WPScan, enum4linux or Dirb through one HTTP endpoint on loopback. Do not adopt it on a machine holding credentials, customer data or a production network path, and do not bind it to 0.0.0.0 to save yourself an SSH tunnel. Before you rely on it, read server.py and client.py to see whether the raw command path performs any argument validation, confirm the licence file actually shipped with the code you cloned, and check whether the apt package and the git checkout are on the same release.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Wh0am123/MCP-Kali-Server on GitHub