Run it for a team

The gateway-supervised sidecar, the standalone bind and token posture, and the hosted profile — what each guarantees, and what each deliberately refuses.

An inspector can spawn processes for stdio: targets and holds whatever credentials its targets carry. Every deployment shape below starts from that, and differs in what it is willing to give up.

Alongside a gateway

bash

mcpg --config server.yml --inspector

The gateway supervises a sibling inspector process: readiness-polled, killed with its parent, and pre-registered against that gateway. It hands the child two things:

this gateway as a target, at the scheme and path it actually serves, with a per-boot identity that clears the default trust floor. On a stock config it lists tools immediately, where an anonymous caller would see none.
every federated upstream, so one session can compare what mcpg re-serves against what the upstream itself offers — the question behind most "why is this tool missing" reports. Each carries the wire the federation pinned and the same private-address posture the gateway uses for it.

No credential rides on the command line. The gateway's token travels by environment, because argv is readable by every process on the box; a federation's credential stays with the gateway, since the inspector dialling that upstream directly is a different caller.

The URL is printed once the gateway itself is answering, not when the sidecar comes up. The sidecar is ready in milliseconds while the gateway still has plugins to load, so announcing early would put the first click on a refused connection to the pre-wired target — which looks like the inspector being broken. If the gateway does not come up within a minute, the URL is printed anyway, with a note that its own target will not connect yet.

--inspector-bind, --inspector-auth-none and the rest pass through to the child.

A terminal onto that session

bash

mcpg inspector tui --attach 'http://127.0.0.1:7846/'

--attach points the TUI at a running inspector instead of dialling targets itself — its targets, its sessions, its wire log. That is the difference that matters against a gateway sidecar: the sidecar holds the frames of the gateway's own traffic, and a TUI dialling the gateway directly opens a fresh session and sees none of them.

Pass the token in MCPG_INSPECTOR_TOKEN rather than in the URL.

Standalone

bash

mcpg inspector serve --target http://127.0.0.1:8787/mcp --open

The URL it prints carries a per-boot session token. Because the API can spawn processes for stdio targets, the defaults are deliberate:

Setting	Default	Why
bind	`127.0.0.1:7846`	loopback only
token	required	the API can spawn processes
`--auth-none`	off	drops the token, and only on a loopback bind
`--dangerously-bind-all-interfaces`	off	reaching beyond this host is deliberately ugly to ask for

The flag names are the documentation here: if reaching an inspector from another machine feels like it should be easier, that is the design.

Hosted

--hosted is the profile inspector.mcpg.cloud runs, and it is a profile rather than one switch:

no stdio targets — a hosted instance does not spawn processes for strangers;
no private-address egress, overridden rather than merely validated;
per-address rate limits;
OIDC sign-in — it refuses to boot without an issuer, and refuses --auth-none and --session-token outright, because one shared credential would mean one shared workspace.

Each signed-in user gets their own workspace: targets, and the credentials attached to them, are never visible to anyone else. Nothing is persisted, so a restart signs everyone out.

The hosted inspector is free to use — there is no plan, tier or licence behind it, and the same is true of the CLI.

Point it at a public server, or at a local one through mcpg --tunnel.

Choosing between them

You want	Use
To debug the gateway you are already running	`mcpg --config … --inspector`
To look at some other server, from your own machine	`mcpg inspector serve`
To give a team one URL, with per-user separation	`--hosted` behind your IdP
To look at a server from a script or CI	the one-shot verbs — see Gate CI on it

What it never persists

Nothing. Sessions and history live in memory for as long as the process does; a recording is a file someone chose to write. There are no share links and no retention. That is what lets the hosted instance run without a database, and what makes a restart a clean slate rather than a data-handling question.

Next steps

Reach a protected server — OIDC, OAuth and AAuth from the client side.
Recordings — the one thing that does leave the process.
mcpg inspector reference — every verb and flag.