Skip to main content
When an operation needs a user’s OAuth connection, Fused can return an authentication link to your MCP client. The client presents the link, the user grants consent in their browser, and Engine stores the provider tokens in the bucket. This page is for client implementers. If you use an existing MCP client, it must already implement URL elicitation; adding a setting to the agent prompt does not enable it. Your MCP execution token still authenticates the client to Fused throughout this flow.

​
Before you start

  • Use Streamable HTTP. Fused’s legacy SSE transport does not support this handoff.
  • Use a Managed service where available, or register your own OAuth application in the MCP’s selected bucket. Configure the exact auth scheme, scopes, and application reference before publishing.
  • Supply a stable user identity. For a first-time connection, use a dynamic token with X-Fused-End-User-Ref. A fixed token requires an existing connection at issuance; see token bindings.
Engine creates the consent session using the MCP’s configured service, bucket, and credential routing. The client does not choose a new bucket or manufacture an authorization URL.

​
Implement the client flow

Request authentication

Advertise URL elicitation and display the authorization link returned by Engine.

Handle completion

Receive the notification, resume the agent, and decide whether the request can be retried.

​
Clients without URL elicitation

Fused returns an error explaining that URL elicitation support is required and does not create a browser consent session for that client. Connect the user first through the CLI or application connect flow, then call the MCP with the matching user binding. The same fallback applies to legacy SSE clients.