Prerequisites
What are you trying to do that currently feels hard or impossible?
If the Looker MCP Toolbox is configured with OAuth (ie. end user supplied credentials) and deployed privately to a GCP service. There will be token conflicts when invoking the Toolbox from a Client, as both GCP services like Cloud Run (which need an ID token when invoked) AND Looker expect their access token to be supplied in the Bearer format.
To workaround this scenario, which could be faced by developers implementing the toolbox for Embedded Analytics I propose that when OAuth is enabled for the Looker source, an optional custom header parameter is supplied that tells the Looker source to look for a custom header to find the Looker Access Token as opposed to the Authorization header.
For example:
sources:
looker-source:
kind: looker
base_url: https://example.cloud.looker.com
use_client_oauth: true
access_token_header: "X-LOOKER-ACCESS-TOKEN"
verify_ssl: true
timeout: 600s
Suggested Solution(s)
No response
Alternatives Considered
No response
Additional Details
No response
Prerequisites
What are you trying to do that currently feels hard or impossible?
If the Looker MCP Toolbox is configured with OAuth (ie. end user supplied credentials) and deployed privately to a GCP service. There will be token conflicts when invoking the Toolbox from a Client, as both GCP services like Cloud Run (which need an ID token when invoked) AND Looker expect their access token to be supplied in the
Bearerformat.To workaround this scenario, which could be faced by developers implementing the toolbox for Embedded Analytics I propose that when OAuth is enabled for the Looker source, an optional custom header parameter is supplied that tells the Looker source to look for a custom header to find the Looker Access Token as opposed to the Authorization header.
For example:
Suggested Solution(s)
No response
Alternatives Considered
No response
Additional Details
No response