VulnClaw MCP Router 路由设计指南:跨服务工具调用的统一入口如何实现
【免费下载链接】VulnClaw基于 AI Agent + MCP 工具链 + 渗透 Skill 编排, 配合大语言模型, 自然语言输入 → 自动完成「信息收集 → 漏洞发现 → 漏洞利用 → 报告生成」全流程。项目地址: https://gitcode.com/GitHub_Trending/vu/VulnClaw
VulnClaw 是一款基于AI Agent + MCP 工具链 + 渗透 Skill 编排的开源安全工具,用自然语言输入即可自动完成「信息收集 → 漏洞发现 → 漏洞利用 → 报告生成」全流程。这篇指南带你读懂它的核心部件MCP Router 路由设计:一个统一入口如何把大语言模型与 fetch、burp、chrome-devtools 等多个 MCP 服务连接起来,让"说一句人话"就能跨服务调用工具,而无需你了解任何底层协议。
1️⃣ 先搞清楚问题:为什么工具调用需要"统一入口"
VulnClaw 内置了 4 个 MCP 服务,它们各管一摊,但通信方式完全不同:
| MCP 服务 | 接入方式 | 职责 |
|---|---|---|
fetch | 本地进程内 | 发送 HTTP 请求,返回状态码、响应头与完整响应体 |
memory | 本地进程内 | 保存与回忆任务过程中的关键信息 |
chrome-devtools | stdio 子进程 | 浏览器自动化:打开页面、执行 JS、截图 |
burp | SSE 远程服务 | 抓包、查看请求历史、重放与篡改数据包 |
如果没有统一路由层,大语言模型需要自己记住"每个工具属于哪个服务、走什么协议、参数长什么样"——这既容易出错,也难以维护。
MCP Router 要解决的,就是把这个"接线板"收敛成一个入口:模型只面对一张扁平的工具清单,路由层负责把每一次调用准确送达对应的服务,并在服务不可用时优雅降级。
2️⃣ 模块全景:6 个文件构成 MCP"控制塔"
MCP 能力集中在 vulnclaw/mcp/ 目录,作为基础设施层同时服务 CLI 和 Web 两种入口:
| 文件 | 角色 |
|---|---|
| router.py | ⭐ 意图识别与工具路由(本文主角) |
| registry.py | 服务与工具的中央注册表,记录运行状态与健康度 |
| lifecycle.py | 服务启停、传输层探测、故障自动恢复 |
| diagnostics.py | 生成 MCP 服务诊断快照 |
| schemas.py | 诊断数据的视图模型定义 |
| _probe_mixin.py | 传输通道(stdio / SSE / HTTP)探测混入 |
一个关键设计在 registry.py:注册表会把所有服务的全部工具合并成一份 OpenAI function-calling 格式的工具清单交给大模型。对模型而言,跨服务调用和调用本地工具看起来完全一样——这就是"统一入口"的第一层含义。
3️⃣ 核心机制:MCP Router 的三种路由能力
路由逻辑定义在 vulnclaw/mcp/router.py 的MCPRouter类中,它提供三种互补的能力。
3.1 意图关键词 → 工具映射:听懂"人话"
router.py 中的INTENT_TOOL_MAP维护了一张"意图表",把中英文关键词组映射到具体的(工具, 服务)组合。举几个例子:
- 你说"抓包/查看请求/重放" → 路由到
burp服务的get_proxy_http_history或send_http1_request - 你说"截图/截屏" → 路由到
chrome-devtools的screenshot - 你说"发请求/调用 API" → 路由到本地
fetch,备选burp的重放工具
route()方法会扫描输入中的关键词命中情况,返回候选工具列表,每条结果附带置信度(confidence),供模型决策参考。这意味着模型不需要背工具名——它只需要理解语义,剩下的交给映射表。
3.2 按渗透阶段推荐工具:路由的"兜底清单"
当模型拿不准时,suggest_tools_for_phase() 会根据当前所处的渗透阶段直接给出推荐组合:
| 渗透阶段 | 推荐工具组合 |
|---|---|
| 信息收集 | fetch探测目标 +chrome-devtools访问页面 + 截图 |
| 漏洞发现 | fetch发送探测请求 +burp代理检测请求 |
| 漏洞利用 | burp构造利用请求 +fetch发送载荷 + 浏览器 JS 执行 |
每个推荐都附带本地化说明(中英文国际化),让路由结果不仅"可用",还"可解释"。
3.3 从自然语言里直接提取参数
extract_url() 与 extract_ip() 用正则从一句话中直接抽取 URL 和 IP 地址。比如输入"打开 https://target.local 并截图",路由层一步产出:new_page(chrome-devtools)、navigate(chrome-devtools)、screenshot(chrome-devtools),目标地址已自动填好——省去了模型反复整理参数参数的回合。
4️⃣ 路由凭什么可靠:注册、健康度与故障自愈
路由表只是"图纸",真正让统一入口稳如磐石的,是下面这套支撑机制。
📇 中央注册表:工具归属一查即知
MCPRegistry 维护三张索引:服务→运行状态、工具→Schema、服务→工具列表。任何一次工具调用都会记录成功/失败与耗时(record_tool_call),路由层随时可反查"这个工具属于哪个服务"。
🔌 三种传输通道 + 自动降级
lifecycle.py 支持stdio、SSE、Streamable HTTP三种 MCP 传输类型:
fetch/memory直接以 local 模式在进程内运行,零部署chrome-devtools(stdio)与burp(SSE)会尝试自动连接(attach)- 连接失败时降级为 placeholder并注册内置的静态工具清单,主流程不中断——服务装上了就自动升级,没装上也不报错
🩺 健康评分与自动重启
- 自动重启:服务崩溃后最多重试 3 次,按指数退避(1s、2s、4s)
- 健康评分:滚动统计最近 20 次调用,成功率 >90% 为 healthy,50%~90% 为 degraded,<50% 判定 unavailable(health_check)
🛡️ 安全约束内置于入口
路由层还承担了"守门员"角色:调用fetch前会先按任务约束检查目标主机、路径、端口是否在允许/阻断名单内(lifecycle.py),越界请求直接返回constraint_violation而不发出——安全边界被写进了统一入口本身,而不是散落在各处。
5️⃣ 实践指南:验证、配置与扩展
查看路由状态:诊断服务(diagnostics.py)会输出每个 MCP 服务的运行模式、健康状态、工具数与调用统计,CLI 与 Web 端(mcp_service.py)共用同一数据源。
配置服务:所有 MCP 服务在config.yaml的mcp.servers下声明,结构定义见 MCPServerConfig / MCPTransportConfig——包括启用开关、优先级(0=关键 / 1=普通 / 2=可选)、传输方式(stdio 用command,sse/http 用url)与超时参数:
mcp: servers: chrome-devtools: enabled: true priority: 1 transport: type: stdio部署外部服务:chrome-devtools 与 burp 的安装步骤详见官方文档 docs/mcp-deployment.md;路由层的单元与集成测试可参考 tests/mcp/test_mcp.py。
✅ 小结
VulnClaw 的 MCP Router 用四个设计实现了跨服务工具调用的统一入口:意图映射让模型"说人话"即可选对工具,阶段推荐提供兜底清单,注册表 + 健康度 + 自动降级保证服务状态透明可控,约束检查把安全边界内置进入口。对新手而言,你只需启用所需 MCP 服务,路由层会默默处理剩下的所有接线工作——这正是"统一入口"架构的价值所在。
【免费下载链接】VulnClaw基于 AI Agent + MCP 工具链 + 渗透 Skill 编排, 配合大语言模型, 自然语言输入 → 自动完成「信息收集 → 漏洞发现 → 漏洞利用 → 报告生成」全流程。项目地址: https://gitcode.com/GitHub_Trending/vu/VulnClaw
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考