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 Overview tab 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
If the module needs any, a dialog asks for them. 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 you manage a team organization, a second button sits beside Install: Add to that organization, which adopts the server as its own gateway — one set of credentials the whole organization calls through, at an address the organization chooses. 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.
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, and any values you typed directly into its fields.
- 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.