Windows 下部署 Kali-Security-MCP 记录

这篇记录的目标很简单：以后换新电脑时，可以按本文把环境重新拉起来，少走弯路。

最终跑通的链路如下：

Windows 安装 Claude Code
WSL 中部署 Kali-Security-MCP
Claude Code 不走网络连接
Claude Code 通过 stdio 方式调用 wsl.exe
wsl.exe 进入 WSL 后，在项目目录中启动 mcp_server.py

这个方案已经能跑通。后面又遇到了上下文长度问题，但部署链路本身已经打通。

一、最终可用方案

最终我放弃了“Windows 通过网络地址连接 WSL 中的 MCP Server”的方式，改用 stdio 方式。

原因很实际：

这个项目在 WSL 里直接起网络型 MCP 服务时，先遇到了 Python 依赖版本不兼容，代码要改
改完以后服务能起，但 Claude Code 通过网络方式接入时，会做额外校验，这个 MCP Server 当前实现没有通过
改成 stdio 后，Claude Code 直接拉起 wsl.exe，再由 WSL 里的 Python 启动 mcp_server.py，链路最稳定

结论先写在前面：

在 Windows 下接 Kali-Security-MCP，当前更稳的做法是 stdio，不要优先折腾网络接入。

二、部署步骤

1. Windows 安装 WSL

先装好 WSL，并准备一个 Linux 发行版。本文实际使用的是 WSL 里的 Linux 环境来部署 Kali-Security-MCP。

常用命令：

wsl --install
wsl -l -v

如果已经装好了，可以直接进入 WSL。

2. 在 WSL 中拉取项目

进入 WSL 后，先准备基础环境。

sudo apt update
sudo apt install -y git python3 python3-venv python3-pip

拉取项目：

cd ~
git clone https://github.com/SeaC-25/Kali-Security-MCP.git
cd Kali-Security-MCP

创建虚拟环境：

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip

安装依赖。这个仓库里实际依赖我当时至少装了这些：

pip install mcp pydantic aiohttp aiofiles

如果后续项目补了 requirements.txt，也可以直接：

pip install -r requirements.txt

3. 修复 `mcp` 包版本导致的启动问题

我当时在 WSL 里直接启动服务，报错如下：

FastMCP.run() got an unexpected keyword argument 'host'

说明项目代码和当前安装的 mcp 包接口对不上。

出问题的位置在 mcp_server.py 的 main() 里，原来是这样：

mcp.run(transport="sse", host=args.host, port=args.port)

需要改成下面这样：

mcp.settings.host = args.host
mcp.settings.port = args.port
mcp.run(transport="sse")

也就是把 host 和 port 先写到 mcp.settings，再调用 run()。

我当时直接把对应逻辑改成下面这样：

if args.transport == "sse":
    logger.info(f"🌐 SSE服务器启动于 http://{args.host}:{args.port}")
    logger.info(f"📌 外部AI连接地址: http://<your-ip>:{args.port}/sse")

    mcp.settings.host = args.host
    mcp.settings.port = args.port
    mcp.run(transport="sse")
else:
    logger.info("📌 stdio模式: 等待Claude Desktop/Code连接...")
    mcp.run()

这个修改的本质，是兼容当前安装到虚拟环境里的 mcp Python 包。

4. 验证 WSL 内服务是否能正常启动

修完代码后，先在 WSL 里测试。

测试 SSE 方式启动

source .venv/bin/activate
python mcp_server.py --transport=sse --host=0.0.0.0 --port=8765

如果能正常启动，说明代码兼容问题已经解决。

测试 stdio 方式启动

source .venv/bin/activate
python mcp_server.py

stdio 模式下不会像普通 Web 服务那样监听一个端口，它会等待上游进程通过标准输入输出和它通信。

最终我实际使用的就是这个模式。

5. 在 Windows 下配置 Claude Code 通过 stdio 调用 WSL

这里有个容易记错的点：

Claude Code 的用户级配置文件是用户目录下的 .claude.json，不在 .claude 文件夹里。

也就是类似下面这个位置：

C:\Users\你的用户名\.claude.json

我最后写入的配置如下：

