Prerequisites
Toolbox version
latest
Environment
- OS type and version: [(output of
uname -a)](root:xnu-11417.140.69.710.16~1/RELEASE_ARM64_T6000 arm64)
- How are you running Toolbox:
- Compiled from source: go run . --prebuilt looker
Client
Tested this using curl and gemini-cli
Expected Behavior
Looker tools should expose the host_url settings exposed by admin settings for all the returned urls from the MCP tools.
Current Behavior
In deployments where the MCP server connects to the Looker instance using an internal/private service address (e.g., across a private network or local DNS), several Looker tools that return absolute URLs (or pass instance domains to external APIs) reference the raw connection BaseUrl or call sdk.GetSetting("host_url"). This leads to two critical problems:
-
Internal Domain Leakage: Tools like looker-generate-embed-url and looker-conversational-analytics reference the connection's BaseUrl directly, resulting in signed embed URLs containing the private internal hostname which is unresolvable by the external client's browser, or causing external APIs to fail metadata domain validation.
-
Permission Denied for Standard Users: Tools like looker-make-look and looker-make-dashboard try to call sdk.GetSetting("host_url", ...). However, standard Looker users do not have administrative privileges to query system settings. This call fails (yielding 403 Forbidden / 404 Not Found API errors) and falls back to returning relative URL paths (e.g. /dashboards/123 or /looks/123) lacking a public hostname prefix.
Steps to reproduce?
Prerequisites & Setup
- Looker Custom Domain Setup: Ensure your Looker instance has a custom domain configured in the Admin console (e.g., host_url is set to https://public.looker.example.com).
- MCP Connection Setup: Configure the MCP toolbox base_url to point to the instance using a local/internal address (e.g., base_url: http://localhost:19999 or your local tunnel address).
Example 1: looker-generate-embed-url tool
- Trigger looker-generate-embed-url: Invoke the tool with valid parameters
- Check the returned embed URL. It will contain the internal connection address: http://localhost:19999/embed/... instead of the public custom domain: https://public.looker.example.com/embed/...
Additional Details
No response
Prerequisites
Toolbox version
latest
Environment
uname -a)](root:xnu-11417.140.69.710.16~1/RELEASE_ARM64_T6000 arm64)Client
Tested this using curl and gemini-cli
Expected Behavior
Looker tools should expose the host_url settings exposed by admin settings for all the returned urls from the MCP tools.
Current Behavior
In deployments where the MCP server connects to the Looker instance using an internal/private service address (e.g., across a private network or local DNS), several Looker tools that return absolute URLs (or pass instance domains to external APIs) reference the raw connection BaseUrl or call
sdk.GetSetting("host_url"). This leads to two critical problems:Internal Domain Leakage: Tools like
looker-generate-embed-urlandlooker-conversational-analyticsreference the connection'sBaseUrldirectly, resulting in signed embed URLs containing the private internal hostname which is unresolvable by the external client's browser, or causing external APIs to fail metadata domain validation.Permission Denied for Standard Users: Tools like
looker-make-lookandlooker-make-dashboardtry to callsdk.GetSetting("host_url", ...). However, standard Looker users do not have administrative privileges to query system settings. This call fails (yielding 403 Forbidden / 404 Not Found API errors) and falls back to returning relative URL paths (e.g. /dashboards/123 or /looks/123) lacking a public hostname prefix.Steps to reproduce?
Prerequisites & Setup
Example 1: looker-generate-embed-url tool
Additional Details
No response