MCP Inspector

There are three inspectors, and they answer different questions.

	Public Inspector	Project Inspector	Gateway Inspector
Where	dev.odel.app/inspector	The Inspector tab inside a project	The Inspector tab inside a gateway
Talks to	Any MCP server, anywhere	Your module's dev deployment	The gateway's upstream server
Account needed	No	Yes — and access to the project that includes Use the inspector	Yes — and access to the gateway that includes Use the inspector
You supply	A URL, and auth if the server wants it	Nothing; it knows where your module is	Nothing; it uses the gateway's stored credentials

The public one is a general-purpose MCP client that happens to live on Odel. The project one is wired to your own deployment, so there's no URL to paste and nothing to authenticate.

Connecting to a server

Paste a URL and press Connect. Everything else on the connection panel is optional:

Bearer token — sent as an Authorization header. For servers behind a static key.
OAuth — for servers that want a real sign-in. The inspector prefers a Client ID Metadata Document, falls back to Dynamic Client Registration, and asks you for a client ID only when the server offers neither. There's a quick flow and a guided one that walks through each step and shows you the authorization code.
Protocol — Auto by default: the inspector tries server/discover and falls back to initialize. Pick Legacy (and a version) or 2026-07-28 to see how a server behaves against one revision.
Try a server — while the URL box is empty, one click fills in and connects to the Odel Calculator or the MCP project's example server, which sits behind OAuth.

The server address lives in the ?url= query parameter, so a connected session is a link you can send someone. If you turned the relay off or pinned a protocol, the link carries that too (relay=0, era=) and it overrides the opener's saved settings; otherwise theirs apply.

CORS

The public inspector sends its requests through Odel's relay by default, because many servers don't allow browser requests. Switch off Use the relay under Connection › Transport, or open the inspector with ?relay=0, and it calls the server from your browser directly; a server that doesn't send CORS headers will then refuse it, and the error offers Enable relay & retry. Your choice is remembered.

The tabs

Tools, Resources, and Prompts list what the server exposes and let you call it. Tool arguments get a generated form from the input schema, with a Raw JSON button to edit them as JSON instead. Results show the content blocks, the structured content checked against the tool's output schema, and any _meta.

In the public inspector, a Vars tab appears when the server exposes the odel://config resource — which is to say, only for Odel modules. That's the marker doing its job: the inspector can tell an Odel module from a plain MCP server. On an Odel URL (a hosted module or a gateway) the tab is always there, but only to say that Odel sets your context and secrets from your account and you can't override them.

Vars: pretending to be the proxy

In production your module doesn't get called directly. Odel's proxy authenticates the user, resolves their secrets, and injects both into the request's _meta. Connect to your module straight from the browser and none of that happens, so anything reading context or secrets sees an empty envelope.

The Vars tab fills it in. Set the identity fields and any secrets, flip the switch, and the inspector injects the same envelope on every tools/call — so a module reading them through the SDK behaves exactly as it would behind the proxy. It reads your declared config to know which secret names to prompt for.

Values you type here are test values in a browser tab. Use a scratch key, not the production one.

DevTools

The DevTools panel shows every JSON-RPC message in both directions — the initialize handshake, each request, each response, and any notifications. Toggle it with the button in the header or Cmd/Ctrl + Shift + D. Whether it's open is remembered between visits.

This is the tab to open when a call fails in a way the error message doesn't explain.

History, in the project and gateway inspectors

Both keep your last 50 tool executions for that project or gateway — what you called, the arguments, whether it worked, and how long it took. You can replay any of them with the original arguments, or clear the list. It's stored in your browser for the session, so it survives a refresh and disappears when you close the tab.

Where your data goes

Nothing you type into the public inspector is stored on Odel. Server URLs, OAuth tokens, execution history, and your relay and DevTools preferences all live in your own browser.

The exception is the relay, which is on by default: requests, OAuth calls included, are relayed through Odel to reach the server, so they pass through infrastructure Odel operates. It stores no request or response bodies. Switch it off if a server allows browser requests and you'd rather connect directly. The URL you enter is also checked against the Odel marketplace, so the inspector can show its listing when it has one.