{
  "mcpServers": {
    "kali-wsl": {
      "type": "stdio",
      "command": "wsl.exe",
      "args": [
        "bash",
        "-lc",
        "cd /home/user/Kali-Security-MCP && /home/user/Kali-Security-MCP/.venv/bin/python mcp_server.py"
      ]
    }
  }
}

这里有几个关键点：

command 用的是 wsl.exe
args 里通过 bash -lc 进入 WSL shell
先 cd 到项目目录
明确使用虚拟环境里的 Python
启动 mcp_server.py 时不加 --transport=sse，默认走 stdio

部署到新电脑时，至少要把下面两处改成你自己的实际路径：

/home/user/Kali-Security-MCP
/home/user/Kali-Security-MCP/.venv/bin/python

更稳一点的写法，可以把 user 改成你自己的 WSL 用户名，例如：

{
  "mcpServers": {
    "kali-wsl": {
      "type": "stdio",
      "command": "wsl.exe",
      "args": [
        "bash",
        "-lc",
        "cd /home/whwq2012/Kali-Security-MCP && /home/whwq2012/Kali-Security-MCP/.venv/bin/python mcp_server.py"
      ]
    }
  }
}

配置完后，重启 Claude Code，再查看 MCP 是否已经被识别。

三、我在这个过程中踩到的坑

1. WSL 里 Python 服务跑不起来

现象

mcp_server.py 一启动就报错：

FastMCP.run() got an unexpected keyword argument 'host'

原因

项目代码写法和当前安装的 mcp 包版本接口不一致。

解决

把：

mcp.run(transport="sse", host=args.host, port=args.port)

改成：

mcp.settings.host = args.host
mcp.settings.port = args.port
mcp.run(transport="sse")

本质

代码依赖的 SDK 接口版本变了。项目代码还按旧写法在调用，所以直接起不来。

2. 服务能跑起来，但 Claude Code 网络连接失败

现象

SSE 服务起起来了，但 Claude Code 通过网络方式连接时，会做一些额外校验，当前这个 MCP Server 没能通过，最后没有接通。

我最后的处理

直接放弃网络方式，改用 stdio。

为什么这样更稳

stdio 模式下，Claude Code 本地直接拉起进程，然后通过标准输入输出和 MCP 通信。路径更短，兼容问题更少，也不依赖远程传输能力是否完整。

我的结论

这个项目当前在 Windows + WSL 的组合里，用 stdio 更合适。

3. Claude Code 配置文件位置容易记错

我一开始会下意识往 .claude 文件夹里找。

实际要改的是：

C:\Users\你的用户名\.claude.json

这一点很关键，记错位置就会导致改了半天没效果。

4. 链路打通后，又遇到上下文长度不够

现象

MCP 接通了，但使用本地模型时又报上下文超限。

当时的实际情况

我当时接的是 Qwen3.5 14B 量化模型，实测只有 40960 左右上下文。而 Claude Code 在挂上 MCP 后，一次请求上下文能到 50000+，所以虽然链路是通的，实际对话还是会因为上下文长度不够而失败。

结论

这个问题和 Kali-Security-MCP 能不能连上已经是两件事了。

链路层面已经通了
真正使用时，又受模型上下文上限约束

后续方向

后面想长期用，有几条路：

换更大上下文的模型
减少一次会话里带入的上下文
精简工具数量或提示词长度
减少 Claude Code 自动注入的历史内容

四、相关原理记录

1. 为什么 `stdio` 能通

stdio 模式下，Claude Code 不需要访问一个远程 HTTP/SSE 地址，它只需要：

启动一个本地进程
通过标准输入给它发请求
通过标准输出接收响应

在当前这个场景里，本地进程其实就是：

wsl.exe -> bash -lc -> python mcp_server.py

所以 Claude Code 看到的是一个本地可执行的 MCP 进程，WSL 只是这个进程运行的容器。

2. 为什么网络方式更容易出问题

网络方式会多出几层东西：

MCP Server 本身的远程传输实现
Claude Code 对远程 MCP 服务的连接和校验逻辑
WSL 网络映射
端口监听和地址绑定

只要其中有一层对不上，就会连不上。

