kerlenton/mcpsnoop

Context A session log already holds every response the server gave, byte for byte. Nothing in the binary can play them back. internal/replay/replay.go:47 is the closest thing today and it goes the other way. func Replay(ctx context.Context, command []string, cwd, method string, params json.RawMessage, timeout time.Duration) (Result, error) It spawns the real server from the meta frame's command, handshakes, and sends one request. That needs the server binary, its credentials and its network, and it answers a single request rather than a session. internal/exporter/exporter.go:26-30 renders json, html, text, otlp and har, none of which anything can execute. cmd/mcpsnoop/main.go:311 registers all ten subcommands and none of them serves. $ mcpsnoop mock session.jsonl mcpsnoop: tracing "mock session.jsonl" (session session.jsonl-97045-15efbc7ed607) mcpsnoop: exec: "mock": executable file not found in $PATH $ echo $? 1 Separate tools exist for only this. mcp-recorder (https://github.com/dev

Context The stream filter is the fastest way to get from a whole session down to the six frames that matter, and it is the one part of mcpsnoop that cannot leave the TUI. The grammar lives entirely in internal/tui, in filterEvents at internal/tui/model.go:1074 and matchToken at internal/tui/model.go:1097, and the result is only ever assigned back to the model in applyFilter at internal/tui/model.go:662. No command can reach it. newExportCmd declares its flags at cmd/mcpsnoop/main.go:512-517, newCheckCmd at cmd/mcpsnoop/check.go:141-146 and newOpenCmd at cmd/mcpsnoop/main.go:846-849, and none of the three has anything that narrows a session. $ mcpsnoop export trim2.jsonl --filter 'tool:echo' mcpsnoop: unknown flag: --filter $ mcpsnoop check trim2.jsonl --filter 'tool:echo' mcpsnoop: unknown flag: --filter The TUI cannot save its own filter either. exportCurrent at internal/tui/model.go:1282 calls exporter.Build(m.store, id) at internal/tui/model.go:1296, which takes the session by id a

Context Elicitation is the one path in MCP where a human types data into a server. Under MRTR the question and the answer are no longer two halves of one JSON-RPC exchange, they are fields buried inside two different requests. The 2026-07-28 elicitation page is explicit that the request is "delivered inside InputRequiredResult.inputRequests" and the answer comes back "returned inside inputResponses on the retried request" (https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation). mcpsnoop already does the hard half of that. matchRetry at internal/store/store.go:1378 links a retry back to the operation it continues, Ingest applies the link at internal/store/store.go:493, and the TUI renders it as continues id N at internal/tui/view.go:790. What it never does is read either side of the exchange. parseInputRequired at internal/store/store.go:1289 opens every inputRequests entry and keeps exactly one field out of it, the method name. methods := make([]string, 0, len(r.I

Context A developer pointed at a remote MCP server sees a 401 then a run of 403s and has no way to tell from mcpsnoop whether the token has the wrong audience, is missing a scope, or expired. mcpsnoop sits in the one place where the challenge and the credential both pass, and today it treats the challenge as display text and never looks at the credential at all. The response side is captured. internal/proxy/http.go:251 reads WWW-Authenticate off every response into route.challenge (internal/proxy/http.go:89), and internal/proxy/frame.go:100-106 carries it as AuthChallenge, whose own comment calls it "the one response header worth keeping verbatim". Nothing reads it back except display. internal/tui/view.go:706-707 concatenates it onto a list row, internal/tui/view.go:1121-1122 prints it in the inspector, internal/exporter/exporter.go:810 copies it to the JSON export, internal/store/views.go:80-81 passes it through. A grep for insufficient_scope, resource_metadata, error_description or

Context An agent run normally talks to several MCP servers at once. mcpsnoop records each one as its own session with nothing tying them together, so the question people actually have, what happened during this run, has no answer. Reproduction. One client process spawns three shims, initializes each, lists tools on each, then calls one tool on each. The client propagates the same W3C trace context on every request, which is what a client instrumented with OpenTelemetry does. $ ls "$MCPSNOOP_HOME"/sessions files-97144-a9c6e9771489.jsonl github-97145-5aad0ff61b2c.jsonl search-97146-bc2bed02c554.jsonl Everything the capture knows about where a session came from lives in its meta frame. $ head -1 "$MCPSNOOP_HOME"/sessions/files-97144-a9c6e9771489.jsonl {"session_id":"files-97144-a9c6e9771489","server_label":"files","seq":1, "ts":"2026-08-01T19:20:39.290898+03:00","direction":"meta","transport":"stdio", "raw":{"command":["python3","/tmp/server.py"],"cwd":"/Users/me/work"}} SessionMeta h