mcpsnoop: Wireshark for MCP, installed in a single command
If you’ve spent real time building against MCP servers, you already know the specific frustration this tool is aimed at. A tool call that silently doesn’t fire. A capabilities handshake that doesn’t match what you expected. A request that just… hangs. And when you turn to the official MCP Inspector to understand what happened, it doesn’t help — because the Inspector isn’t looking at your actual conversation. It connects as its own separate client, runs its own test calls, and shows you what it sees, not what your real client and real server actually said to each other.
mcpsnoop, a new open-source tool published on GitHub and posted to Hacker News on July 4th, goes the opposite direction: it sits directly in the data path between your real client and your real server, and shows you the traffic as it happens.
The blind spot it solves
MCP runs on JSON-RPC 2.0, and there’s a subtlety in the protocol that trips up a lot of debugging: a tool call can come back as a perfectly successful response at the transport level while carrying inside it, in result.isError, an application-level failure. If you’re only looking at HTTP status codes or basic request logs, that failure is invisible — the call “succeeded” as far as your logging is concerned, even though the tool just reported that it failed.
The Inspector’s side-channel architecture can’t detect this either, since it never sees the actual call in the first place. mcpsnoop’s entire design is built to occupy the real pipe instead of standing off to the side, so it sees:
- Every JSON-RPC frame between your real client (Claude Desktop, Cursor, Claude Code, or your own agent) and your real server, no matter what language the server is written in
- Responses with
isErrorat the tool level marked explicitly, not hidden - Hung calls, shown live with a timer running instead of hanging silently
- The capability handshake that both sides actually negotiated when connecting
How to use it
It’s a single Go binary with two built-in roles. As a shim, it wraps your server’s startup command and forwards the bytes as-is while sending a copy of each frame to the hub. As a hub, it’s the live TUI you actually look at. They find each other automatically through a known socket and disk logs — no manual pairing, no required startup order.
Wrapping a stdio server looks like this in your client config:
{
"mcpServers": {
"my-server": {
"command": "mcpsnoop",
"args": ["--", "node", "build/index.js"]
}
}
}
Everything after -- is the command that normally starts your server. For streamable-HTTP servers, it runs as a reverse proxy instead:
mcpsnoop http --target http://localhost:3000/mcp --listen :7000
Once running, the TUI supports live filtering with space-separated tokens — tool:search status:slow to isolate slow calls to a specific tool, or dir:s2c kind:req to surface requests initiated by the server, like sampling or roots. Captured sessions can be replayed against a fresh, isolated copy of the server, so you can reproduce a specific failure without re-running your entire agent session, and exported afterwards as JSON, HTML, or plain text.
Installation
go install github.com/kerlenton/mcpsnoop@latest
or via Homebrew, though with a caveat to be aware of upfront: a brew install mcpsnoop without a tap requires the project to clear Homebrew core’s notability bar (stars, forks, watchers), something it doesn’t quite reach at this stage. For now, Homebrew installations come by trusting the author’s tap directly, or you can download a prebuilt binary from the Releases page on GitHub.
Before using it
It’s a fresh project — the repo is small, pre-1.0, and follows semver loosely while at 0.x (which means minor releases can still change user-facing behavior). The comparison to the official Inspector is the author’s own framing, not an independent benchmark, though the architectural distinction it points out — being in the pipe versus connecting as a second client — is accurate and easy to verify by reading the source code of either tool.
It’s also worth clarifying that mcpsnoop only executes the server command you explicitly wrap it around, so apply the usual precaution: only wrap servers you trust, and run ones you don’t in a container.
For anyone who’s lost time guessing at MCP failures from scattered logs, this is a genuinely useful, pinpoint solution — small, focused, and addressing one specific blind spot instead of trying to be a complete observability platform.