How are you debugging your MCP servers today?

[adityachilka1]

I've spent the last few weeks talking to people building MCP servers and asking how they debug them today. The answers were depressingly consistent:

• "I tail my server logs and squint."
• "I print the JSON-RPC envelope from inside my tool handlers."
• "I run the official MCP Inspector when something is really broken."

Curious — what's your actual workflow? Especially interested in:

1. How do you know which tool a model picked and why?
2. How do you compare two runs that should have done the same thing?
3. How do you tell a teammate "the server returned this exact frame" without screenshots?

Reply with your setup — even a bad one is data.

[adityachilka1]

Sharing my own setup since I built mcp-devtools specifically to scratch this itch.

The 30-second version. Wrap your server with the proxy and open the inspector:

mcp-devtools proxy --upstream "node ./my-server.js"
# → open http://localhost:7456/inspect

Every JSON-RPC frame in both directions shows up in the timeline as it happens. The detail view shows the parsed envelope (method, params, result/error), so the three questions become:

1. Which tool, and why? The timeline shows each tools/call with the exact name and arguments the model picked. The preceding tools/list shows what the model could see when it picked.
2. Compare two runs. Use record to capture each:

   mcp-devtools record --upstream "node server.js" --out before.mcptrace
   # … change prompt …
   mcp-devtools record --upstream "node server.js" --out after.mcptrace

   Diff support is on the v0.2 roadmap; for now gunzip -c x.mcptrace produces grep-able JSONL.
3. Reproducible bug reports. Send the .mcptrace file. The receiver replays it with mcp-devtools open file.mcptrace and sees the exact same wire transcript you saw.

Genuinely curious what's missing — drop a reply with whatever your workflow can't do today.