Connector Providers

Connectors reach outside services in two different ways, and the difference decides who configures what.

• A connector is a catalog entry a workspace installs — Notion, Linear, Gmail. Installing is a workspace-admin action, done from Settings → Connectors.
• A managed-connector provider is a third party that brokers auth and hosts the MCP session on your tenant’s behalf. You configure one once, platform-wide, with a credential. That’s an operator action, not a workspace one.

They are different layers. A connector declares which auth kind it uses, and two of those kinds — composio and smithery — delegate to a configured provider:

Layer	What it is	Who sets it up	Where it lives
Provider	A broker holding credentials and hosting sessions	Operator, once per platform	connectors.providers
Connector	A catalog entry a workspace installs	Workspace admin, per workspace	The connectors catalog

Note

“Operator” here means platform-wide, which the product’s own vocabulary predates. The catalog field is operatorSetup and the UI says “Operator setup required” — both for the auth: static flow, which this split calls a workspace-admin action. Read those two as “someone has to configure this first,” not as the platform-wide role.

Note

The auth kind is a deployment choice, not a property of the server. Gmail is typically catalogued as auth: composio because Google requires app verification (gmail.*) most operators don’t hold on day one — but the same server becomes auth: static or auth: dcr once you have your own verified OAuth app — see migrating off the broker. Nothing about Gmail forces the broker; your verification status does.

Why a provider at all

A broker earns its place when the platform can’t hold the vendor relationship itself:

• The vendor’s API requires app verification you don’t hold yet (Google’s restricted gmail.* scopes, Microsoft’s Mail.*).
• You’d otherwise register and maintain an OAuth app per vendor, per environment.
• The vendor has no MCP server of its own and the broker supplies one.

If none of those apply, prefer a runtime-native kind. auth: dcr needs zero operator setup and puts no third party in the trust path.

Hosted MCP gateways

Composio, Smithery, MCP360, and Glama all describe themselves with overlapping words: gateway, aggregator, registry, hub. The words do not tell you which mechanism to reach for.

Vendor	Brokers auth	Hosts the session	Configure it as
Composio	OAuth, API key	Per connection	A provider — Composio guide
Smithery	OAuth, config, completed on Smithery’s own hosted setup page rather than a callback to us	Per connection	A provider — Smithery guide
MCP360	No, one account key	Fixed endpoints	A catalog entry — gateway endpoints
Glama	Upstream only — see below	Per connection profile	A remote connector — see below

The top two are providers, and this page describes their machinery. Configuration — the block, its fields, the broker credential’s environment fallback, and why it names a credential provider rather than an env var — is documented once, under connectors.providers.

MCP360 publishes fixed endpoints and one account-wide API key. It holds no per-connection state for you to configure, so it never reaches this page’s machinery and belongs in the catalog instead — see gateway endpoints.

Glama’s MCP gateway is a source-agnostic reverse proxy: it fronts servers Glama hosts for you, its own pre-indexed connectors, and any remote MCP endpoint you point it at. You create a connection profile in its UI and get a dedicated Streamable HTTP endpoint back:

https://glama.ai/endpoints/<your-connection-profile>/mcp

Glama documents that endpoint as gated by an access token issued per connection profile. The OAuth it manages is a separate thing, sitting between the gateway and the servers upstream of it rather than between the gateway and you.

Caution

How the token reaches the endpoint is unconfirmed, and Glama’s own docs read two ways. The hosting page says requests are gated by per-profile access tokens; its client FAQ says to paste the URL in with “no special client setup”, which would put the token in the profile segment. Whether you configure a bare URL or a URL plus a bearer credential follows from which is true, so check a real profile before writing an entry. Untested against NimbleBrain.

Either way it installs as a remote connector — a URL plus, where one is needed, a transport credential. It reaches none of the machinery on this page: no connectors.providers block, because nothing is brokered on your behalf, and no connectors.gateways entry, because the token is per profile rather than one key for the account.

Note

gateway.glama.ai is a different Glama product — an OpenAI-compatible chat-completions API for LLM calls, unrelated to MCP and to connectors. Their shared “gateway” name makes the two easy to conflate when reading Glama’s docs.

Caution

auth: provider is a different mechanism despite the name. It reads no connectors.providers block. It names a credential provider that supplies the transport credential server-side, and the entry that names it must be operator-authored. Two things use it: the platform’s own connectors, whose credential the runtime mints against the fleet authorizer, and a one-key gateway. The "type": "provider" inside an installed connector’s persisted transport is the layer underneath all of this: the credential-provider seam. A brokered connector names its broker there; an auth: provider entry names whichever provider its catalog entry declared.

A registry is not a gateway

Some vendors here are also directories you publish a server into, which is the opposite relationship from connecting to one and needs no configuration on this side at all.

Two of them do both jobs, which is where the vocabulary gets slippery: Smithery is a registry and a broker, and Glama is a registry and a gateway. This page covers only the halves you configure.

Related

• Connectors — the auth kinds, from a user’s point of view
• Connectors Catalog — authoring catalog entries
• nimblebrain.json — the full connectors reference
• Composio operator guide — a shipped provider, end to end
• src/connectors/providers/managed-provider.ts — the interface a new provider implements, for contributors