mcpsnoop: Wireshark for MCP — Debug AI Agent Tool Calls

So you spend an hour wiring up an MCP server. Your Claude Code client connects fine — no errors. But when you ask it to use a tool, nothing happens. Or worse, it calls the tool with arguments that look weird, and you have no idea why.

That’s the blind spot. The MCP Inspector is a standalone test client — it can’t see what your real client is actually sending. You’re debugging in the dark.

So when I stumbled across mcpsnoop (127★ on GitHub, 18 stars/day this week) — a project that calls itself “Wireshark for MCP” — I had to try it immediately.

Here’s what I found.

The Blind Spot in MCP Debugging

But every MCP setup has a data path: your AI client (Claude Desktop, Claude Code, Cursor, Copilot) talks to your MCP server over JSON-RPC. When something goes wrong, the natural reflex is to fire up the MCP Inspector.

But here’s the problem: the Inspector is its own client. It connects independently to your server. It never sees the actual traffic between your real client and the server.

Tail the server logs? Sure — but logs are post-hoc. So you only see what the server thinks happened, not what the client actually sent in the request. Subtle issues — extra whitespace in a parameter, wrong argument name, a timeout that the client handles differently — are invisible.

And I’ve been burned by this more times than I’d like to admit. Last week I spent two hours debugging why Claude Code kept calling a search tool with an empty query parameter. Turns out the MCP server’s schema declared the field as "query_string" instead of "query" — a mismatch I’d have spotted in seconds with the right tool.

What Is mcpsnoop?

So mcpsnoop is a transparent proxy that sits right between your client and server. Every JSON-RPC request and response passes through it, and it renders them in a real-time TUI right in your terminal.

The core insight is simple but powerful: instead of simulating a client (like MCP Inspector does), mcpsnoop intercepts real traffic from your actual client. You see exactly what the client sends and exactly what the server responds.

It’s written in Go, MIT licensed, and actively maintained — latest update was yesterday. If you’re already running other MCP tooling like GitHub MCP Server or MCP Toolbox for Databases, mcpsnoop slots right into the same workflow.

Getting Started in 30 Seconds

Installation is straightforward:

# macOS/Linux
brew install mcpsnoop

# Or if you have Go installed
go install github.com/kerlenton/mcpsnoop@latest

Then wrap your MCP server command in your client config:

{
  "mcpServers": {
    "my-server": {
      "command": "mcpsnoop",
      "args": ["--", "python", "server.py"]
    }
  }
}

Now open a second terminal window, run mcpsnoop, and you’ll see the TUI pop up. Now every tool call your AI client makes shows up in real time — method name, parameters, response, latency. It took me about 30 seconds to set up, and I was immediately looking at raw JSON-RPC frames.

There’s also an HTTP reverse proxy mode if your MCP server speaks HTTP:

mcpsnoop http --target http://localhost:3000/mcp --listen :7000

Three Real Debugging Scenarios

1. Tool Called with Wrong Arguments

So I set up mcpsnoop between Claude Code and a file-search MCP server. When I asked “find files modified in the last week,” I expected to see {"method": "find_files", "params": {"pattern": "*.py", "modified_after": "..."}}. Instead, the frame showed modified_after was missing entirely — my server schema had a bug. Without mcpsnoop, I’d have checked the server logs (which would show the server processing the request, not what was missing).

2. Silent Timeout

But one of my MCP servers occasionally hung on complex queries. Still, in the mcpsnoop TUI, I could watch the request go out, see the server start streaming a response… and then nothing. The TUI showed the exact latency spike, proving it was a server-side issue, not a client timeout configuration problem.

3. Streaming HTTP Debug

And for MCP servers running over HTTP, the reverse proxy mode (mcpsnoop http) captures every SSE event and JSON-RPC frame. I used this to debug a streaming tool call where the server was sending malformed delimiter bytes — spotted it in the raw frame view in about 2 minutes.

mcpsnoop vs MCP Inspector: Not Competitors

But they’re complementary. MCP Inspector is great for verifying a server works at all. mcpsnoop is what you reach for when things go wrong with your actual setup.

Running mcpsnoop as a 24/7 Debug Service

So if you’re running multiple MCP servers or building a development pipeline around MCP, you can deploy mcpsnoop persistently. Throw it in a Docker container on a cheap VPS and route traffic through it.

Want to run a 24/7 MCP debugging setup? Then DigitalOcean’s $6/month droplet is more than enough to run mcpsnoop plus all your MCP servers. New users get $200 in credit — plenty to experiment with.

Deploy your MCP stack: DigitalOcean offers $6/month droplets — enough to run mcpsnoop alongside all your MCP tools. New users get $200 in free credit to experiment with.

Go deeper: Building LLM Powered Applications teaches you to build intelligent apps and agents with LLMs. Covers MCP, tool-use, function calling, and production deployment patterns — directly relevant to the MCP ecosystem mcpsnoop lives in.

The Bottom Line

So mcpsnoop fills a genuine hole in the MCP ecosystem. The MCP Inspector is fine for smoke-testing a server, but when you need to debug real traffic between your actual client and server, a transparent proxy is the right tool. Even the fact that it’s a single brew install away, with a clean TUI and both stdio and HTTP proxy modes, makes it a must-have for anyone building with MCP seriously.

Still debugging MCP servers and reaching for logs and blind guesses? Then give mcpsnoop a try. You’ll see the problem in seconds instead of hours.