Looker’s coding extension is GA—but its MCP control plane is still preview

Google has made the Looker extension for VS Code generally available, moving LookML development—and an optional AI-agent workflow—into local desktop IDEs. The September 10 release adds an onboarding walkthrough, support for populating an empty workspace from a bare repository, tighter synchronization between local Git branches and Looker Development Mode, OAuth support for Kiro, and more secure storage of API client secrets. (Looker release notes)

The practical change is bigger than syntax highlighting. Google’s extension documentation says the tool supports VS Code, Cursor, Kiro, Windsurf, Zed, Claude Code and Codex workflows. It can synchronize LookML files with a Looker instance and connect an IDE agent through a local MCP proxy. The extension buffers MCP requests until pending file synchronization finishes, so validation runs against the current server-side code rather than a stale copy. (Extension setup)

The agent can edit; Git still decides what ships

Google’s AI-assisted development guide describes a four-part workflow: a local IDE and agent, the Looker extension, a Looker-managed or self-hosted MCP server, and prebuilt skill files that supply coding standards and project instructions. In that setup, an agent can read local LookML, inspect database schemas through MCP, propose or apply code changes, and run LookML validation before a commit. (AI-assisted development guide)

That does not make the agent a deployment system. Google instructs developers to inspect the diff, run the extension’s LookML validation command, and then use the normal Git commit and deployment process. Saved files synchronize to the developer’s branch in Looker Development Mode; promotion to production remains a separate step. (AI-assisted development guide)

For teams adopting the feature, that separation is the useful operating boundary: natural language can accelerate model creation and refactoring, but review, validation and deployment remain observable checkpoints. A sensible rollout is therefore to start with generated changes on development branches, require validator success, and preserve ordinary code-review rules rather than treating an agent’s successful tool call as approval to deploy.

GA editor, preview server

The extension is GA, but the Looker-managed MCP server it can use is still preview and is limited to Looker-hosted instances. The server inherits the authenticated user’s Looker roles and content access; admins must explicitly enable MCP tools because all are disabled by default. Looker records agent actions in System Activity, and Looker (Google Cloud core) also records them in Cloud Audit Logs. (Looker-managed MCP server)

The preview also has material constraints. Fine-grained OAuth scopes are not supported, connected clients do not receive tool-allowlist changes automatically, capacity is fixed and may produce peak-time timeouts, and Looker (original) IP allowlists are incompatible with the managed server. (Looker-managed MCP server)

So the release is best read as two maturity levels in one workflow: a production-ready local development extension wrapped around an agent gateway that still carries preview limitations. Teams can adopt the IDE now, but should stage the MCP path separately, with narrow tool enablement and an explicit reconnect procedure when administrators change access.