Mcpsnoop 开源：给 MCP 协议做个 Wireshark

Agent 调工具到底调了啥，终于有工具能盯着看了

7 月 3 日晚上，一个叫 kerlenton 的开发者把 Mcpsnoop 挂上了 Hacker News 的 Show HN。项目定位说得很直白：Wireshark for MCP。透明代理夹在 MCP Client 和 Server 之间，把两边来回跑的 JSON-RPC 消息实时打到一个 TUI 界面上，谁调了什么工具、传了什么参数、返回了多长的内容，一览无余。

这个项目出现的时机挺微妙。MCP 协议从 2024 年 11 月 Anthropic 开源到现在快两年了，生态已经从早期几十个官方 Server 长到了一堆第三方 Server 满天飞的状态。Claude Desktop、Cursor、Codex、Cline、Continue 这些客户端都在用，公司内部搭的 Agent 也基本绕不开 MCP。但一个老问题从没被真正解决——当你的 Agent 表现异常，你根本不知道它跟 MCP Server 之间说了什么。

透明代理夹在中间，什么都不改

先说清楚它是怎么工作的。MCP 目前主流的传输方式两种：本地 stdio（进程间管道）和远端 HTTP+SSE（或者新的 Streamable HTTP）。Mcpsnoop 处理这两种情况的思路不太一样，但核心都是**"透明"**——不改协议、不改客户端配置逻辑、不需要 Server 端做任何适配。

对 stdio 场景，Mcpsnoop 自己扮演 Server 进程，被 Client 拉起来。启动后它再去 fork 真正的 Server，把 stdin/stdout 挂在两边中间做转发。所有经过管道的字节都会被复制一份到 TUI 的解析器。这套路子跟 mitmproxy 处理 HTTPS 是同一个套路，只是换了传输层。

对 HTTP 场景，就更简单了，起一个反向代理，Client 把原本指向 Server 的 URL 改成指向 Mcpsnoop 的地址，中间加一层拦截。SSE 长连接也支持流式转发和记录。

配置层面基本零成本。你原本 claude_desktop_config.json 里怎么写的：

{
  \"mcpServers\": {
    \"filesystem\": {
      \"command\": \"npx\",
      \"args\": [\"-y\", \"@modelcontextprotocol/server-filesystem\", \"/tmp\"]
    }
  }
}

套一层 Mcpsnoop 之后：

{
  \"mcpServers\": {
    \"filesystem\": {
      \"command\": \"mcpsnoop\",
      \"args\": [\"--\", \"npx\", \"-y\", \"@modelcontextprotocol/server-filesystem\", \"/tmp\"]
    }
  }
}

就这样。Client 那边完全感知不到中间还夹着东西。

TUI 里能看到什么

界面本身用 Rust 写的（作者应该是 Ratatui 的用户），冷启动几乎没延迟。主视图左边是消息流时间线，每一条 JSON-RPC 请求/响应/通知都是一行，标红标绿区分方向；右边是选中消息的详细面板，JSON 展开可以折叠，长文本按需截断——这个细节挺重要，因为 MCP 传回来的 tools/call 结果动辄几十 KB 的文档内容，全部铺开屏幕直接爆炸。

几个我认为实用的能力：

• 方法过滤：按 initialize、tools/list、tools/call、resources/read 这类 method 过滤，只看你关心的。
• 耗时统计：每一次 tools/call 从请求发出到响应回来的墙上时间，直接标在消息上。看哪个工具慢一目了然。
• 会话导出：可以把整场对话导成 .jsonl，扔给分析脚本或者直接贴到 issue 里。
• 搜索：TUI 里 / 触发全文搜索，跳到匹配的消息。

作者在 README 里写了一句我觉得挺到位的话：MCP 表面上是协议，但对大多数开发者来说，它是个黑盒——因为你的 Agent 框架把它包起来了，Server 端日志又稀碎，出了问题只能猜。Mcpsnoop 干的事就是把这层黑盒撬开。

跟 Wireshark MCP、pcap-mcp 完全不是一回事

看名字容易混淆。最近半年社区里冒出来好几个跟"Wireshark"沾边的 MCP 项目，但方向刚好反过来：

• Wireshark MCP / pcap-mcp：把 tshark 的能力封装成 MCP Server，让 AI Agent 能读 pcap 文件、做网络分析。是让 AI 用 Wireshark。
• Mcpsnoop：抓 MCP 协议本身的包，观察 AI Agent 在干什么。是用 Wireshark 看 AI。

一个是把 Wireshark 变成 AI 的工具，一个是把 AI 变成 Wireshark 的观察对象。中间那个介词换了位置，事情就完全不一样。

为什么这东西早该出现