这个项目当前的 SSE 实现虽然能起服务，但和 Claude Code 通过网络接入时的实际要求没有完全对上，结果就是服务在，客户端连不上。

3. WSL 和主机之间的网络互通

虽然我最终没用网络方式接 MCP，但过程中顺手验证了 WSL 的网络互通特性，这个结论以后仍然有用。

我确认过的现象

WSL 里的服务，可以通过 eth0 的 IP 被 Windows 主机访问
Windows 主机的局域网 IP，也可以在 WSL 里访问

这意味着什么

WSL 并不是一个完全隔离的小黑盒，它和 Windows 主机之间本身就有一层可通信的虚拟网络。

以后如果需要在 WSL 里开普通 Web 服务、API 服务、调试端口，这个结论很有用。

常用排查命令

在 WSL 中查看 IP：

ip addr show eth0
ip route
hostname -I

在 Windows 中测试：

curl http://<wsl-ip>:8765

在 WSL 中访问主机局域网 IP：

curl http://<windows-lan-ip>:端口

五、以后换电脑时的最小复现步骤

直接按这个顺序做即可：

1. Windows 准备 WSL

wsl --install

2. WSL 安装基础环境

sudo apt update
sudo apt install -y git python3 python3-venv python3-pip

3. 拉项目并建虚拟环境

cd ~
git clone https://github.com/SeaC-25/Kali-Security-MCP.git
cd Kali-Security-MCP
python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install mcp pydantic aiohttp aiofiles

4. 修补 `mcp_server.py`

把：

mcp.run(transport="sse", host=args.host, port=args.port)

改成：

mcp.settings.host = args.host
mcp.settings.port = args.port
mcp.run(transport="sse")

5. 配置 `C:\Users\你的用户名\.claude.json`

{
  "mcpServers": {
    "kali-wsl": {
      "type": "stdio",
      "command": "wsl.exe",
      "args": [
        "bash",
        "-lc",
        "cd /home/你的WSL用户名/Kali-Security-MCP && /home/你的WSL用户名/Kali-Security-MCP/.venv/bin/python mcp_server.py"
      ]
    }
  }
}

6. 重启 Claude Code 验证

看到 kali-wsl 被识别，基本就说明链路通了。

六、最后的结论

这次折腾下来，最重要的结论有四个：

Kali-Security-MCP 在 WSL 里能跑，但当前代码和 mcp 包版本可能对不上，需要手改
网络方式理论上可尝试，实际接 Claude Code 时容易卡在远程传输兼容问题
stdio + wsl.exe + 虚拟环境 Python 是当前最稳的方案
链路打通后，真正的瓶颈又变成了模型上下文长度

所以这套方案的定位很清楚：

先把工具链打通，再去处理模型上下文和实际可用性问题。

对部署来说，stdio 这条路已经足够实用。

Windows 下部署 Kali-Security-MCP 记录#

一、最终可用方案#

二、部署步骤#

1. Windows 安装 WSL#

2. 在 WSL 中拉取项目#

3. 修复 mcp 包版本导致的启动问题#

4. 验证 WSL 内服务是否能正常启动#

测试 SSE 方式启动#

测试 stdio 方式启动#

5. 在 Windows 下配置 Claude Code 通过 stdio 调用 WSL#

三、我在这个过程中踩到的坑#

1. WSL 里 Python 服务跑不起来#

现象#

原因#

解决#

本质#

2. 服务能跑起来，但 Claude Code 网络连接失败#

现象#

我最后的处理#

为什么这样更稳#

我的结论#

3. Claude Code 配置文件位置容易记错#

4. 链路打通后，又遇到上下文长度不够#

现象#

当时的实际情况#

结论#

后续方向#

四、相关原理记录#

1. 为什么 stdio 能通#

2. 为什么网络方式更容易出问题#

3. WSL 和主机之间的网络互通#

我确认过的现象#

这意味着什么#

常用排查命令#

五、以后换电脑时的最小复现步骤#

1. Windows 准备 WSL#

2. WSL 安装基础环境#

3. 拉项目并建虚拟环境#

4. 修补 mcp_server.py#

5. 配置 C:\Users\你的用户名\.claude.json#

6. 重启 Claude Code 验证#

六、最后的结论#