Connect your client
What an Odel URL looks like, what happens the first time you use one, and what you never have to paste into a config file
Connecting anything on Odel to anything that speaks MCP is one gesture: copy a URL, give it to your client, sign in when the browser opens. There is no client ID to obtain, no secret to store, and nothing to configure per module beyond the URL itself.
This page covers the Odel side, which is the same everywhere. The part that differs per client — which file, which settings panel — is on the Integrations pages.
The URL
Everything you can connect to has an address under mcp.odel.app. There are three shapes,
and which one you get depends on what you're connecting to, not on how you connect.
| Shape | What it is | Example |
|---|---|---|
/@<owner>/<module> | a module | https://mcp.odel.app/@odel/calculator-basic |
/g/<owner>/<name> | a gateway, by its readable address | https://mcp.odel.app/g/@acme/github |
/g/<id> | a gateway, by its generated id | https://mcp.odel.app/g/gw_7f3a… |
Both gateway forms point at the same gateway and behave identically. Every gateway gets both the moment it's created, and the readable one is easier to recognise in a config file.
Where to find it
A module's URL is on its page in the marketplace, next to the connect state. An organization's gateway has its URL on the gateway's page in the developer portal, where the organization manages it. Once you've added a module or a published gateway, its marketplace page carries the same address behind a copy button.
Copy it from there rather than assembling it by hand from the table above: a module's address is matched exactly, so a character out of place fails in a way that looks like an auth problem rather than the typo it is.
Signing in, the first time
Point your client at the URL and it will tell you it needs authorization. From there:
Your client registers itself. Odel supports dynamic client registration, so a client that has never spoken to Odel before can introduce itself and get its own credentials automatically. You don't do anything here and you never see the result.
A browser opens and you sign in to Odel. If you're already signed in, this is the approval screen — or, when you haven't added the module or gateway yet, a page that asks you to add it first.
You approve that client's access. The approval names the specific module or gateway, not your whole account — so approving one thing doesn't grant access to the rest.
The client gets a token and the tools appear. The token belongs to that client alone, for that resource alone.
You'll do this once per client per thing you connect. After that the client refreshes on its own; you won't be asked again unless you revoke it, remove it from your account, a gateway you use starts sending your identity to its own server, or you stay away for a month.
Why there's no client ID to copy
Most MCP clients have nowhere sensible to put a client ID and secret, and with Odel they don't need one — the client registers itself. Some upstream services don't offer that, which is the entire reason gateways exist: a gateway holds that one registration so the people using it don't have to.
What never goes in a config file
Your Odel URL is not a secret — it identifies what you're connecting to, and it's useless to anyone who can't sign in as you.
That's the point of connecting through Odel. A module's own API keys are configured once on Odel and injected at call time, so they never reach your client's config, your shell history, or a file you might commit. If a setup guide anywhere asks you to paste an API key next to an Odel URL, something has gone wrong.
One URL per thing
There's no single account-wide URL that carries everything you've installed. Each module and each gateway is its own endpoint, and you add the ones you want to a given client.
That's deliberate: a client only sees the tools you gave it, so a coding assistant doesn't have to carry your unrelated tools around, and revoking one doesn't disturb the others.
Set it up in your client
Using a client that isn't listed
Anything that supports remote MCP servers over Streamable HTTP with OAuth will work — Odel is a standard authorization server and asks for nothing unusual.
Two things are worth knowing if you're debugging a client that won't connect:
- Streamable HTTP only. Odel doesn't open an SSE stream, so a
GETto any of these URLs answers405on purpose. A client that only speaks the older HTTP+SSE transport can't connect. - The token is bound to the resource. A token issued for one module or gateway isn't accepted at another. If you're moving a token between endpoints by hand, that's why it fails.
Building rather than connecting?
If you're testing a server you're writing, the MCP Inspector connects to any MCP server and shows you the raw traffic — no Odel account needed.