Skip to main content
The inspector is the live timeline at app.heymcp.dev. Every session has one, linked from the CLI as a short …/s/x7k2 URL.

​
It’s a list of attempts, not frames

On the wire, a tool call is two messages: a request going one way and a result coming back the other. The inspector folds them into one row:
That’s what you actually want to see — one attempt, with its outcome and how long it took — rather than two rows you have to mentally staple together. A response that arrives without a matching request still gets its own row. Hiding an orphan would hide a real problem.
The database keeps the two halves separate, which is why heymcp export is lossless. The folding is a reading convenience, not a storage decision.

​
Latency is measured at the edge

The number on each row is the round trip as seen from the edge, because that’s the only place both halves of an exchange are visible. It includes your local server’s work plus the hop to your machine, which is the number that matters when you’re deciding whether a tool feels slow to an agent.

​
What the rows say

The inspector writes plain English, not protocol labels. The same events show up in the CLI ticker as a terse glyph column instead. Every row that has an author names it. One tunnel can carry several clients at once, so a row that just read Called server/discover would get read as belonging to whichever client said hello above it. A replayed call reads Replaying place_order rather than naming a client, so a replay is never mistaken for real agent traffic.

​
Errors that aren’t your fault

Not every error is a problem, and the inspector distinguishes them. An error is treated as benign — shown as handled or declined rather than hmm, that broke — when it is the protocol working as designed:
  • Your server declining an optional method the client probed for.
  • An HTTP 404, which is how the spec tells a client its session is gone and it should re-initialize.
The rule is deliberately narrow. A tools/call that errors stays red, even though the client may well retry it — that’s somebody’s work failing. Benign errors don’t count toward the Problems tally, so the number next to that filter is the number of things actually worth looking at.

​
Filters

All shows everything. Problems shows only rows that failed, excluding the benign ones above. The empty state for the Problems filter reads “Nothing has gone wrong. That’s the good outcome.”, which is the honest framing: an empty problems list is a result, not a missing feature.

​
Which client is this?

Each row is fingerprinted with the client that produced it — Claude.ai, ChatGPT, Claude Code, Gemini, Grok, Cursor, VS Code, MCP Inspector, curl, or HeyMCP’s own probe. This is more useful than it sounds. When a tool works in Claude Code and silently doesn’t in Claude.ai, the timeline shows you exactly which client got as far as what. HeyMCP’s own probe is always fingerprinted as the probe, never mistaken for a real client, so it never pollutes your view of what agents actually did. The probe goes in through the front door — the same routing, path policy and tee a real agent hits — so its traffic is recorded like anyone else’s. Activity hides those rows by default, because on a fresh tunnel they would otherwise be the whole timeline before your agent has connected. Show HeyMCP’s own check, under the list, brings them back for when the probe itself is what you’re debugging. What the probe found lives in the Handshake tab.

​
Replay

Expand any tool call and you get Try it again — HeyMCP re-fires that exact request against your local server. This is the loop the product is built around:
1

An agent calls your tool and it breaks

The row goes red. Expand it and you can see the arguments the agent actually sent, which is frequently the surprise.
2

You fix your server

Edit the code. Your dev server reloads.
3

Replay

Same arguments, same route, no waiting for the agent to try again — and no trying to talk it into producing the same call twice.
Replayed events are flagged as replays so they don’t look like real agent traffic later.

​
The payload

Expanding a row shows its payload straight away — the click that opened the row was the request to see it. The viewer is a real one, not a wall of text: objects and arrays fold, types are told apart by colour, and the filter box searches keys and values at once. Filtering keeps the trail down to each match so you can see where it lives, and says how many rows it hid rather than quietly showing you a subset. Searching a key name — arguments — keeps that whole subtree, because that is what you were asking for. Big payloads open with their shallow structure expanded and large collections folded, so a tools/list from a server with eighty tools stays readable. Paired rows show two viewers, Sent and Came back, each with its own filter.

​
Headers

At the top of the payload panel, headers shows the HTTP headers for whichever half you’re looking at — the client’s request headers, or your server’s response headers. Inside the panel rather than below it, because the payload scrolls within a fixed height and anything underneath it is easy never to find. This is where the failures that produce no error at all become visible. Claude fails silently on a response content-type it doesn’t accept, and the MCP-Protocol-Version header is what earns a server/discover its 400. The timeline could always show you the effect; the headers show you the cause. Secrets never leave the relay. Authorization, cookies, API keys and anything whose name looks like a credential are redacted before they are stored — the header name survives, and for auth headers so does the scheme, because “Bearer” versus “Basic” is usually the bug. The value does not. The one identifier deliberately kept is Mcp-Session-Id: it is the spec’s own routing identifier and what the inspector pairs requests on. Rows recorded before this shipped have no headers, and the panel stays away rather than offering you an empty box. Exchange details, underneath, is the same event in protocol terms — direction, kind, rpc id, stream, latency, client — for when the plain-English layer is what you’re trying to see past. It covers both halves, which is why it is not called request details.

​
The handshake tab

Alongside Activity is Handshake, carrying the count of findings from the probe. That’s the report on your server itself, as opposed to the traffic through it. You can re-run it from there after a fix — the reports are kept as history, so you can see whether the fix landed.