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 — it's your project	Yes — the same access as managing the gateway
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 registers itself dynamically, so there's no client ID to obtain first; there's a quick flow and a guided one that walks through each step and shows you the authorization code.
Protocol version — pinned to the latest by default. Change it to see how a server behaves against an older revision.
Quick connect — one click to fill in the URL for a listed Odel module.

The server address lives in the ?url= query parameter, so a connected session is a link you can send someone. Reconnecting from that link reuses your saved proxy preference.

CORS

The inspector runs in your browser and calls the server directly, so a server that doesn't send CORS headers will refuse it. When that happens the error offers Use Proxy, which routes the request through Odel instead. 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, and results are shown both structured and raw.

A fourth tab, Vars, appears only 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.

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 proxy and DevTools preferences all live in your own browser.

The exception is the CORS proxy: when it's on, requests are relayed through Odel to reach the server, so they pass through infrastructure Odel operates. Leave it off unless a server needs it.