Module types
What the badges on a module card tell you.
Every module in the marketplace carries a badge naming its type. The badge answers one question: who runs this code? That in turn decides how you add it, what it can be told, and who you're trusting.
Official
Built and maintained by Odel. They're part of the platform, updated with it, and the only ones where Odel is responsible for both the code and the hosting.
Add them like any other module. If a task has an official module, it's usually the least surprising option.
User
The badge on the card reads Native.
Written by someone else and deployed to Odel. The code is theirs; the runtime is Odel's, so it runs in the same isolate under the same rules as everything else — a per-call V8 isolate, with your credentials injected at call time.
These are addressed @org/module-name, and the owner is a link you can follow to see what else
they've published.
Your secrets do reach the module
Credentials are encrypted at rest and injected only when a tool runs — but the module's code receives the value in plaintext, because it has to in order to make the API call. Odel can't constrain what a module does with a key after handing it over. Give a module the narrowest key that does the job, and check that what it asks for matches what it claims to do. A calculator asking for mail credentials is telling you something.
External
An MCP server that Odel doesn't run at all — someone else's infrastructure, or your own. Odel knows about it, lists it, and can put a URL in front of it, but the code executes elsewhere.
You add one like any other module: the button says Add to My Modules. The first install of a given server mints the Odel address that relays to the upstream, and everyone who installs it after that gets the same address — your credentials in it stay yours. An organization you manage can instead adopt the server as its own gateway, from a second button on the same page. Because the server is outside the platform, Odel's visibility into what happens after the relay is limited to what the protocol shows.
Servers that sign you in
If an external server authenticates with OAuth rather than an API key, there is nothing to paste: add it, then approve the sign-in the server itself shows you — an Authorize button appears on the module's page once it's installed. Odel registers with the server on your behalf where the server allows that, and holds the resulting access as yours alone. A handful of servers only accept an application registered by hand in their own console — those can't be added in one click, and the install says so and points you at creating a gateway from that upstream in the developer portal instead — see connecting gateways.
Gateway
An organization's shared front door to an external server. The code still runs somewhere else — same as External — but the listing belongs to an organization, which holds the credentials and decides who may use it.
You add one like any other module: the button says Add to My Modules, and the gateway's own visibility decides whether you can — everyone once it's Public, the organization's members once it's Internal, its admins and managers while it's still a Project. Once it's added, the page carries the address to point a client at, and the gateway checks on every call whether you're allowed through. Its tools get no tab of their own: they sit behind that door rather than in a public listing.
Who you're trusting is one layer deeper than usual — the upstream service, and the organization whose credentials reach it. Gateways and installing covers who owns what, and how a gateway moves from Project to Internal to Public.
Default
The badge on the card reads Core.
Platform modules that power Odel's own chat — things like title generation and cross-conversation memory. They're listed in the marketplace so you can see what's there and turn pieces off, but they have no install button and can't be added to an outside client.
You never need to think about these unless you want to disable one.
What the badge doesn't tell you
Whether you can see it. Visibility is a separate setting. A module is either public — listed for everyone — or restricted to the organization that owns it, which is how a team ships something internal. A private module behaves exactly like a public one; its page carries a small Internal badge, and it isn't in anyone else's marketplace. See publishing.
What it costs. Everything on the marketplace is currently free.
Whether it's any good. There are no ratings and no reviews. Judge a module by its owner, its description, the tools it actually exposes on its detail page, and the credentials it asks for.