Skip to content

Splitting Looker prebuilt into looker + looker-dev breaks dev_mode isolation (separate API sessions) #2615

@roanny

Description

@roanny

Description

After upgrading from v0.27.0 to v0.28.0, the Looker prebuilt config was split into two separate configs via PR #2559:

  • --prebuilt lookerlooker.yaml (query, content, explore tools) using looker-source
  • --prebuilt looker-devlooker-dev.yaml (dev_mode, project files, validate, directories) using looker-dev-source

When using --prebuilt looker,looker-dev, each YAML creates its own independent Looker API source/session. This means dev_mode activated via looker-dev-source is not visible to tools using looker-source. The tools in looker (query, get_explores, make_look, etc.) operate on the production branch and cannot see views/explores created in development mode.

In v0.27.0, all tools shared a single looker-source, so dev_mode applied globally to all Looker tools.

Steps to Reproduce

  1. Start Toolbox v0.28.0 with: toolbox --stdio --prebuilt looker,looker-dev
  2. Call dev_mode with enable=true → returns {"workspace_id": "dev"}
  3. Call create_project_file to create a new LookML view → succeeds ✅ (uses looker-dev-source)
  4. Call validate_project → succeeds ✅ (uses looker-dev-source, sees dev files)
  5. Call get_explores for the model → returns empty ❌ (uses looker-source, not in dev mode)
  6. Call query against the new view → returns "View Not Found" ❌ (uses looker-source, not in dev mode)

Evidence from ADK Session

Session with 82 events using --prebuilt looker,looker-dev:

# dev_mode response (via looker-dev-source):
{"workspace_id": "dev"}  ← dev mode activated

# create_project_file (via looker-dev-source):
✅ Files created successfully in dev branch

# validate_project (via looker-dev-source):
✅ Validation passes — sees dev files correctly

# query (via looker-source — DIFFERENT session, NOT in dev mode):
{"message": "View Not Found", "documentation_url": "https://docs.cloud.google.com/..."}

# get_explores (via looker-source — DIFFERENT session, NOT in dev mode):
{"content": []}  ← empty, doesn't see dev mode explores

The agent can create files, validate, and manage them (all via looker-dev-source), but cannot query, create Looks, or run dashboards against them (all via looker-source) because the query/content tools are on a separate API session where dev mode was never activated.

Server Logs

INFO "Using prebuilt tool configurations for: looker, looker-dev"
INFO "Initialized 2 sources: looker-source, looker-dev-source"   ← two separate sources
INFO "Initialized 40 tools: ..."
INFO "Initialized 3 toolsets: looker_tools, looker_dev_tools, default"

Root Cause

looker.yaml and looker-dev.yaml each define their own source (looker-source and looker-dev-source). When merged via --prebuilt looker,looker-dev, the Looker API creates two independent authenticated sessions. dev_mode only activates on looker-dev-source's session, leaving looker-source on the production branch.

Suggested Fix

Both YAML files should reference the same source so all tools share a single API session. For example, looker-dev.yaml could reference looker-source (defined in looker.yaml) instead of creating looker-dev-source. This way dev_mode applies to all Looker tools regardless of which toolset they belong to.

Alternatively, the prebuilt merge logic could detect when two configs target the same Looker instance and consolidate them into a single source.

Environment

  • Toolbox version: v0.28.0 (darwin/arm64)
  • Client: Google ADK 1.26.0 via MCPToolset (stdio mode)
  • Looker instance: Looker Cloud (production)
  • Worked correctly in v0.27.0 where all tools shared a single source

Workaround

Currently no workaround — reverting to v0.27.0 is not viable since v0.27.0 doesn't include create_view_from_table, validate_project, or the directory tools.

A possible but untested workaround would be using a custom config file (instead of --prebuilt) that defines a single source used by all tools.

Metadata

Metadata

Labels

priority: p2Moderately-important priority. Fix may not be included in next release.

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions