The inspector

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:

Face	Command	Reach for it when
Web UI	`mcpg inspector serve`	You are exploring — forms, rendered results, MCP Apps
Terminal UI	`mcpg inspector tui`	You are on SSH, or you live in a terminal
CLI verbs	`mcpg 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, 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

mcpg-inspector is part of the CLI suite, so most people already have it. install.sh fetches the whole suite by default:

bash

curl -fsSL https://raw.githubusercontent.com/mcpg-dev/source-code/main/install.sh | sh

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

Through a package manager instead. The npm package is @mcpg-dev/mcpg and carries every CLI in the suite as a bin; the PyPI distribution is mcpg-cli:

bash

npx -p @mcpg-dev/mcpg mcpg-inspector --help   # npm
pip install mcpg-cli && mcpg-inspector --help   # PyPI

brew tap mcpg-dev/mcpg https://github.com/mcpg-dev/source-code
brew install mcpg-inspector

Prebuilt binaries exist for x86_64 and aarch64 Linux (glibc and musl), Apple Silicon, and x86_64 Windows, plus an x86_64 Windows .zip. See Install MCPG for the other paths.

Reached as mcpg inspector … through the front door, or invoked directly as mcpg-inspector. Both are the same binary.

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.
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.