Gateways and installing
The two ways Odel fronts an external MCP server — you install it for yourself, or an organization adopts it as a gateway
An external server in the marketplace can be added two ways, and both buttons can be on the page at once. Add to My modules adds it for you, the same gesture as any other module. Add to <organization>, beside it when you are acting as a team organization in which your role lets you create modules, opens the developer portal to set the server up as that organization's gateway — a draft you configure, test and publish from there. Either way Odel puts itself in front of the server: it holds credentials, signs callers in with their Odel account, and gives an address to point an MCP client at. What differs is whose credentials those are, and who the address is for.
Installing it for yourself
Installing keeps your credentials yours: what you typed, or the sign-in you granted, stored against your account and read only when Odel relays a call you make. The address is not yours in the same way. The first person to install a given server mints the one address Odel relays it on, and everybody who installs it afterwards gets that same address back. There is no listing to create — the marketplace entry you installed is the listing — and nothing to manage in the developer portal; your own credentials change on the module's Config tab.
A gateway belongs to an organization
Acting as a team organization in which your role lets you create modules, you get the organization's gateway: one set of credentials shared by the organization, a stable @organization/name address, and a listing on the organization's page and, if you choose, in the marketplace.
A gateway starts as a Project, visible only inside the organization's developer portal and tested from its Inspector tab there: its address answers no one until it is published. Its listing (title, tagline, icon, store page) is edited in the developer portal from the moment it exists, and publishing is one step: Internal makes it usable and visible to the members whose access lets them use it, Public lists it in the marketplace for everyone. Stepping back to Project hides it again without losing anything.
What each one gives you
| Installing it yourself | Gateway | |
|---|---|---|
| Credentials | yours | the organization's, shared by everyone who uses it |
| Address | the server's own /g/@owner/name, shared by everyone who installs it | /g/@organization/name, chosen when it is created |
| Who it is for | you | only the Inspector as a Project, members whose access lets them use it once Internal, everyone once Public |
| Listed | already listed — it is the entry you installed | the organization's page; the marketplace when Public |
| Where to manage | the module's own page, Config tab | developer portal, Projects |
The two are not alternatives you pick between. Installing a server for yourself and adopting it for an organization are separate acts with separate buttons, and doing one leaves the other available.
Servers that sign you in
Some servers authorize each user with OAuth rather than a shared key. A gateway for such a server still belongs to the organization, but every member connects to the service separately, with their own account. That step is described in Connecting gateways.