讲实话，MCP 生态最缺的一直不是 Server，而是可观测性工具。过去这一年，社区里各种"awesome-mcp-servers"列表越拉越长，但配套的调试、监控、审计工具几乎为零。Anthropic 官方给了个 mcp inspector，是个 Web UI，能手动调用 Server 测接口——但那是测试工具，不是观测工具，两码事。

实际开发场景里，痛点长这样：

1. 多 Server 冲突。你同时挂了 filesystem、git、playwright、fetch 四个 Server，Agent 某次调用行为诡异，你不知道是模型选错工具了、还是参数传错了、还是某个 Server 返回了脏数据。
2. 工具调用嵌套。Agent 一次任务里可能连续调二三十次工具，每次的上下文和结果互相影响。没有时间轴视图，你根本理不清链路。
3. 成本审计。tools/call 返回的内容都要塞回模型 context，一个不小心，某个工具吐 200KB 内容进去，token 账单就爆了。你需要看到"哪次调用吃了多少 payload"。
4. 安全审计。企业环境下，Agent 到底读了哪些文件、发了哪些外网请求，合规上必须留痕。

Mcpsnoop 至少解决了前两个，第三第四条通过它的日志导出功能也能间接做。作者在 HN 评论区提到下一步会加 token 估算（用 tiktoken 类似方案对每条消息估算大小），如果做出来了，前三条就都齐了。

一个 Rust 实现的透明代理，能不能立得住

看代码质量的话，仓库现在大概 3000 多行 Rust，依赖不多：tokio、ratatui、serde_json、crossterm 这些常规配置。协议解析部分自己手写了个精简版的 JSON-RPC 2.0 处理器，没有引入完整的 MCP SDK——这个选择我觉得对。因为 Mcpsnoop 要做的就是透传+旁观，它不需要理解语义，只需要认得出消息边界和字段结构。真去用 MCP SDK 反而会因为版本追随的问题限制自己。

项目当前的短板也很明显：

• 只支持 stdio 和 HTTP，WebSocket 变体没做（虽然目前用 WebSocket 传输 MCP 的还不多）。
• TUI 没做鼠标支持，纯键盘操作，对不熟悉 vim 类快捷键的用户有门槛。
• 没有 GUI 版本，命令行环境之外没法用——虽然作者说"Wireshark for MCP"，但 Wireshark 的招牌就是它的 GUI 抓包界面。TUI 是权宜之计，真要做到普适，迟早得有个 Electron 或者 Tauri 的图形版。
• 没有过滤规则语言。Wireshark 强大的一半原因是它的 filter DSL（http.request.method == \"POST\" 这种）。Mcpsnoop 目前只能按 method 名简单过滤，做不到复杂条件组合。

更大的信号：MCP 到了"要工程化"的阶段

2024 年底 MCP 刚出来时，圈子里讨论的是"这协议好不好"、"能不能取代 Function Calling"。2025 年上半年讨论的是"有哪些好用的 Server 可以装"。到了 2026 年年中，讨论开始转向调试、监控、审计、性能——这些词组合起来就四个字：工程化。

Mcpsnoop 是这个转向的一个具体注脚。它不解决"AI 能做什么"，它解决"AI 做了什么你怎么知道"。前者是能力扩展，后者是可控性。Agent 应用要真正进企业，可控性比能力更关键。

顺带一提，OpenAI Hub 上跑 MCP 相关的 Agent 场景也不少——Claude 3.7、GPT-5、Gemini 2.5 这些模型都能通过统一 Key 调用，Agent 层挂 MCP、模型层用 OpenAI Hub 是不少国内团队的现成组合。Mcpsnoop 这类观测工具正好卡在中间那层，跟具体模型无关，谁用都能省事。

该不该现在装一个

如果你在写 MCP Server，或者你的 Agent 应用重度依赖 MCP 工具链，现在就装。这东西不是"锦上添花"，是"你早就应该有的东西"。它填的是 MCP 生态一个明显的空白。

如果你只是在 Claude Desktop 里挂了两个玩具 Server 偶尔用一下，那不用急，Mcpsnoop 主要价值在开发和排障场景。

项目 star 数从昨晚发布到现在增长挺快，作者 issue 回复也积极。开源协议是 MIT，直接 cargo install 就能装。看得出是个认真做的项目，不是一次性 demo。

参考来源

• Mcpsnoop GitHub 仓库 - 项目主页，含安装说明、TUI 演示和配置示例
• Model Context Protocol 官方仓库 - MCP 协议规范与官方 SDK
• awesome-mcp-servers - 社区维护的 MCP Server 集合，配合 Mcpsnoop 使用可以快速验证多 Server 场景
• modelcontextprotocol/servers - 官方维护的参考 Server 实现，包括 filesystem、gdrive 等常用组件