Installing modules
Adding a module to your account, giving it credentials, and taking it back off.
Installing adds a module to your account, not to a particular app. Every MCP client you connect sees the same set, so you do this once and Claude, Cursor, and anything else you point at Odel all pick it up.
You need an Odel account. Getting started covers that part.
Adding a module
Find it
Browse the marketplace and open the module's page.
Check what it wants
The Requirements section of the module page lists the credentials the module requires. This is the moment to decide whether you're comfortable — after installation the module receives those values whenever it runs.
Add to My modules
The button is on the module page. If you're signed out it says Sign in to install instead.
Give it credentials
A dialog opens with a Where it runs panel at the top — it names whether the module runs on Odel, on the creator's own server, or on a vendor's, since that decides who ends up with your values. Below it, if the module needs any credentials, each field takes either a value you type or a vault item you point at — the picker beside the field. Pointing at the vault means one copy of the key, reusable across modules, changeable in one place.
Use it
Connect a client and the module's tools are there. See connecting a client.
What the module can see
Your credentials are encrypted at rest and injected only when a tool runs — but the module's code does receive the plaintext value, because it needs it to call the API. Odel can't control what happens to a key after that. Prefer a scoped key over an account-wide one, and be more careful with modules from owners you don't recognise.
External servers are different
A server Odel doesn't host takes the same Add to My modules button, but what it gives you is shared. The first install of one mints the Odel address that relays to the upstream, and everyone who installs it after that gets the same address; only the credentials in it are yours. A package you run on your own machine has no address to front, so it has no install button at all — its Installation tab covers running it locally instead.
If your role in a team organization lets you create modules there (by default Owner, Admin and Member do; Billing manager doesn't), a second button sits beside Install: Add to that organization, which opens the developer portal to set the server up as its own gateway — a draft you finish and publish there, after which it is one set of credentials the whole organization calls through, at an address the organization chose. It is a separate act from installing, not an alternative to it.
If the upstream signs people in with OAuth rather than an API key, there is nothing to paste. Odel registers itself with the upstream where it allows that, and you sign in with your own account as a second step. An upstream that only accepts an OAuth app registered by hand in its own console refuses instead, and points you at adding it as an organization's gateway in the developer portal.
Changing credentials later
Open the module and go to the Config tab, which appears once you've installed it. You can replace a typed value, switch a field to a vault item, or the other way round.
If a value came from the vault, changing it there is enough on its own — every module pointing at that item picks up the new value on its next call, with nothing to reconfigure.
When a module moves
A module's owner can change its Module ID, or hand the module to another organization, which changes its ID too. Your install moves to the new ID, but what you set up for it is cleared:
- Deleted: values you typed into its fields, its links to vault items, and every MCP client's sign-in for it.
- Kept: the install itself, under the new ID, and the vault items it pointed at.
You get an email with the new address. For 14 days, signing in at the old address shows a notice with the new address instead of connecting. To use the module again, change the address in your MCP client to the new one, sign in, and set its credentials up again on its Config tab.
If the module changed hands, the email names its new owner. The email also says when the module sees you as a new user, which depends on how you let modules identify you on Account → General: anything it stored about you before the move is then no longer linked to you.
Removing a module
Config tab → Danger Zone → Uninstall. Confirm, and the module and the configuration you set for it are removed from your account.
What that does and doesn't delete:
- Deleted: the module's configuration, any values you typed directly into its fields, and its links to vault items.
- Kept: vault items the module pointed at. They're yours, not the module's, and other modules may be using them.
- Untouched: anything the module created in an external service. Uninstalling doesn't reach into a third party to undo work.
You can reinstall at any time, and you'll be asked for its credentials again. A client that was already connected loses access at its next call, and has to sign in again.