Desktop clients: multiple services in one connection
Use standard OAuth sign-in and explicitly select each service, tool, prompt, resource and subscription. Write requests are off by default and still require individual approval when enabled. Current group permissions and each service grant constrain calls; new tools never expand existing grants. Revoke one service or the whole connection in the portal.
mcpbridge login --native --server https://hub.example.com/mcp --profile work
mcpbridge connect --profile work
Use this flow with a local browser. Administrators preregister native MCP client callbacks under Operations → OAuth clients. Clients use PKCE and standard Bearer credentials without a custom grant header. Headless Agents retain device link authorization, with one service per pairing; existing single-service entries remain available.
For remote or headless Agents, use link authorization: sign in and choose access on one page, or use --interactive-auth for authentication tools. The existing setup flow below remains available.
Understand the names
- Profile
- Local sign-in and connection settings, such as work; the default is default.
- Client entry
- A generated ci_… ID containing the authorized tools and resources for one service.
- Service / Endpoint
- A company-published set of business tools. Each entry connects to one service.
- Broker
- A local service that shares sessions and sign-in renewal across processes. connect --client starts it when needed.
Multiple services and clients
mcpbridge setup --profile work > projects-mcp.json
mcpbridge setup --profile work > tasks-mcp.json
Choose the target service and tools each time, use distinct client names, and merge entries into your client configuration. Separate entries for different AI clients also make revocation easier.
Separate companies and identities
Use different profiles for different MCPHub URLs or identities. Setup rejects mixing an existing profile with another URL or client ID. Create a new profile or explicitly sign in again:
mcpbridge setup --server https://other-hub.example.com/mcp --client-id mcpbridge --profile other-work > other-mcp.json
Keep administrator sign-in profiles separate from everyday user profiles.
Change computers or system accounts
- Install the connector in the new environment.
- Run setup again, sign in, and authorize.
- Use the newly generated paths, MCPHUB_HOME, and entry ID.
- After checking the new connection, revoke unused old sessions or entries in the portal.
Personal upstream accounts are stored server-side per user and may not need reconnection. The new environment still needs its own client entry. Do not migrate by copying the credentials directory.
SSH, remote development, and containers
First identify where the client actually launches the connector. The executable, private directory, broker, and callback must be available in that environment. Local absolute paths cannot be used directly on a remote machine.
If no browser is available or the callback cannot be reached, ask your administrator for a supported approach. Open authorization links in an environment that can reach the corresponding local callback.
Manage the local broker
mcpbridge broker status
mcpbridge broker stop
Stopping the broker stops local connections and keeps remote grants. The next connect starts it when needed. Run broker run in the foreground for diagnosis. If MCPHUB_HOME changes, related processes must all use the same directory.