What is Odel?
Odel is a dock for MCP — plug in servers that each work differently, get one URL that works everywhere.
The Model Context Protocol standardised how an AI client talks to a tool. It did not standardise anything around that conversation, and that turns out to be most of the work.
Every server authenticates differently. Some want an API key in a header, some want a full OAuth flow against a vendor you already have an account with, some want nothing at all. Every server has to be hosted by somebody. And every client — Claude Code, Cursor, Claude Desktop, ChatGPT — supports a different slice of the protocol and a different way of being configured.
So "add this tool to my assistant" is rarely one step. It's finding the server, working out its auth, putting a secret somewhere you'd rather not, and then doing it again for the next client you use.
Odel is a dock. You plug the varied things in, and you get one cable out.
One URL, whatever is behind it
Everything on Odel resolves to the same thing: an HTTPS endpoint that speaks MCP, that any client can point at, and that you sign in to with your Odel account.
What changes is what sits behind that URL, and how much of it is yours.
The three things you can plug in
Modules
A module is something Odel serves. Either the code runs on Odel — you deploy TypeScript through the developer portal and Odel hosts it — or the code runs on your own infrastructure and connects back to Odel. Either way, the only sign-in between you and it is your Odel account, and it can be listed in the marketplace for other people to install.
If a module needs a credential of yours, you configure it once and Odel injects it at call time. The module receives the value; it never learns where it came from, and you never paste it into a client config file.
External servers
An external server is one Odel doesn't run. Find it in the marketplace and add it like any other module, and Odel hands you a URL that proxies it behind your account. Any credentials it needs are stored encrypted against your account and injected on the way through. An upstream that signs you in itself asks for your own account instead, and the access stays yours.
The credentials are yours; the URL is not. The first person to add a given server mints the one address Odel relays it on, and everyone who adds it afterwards gets that same address. Add one when you want something that has nothing to do with Odel to behave as though it did — so it shows up in your client next to everything else, and so its traffic runs through one place.
Gateways
A gateway is a proxy an organization shares. Some upstreams take a single credential the organization holds; others have their own per-person sign-in.
This is the case worth going slowly on. Some services won't let an application register itself on the fly. To connect to one you need an OAuth app that a human created in the vendor's console, with a client ID and a client secret. That's fine when you're configuring a single client for yourself. It falls apart the moment you want to hand the thing to your team: you'd have to distribute the client secret to everybody, and most MCP clients have nowhere sensible to put it anyway.
A gateway holds that registration once. You register the OAuth app with Odel, point the gateway at the upstream, publish it to your organization, and share the gateway's URL. Everyone who uses it signs in to the upstream themselves, with their own account and their own permissions. The thing that gets shared is the app registration — never anybody's access.
One person's access is never another's
A gateway's users each hold their own upstream connection. Odel uses yours only for requests you make, and never for another gateway — even one pointing at the same service.
Which one do you want?
Three questions settle it.
Where does the code run? On Odel, on your own infrastructure, or somewhere you don't control at all.
What do you have to supply? Nothing, a credential you configure once, or your own account with the upstream service.
Who else can use it? Just you, your organization, or anyone.
| Code runs | You supply | Who can use it | |
|---|---|---|---|
| Module (hosted) | on Odel | nothing, or a credential | anyone you publish to |
| Module (your backend) | your infrastructure | nothing, or a credential | anyone you publish to |
| External server | someone else's | a credential, or your account | anyone who adds it |
| Gateway | someone else's | a credential, or your account | anyone you share it with |
Every one of these gives back the same kind of URL. The differences are about ownership and sign-in, not about what your client has to do.
Servers Odel doesn't touch
The marketplace also lists MCP servers that have nothing to do with Odel — thousands of them, ingested from the public registries. For those, Odel is a catalogue. You can take the URL and point your client straight at it, with no Odel account involved at all.
A listing carries a badge saying where it came from — who built it, not how it connects:
A listing stays that way until you wire it up. Adding one is what turns it into a module you run through Odel, or into an organization's gateway; that's the only difference between a server you found here and a server you run through here.
Where to go next
Finding and installing
Browse the marketplace and add something to your client.
Connecting your client
Claude Code, Cursor, Claude Desktop, Cline, ChatGPT.
Connecting a gateway
What happens when you authorize one, and how to undo it.
Here to build something?
If you want to publish a module, run a gateway for your team, or deploy code to Odel, the developer documentation covers the SDK, the developer portal, and publishing.