Inspector
Inspectorbeta

The inspector

rc
v0.1.0-rc.14

One binary, three faces over one engine — a web UI, a terminal UI and scriptable CLI verbs that work against any MCP server, and come pre-wired when you run one against a gateway.

An MCP server that "doesn't work" is almost never one failure. It is a tool that isn't listed, a call that comes back refused, a schema the client fills in wrong, or a frame that never arrives. Each has a different answer, and none of them is visible from the client side.

mcpg inspector is how you look. It works against any MCP server, not just an mcpg gateway: point it at a URL, a stdio: command line, or a recording.

Beta. The surface is complete and covered by end-to-end tests, but it is pre-1.0 and flags may still change. Every verb and flag is at mcpg inspector.

Three faces, one engine

The same engine drives all three, so they cannot disagree about what a server said. Pick by where you are, not by what you need:

FaceCommandReach for it when
Web UImcpg inspector serveYou are exploring — forms, rendered results, MCP Apps
Terminal UImcpg inspector tuiYou are on SSH, or you live in a terminal
CLI verbsmcpg inspector list …A script or a CI job is asking the question

The web UI has a pane per surface: tools, resources (and templates), prompts, subscriptions, events, diagnose and wire. The TUI covers the same ground — tab moves between screens, j/k selects, c connects, a edits arguments, enter runs whatever the screen is about, and ? lists every key.

The fastest path

If you are already running a gateway, add one flag:

bash
mcpg --config server.yml --inspector

The gateway supervises an inspector alongside itself and prints a URL with a token. It comes up already connected to that gateway, and to every federated upstream behind it — no target to add, no credential to paste. It dies with the gateway and never outlives it. See Run it for a team for what that pre-wiring hands the child, and why the URL appears later than the process does.

Standalone, against anything. --target is repeatable, so several servers can sit side by side:

bash
# a server over HTTP
mcpg inspector serve --target http://127.0.0.1:8787/mcp

# a server you launch yourself, over stdio
mcpg inspector serve --target 'stdio:npx -y @modelcontextprotocol/server-everything'

A target takes three forms anywhere one is accepted — a URL, a stdio: command line, or a JSON object when you need the full spec:

bash
http://host:port/mcp
stdio:npx -y @modelcontextprotocol/server-everything
'{"url": "https://gw.example/mcp", "bearer": "…"}'

A fourth form, recording:./session.jsonl, replays a captured exchange with the server gone — see Recordings.

Installing it

The inspector ships in two forms:

  • The full inspector, the mcpg-inspector binary with all three faces, ships as the image ghcr.io/mcpg-dev/mcpg-inspector (multi-arch, pullable without credentials; its default command is mcpg-inspector serve). To run it outside a container, build it from source in mcpg-dev/mcpg-inspector.
  • The terminal UI alone, the mcpg-inspector-tui binary, ships as a release archive for x86_64 and aarch64 Linux (glibc and musl), Apple Silicon, and x86_64 Windows (Windows as a .zip) and as the image ghcr.io/mcpg-dev/mcpg-inspector-tui. It takes the same flags as mcpg inspector tui. install.sh installs it with the rest of the CLI suite:
bash
curl -fsSL https://raw.githubusercontent.com/mcpg-dev/mcpg/main/install.sh | sh

# or just this one binary
curl -fsSL https://raw.githubusercontent.com/mcpg-dev/mcpg/main/install.sh \
  | sh -s -- --bin mcpg-inspector-tui

For a manual install, take mcpg-inspector-tui-<version>-<triple>.tar.xz for your platform from the inspector's own releases. The model-context-protocol-gateway package on npm and PyPI does not carry the inspector, and there is no Homebrew tap. See Install MCPG for the other paths.

mcpg inspector … through the front door and mcpg --inspector run the full mcpg-inspector binary, so it must be on PATH or next to mcpg.

Both protocol revisions

The inspector speaks 2025-11-25 and 2026-07-28 because it uses the gateway's own wire types and MCP client — the same code, extracted into shared crates. The inspector and the gateway cannot disagree about a revision.

It probes and negotiates by default. Pin one when you want to test a specific wire:

bash
mcpg inspector list https://gw.example/mcp tools --protocol-version 2025-11-25

See Protocol versions for what differs.

What it never keeps

Nothing is persisted. Sessions and history live in memory for as long as the process does; a recording is a file you chose to write. There are no share links, no retention, and no custody of anyone's traffic. The hosted instance runs the same way, which is what keeps it database-free.

Where to go next

  • Debug a server — the four questions it answers, and which surface answers each.
  • Reach a protected server — why a call was refused, OAuth sign-in, and AAuth agent identity.
  • Watch MCP Events — poll, stream and webhook subscriptions, each checked against what the extension requires.
  • Recordings — capture an exchange, replay it with the server gone, attach it to a bug report.
  • Gate CI on it — exit codes as a contract, capability drift, schema enforcement.
  • Run it for a team — the gateway sidecar, standalone posture, and the hosted profile.
  • mcpg inspector reference — every verb and flag.