From Prompt to Production: LookML Authoring in MCP-Toolbox

The AI era presents new opportunities for interacting with and leveraging new tools to gain information from your data. With the release of MCP Toolbox v0.18.0, you can now use AI agents to author and manage LookML directly from a prompt, bringing Looker code development to the new tools you use every day, and streamlining your workflow.

The Rise of the AI Data Analyst

AI-powered data agents can understand your data, suggest improvements to your LookML models, and write the code for you. Powered by LLMs like Gemini, these agents can translate natural language prompts into complex actions, including code generation.

The key to unlocking this potential lies in providing these agents with the right context and tools. This is where Looker’s semantic layer, LookML, and the MCP Toolbox come into play. LookML provides the structured, governed, and reusable definitions of your business logic, while the MCP Toolbox acts as the bridge, allowing AI agents to securely interact with and, now, modify your Looker instance’s codebase.

The LookML Authoring Toolkit is Here

With the latest release of the MCP Toolbox, we are shipping a powerful new suite of tools specifically for authoring LookML.

With version v0.18.0, you can empower an AI agent to:

  • Analyze your existing LookML models: The agent can inspect your Explores, identify areas for improvement, and suggest changes based on best practices.

  • Generate new LookML views and models: Provide the agent with a natural language description of the data you want to model, and it will generate the corresponding LookML code for a new view or model file.

  • Refactor and optimize your LookML: The agent can help you streamline your LookML projects by identifying redundant code, improving performance, and ensuring consistency across your models.

Your New LookML Workflow in Action

Here’s how you can leverage the new LookML authoring tools:

  1. Prompt: You, the developer, provide a prompt to your AI agent. This could be something simple like, “Create a new view for our users table based on the schema in our BigQuery database,” or a more complex request like, “Add a year-over-year measure to our orders Explore.”

  2. Agent’s Action: The agent leverages the new LookML authoring tools in the MCP Toolbox. It inspects your database schema, analyzes your existing LookML, and writes the code to fulfill your request.

  3. Code Generation: The agent generates the complete, syntactically correct LookML code. This could be a brand new view file ready for your project or a set of new measures to be added to an existing file.

  4. Review and Deploy: You review the generated code directly in your development environment. Once satisfied, you can commit it to your project repository, putting it through your standard CI/CD and review process.

Introducing the New Tools

  • dev_mode: Turn dev mode on and off for the session. LookML authoring must be done in dev mode. Also queries run in dev mode use the modified LookML so you can test the impact of your changes.

  • get_projects: Get the list of available LookML projects.

  • get_project_files: Get the list of LookML files in a project.

  • get_project_file: Get the content of a LookML file.

  • create_project_file: Create a new LookML file.

  • update_project_file: Modify an existing LookML file.

  • delete_project_file: Delete a LookML file.\

There are no tools for committing the changes or promoting them to production. For security, those actions must still be done by the LookML developer in the Looker UI.

Empower Your AI Agent to Author LookML Today

To get started with AI-powered LookML authoring, download and install the MCP -Toolbox server following the instructions at https://googleapis.github.io/genai-toolbox/how-to/connect-ide/looker_mcp/.

The combination of AI agents, Looker’s semantic layer, and the now-shipping LookML authoring tools in MCP Toolbox v0.18.0 empowers you to do more from the cutting-edge tools you are leveraging today. Start building with the future of data modeling.

8 Likes

MCP Toolbox Listen Parameter Issue

Issue Summary:

The MCP toolbox add_dashboard_element function ignores the listen parameter in JSON payloads, causing dashboard-level global filters to become non-functional decorations.

Technical Details:

Bug Location: add_dashboard_element API call in MCP toolbox
Impact: Dashboard filters appear in UI but don’t actually filter tile data

Can someone help me with this case.

1 Like

The MCP tools (query, make_look, add_dashboard_element) silently ignore the dynamic_fields parameter. When we pass dynamic_fields(Table Calculations, custom dimesion, custom measures) to these tools, no error is returned, but the custom fields are not included in the resulting query, Look, or dashboard element.

What we need:

  1. The query MCP tool to accept and pass through the dynamic_fields parameter when creating queries

  2. The make_look MCP tool to either accept dynamic_fields (forwarded to the query) or accept a query_id from a pre-created query

  3. The add_dashboard_element MCP tool to support query_id from a query that contains dynamic_fields

    @Dr_Strangelove , @robertcarr , @lyg

Yeah, this is definitely a gap right now.

The MCP tools don’t currently support or pass through dynamic_fields, which is why they’re being silently dropped. So even though the request succeeds, anything like table calculations, custom dimensions, or custom measures just doesn’t make it into the final query/Look/dashboard element.

What ur asking for makes sense and honestly feels necessary.

  • query should accept and forward dynamic_fields

  • make_look should either support dynamic_fields directly or take a query_id

  • add_dashboard_element should support query_id so those dynamic fields persist

right now, the only real workaround is to pre-create the query (with dynamic fields) outside MCP and then reference it via query_id—but since that’s not fully supported across all tools yet, it’s pretty limiting anndddd a bit annoying.

this feels less like edge case behavior tbh & more like a missing core capability, especially if the goal is parity with what users can do in the UI

this feels less like edge case behavior tbh & more like a missing core capability, especially if the goal is parity with what users can do in the UI

At this point, the goal is definitely not “parity with what users can do in the UI”. This is intentional. I wanted to build tools that the LLM can figure out how to use easily. That means dropping some functionality to make the tool more simple. I also didn’t give control over layout for the same reason.

I will do some investigation to see if this feature can be added.

This is super helpful, appreciate you explaining the thinking here.

I see the focus on keeping things simple for LLMs, that makes a lot of sense. I ran into this while trying a workflow, so I pushed on it from that angle and didnt mean to dismantle the intent.

Im honored to see your reply @Dr_Strangelove - Please continue to build great things as you do! Personal fan of your contributions at Google :slight_smile: