Solving dashboard errors in minutes: How Integral Ad Science used MCP to connect agents to dbt and Databricks

Stop us if you've heard this one. A user goes into a report on a BI dashboard and starts asking questions of the embedded chatbot. They're drilling, filtering, checking the numbers…

And all of a sudden, things don't add up.

This isn't an uncommon problem for analysts in the AI data age. Mars Dauer, Senior Director of Enterprise Data and AI at Integral Ad Science (IAS), and his team ran into the same issue. They knew they had the information that their AI agent needed; it was already there in dbt and Databricks. The challenge was how to supply it to the agent so that it could solve what Dauer and his team call the "BI why" problem.

At Databricks Data + AI Summit 2026, Dauer shared how teams can supply this missing context via model context protocol (MCP) servers that connect AI chatbot agents to dbt and Databricks. In this article, we'll dig into the architecture he used to solve the problem, the decisions made, and the honest lessons about what worked and what the team learned.

The BI "why" problem: What copilots can't answer

BI chatbots have what Dauer calls a "BI why" problem. They can tell you what the numbers say. However, they can't explain the context and reasoning behind them.

Let's assume, for example, that the company is a supermarket chain. An analyst is digging into a revenue report and breaks it down by category — and Food jumps out as unreasonably high.

But why? Can the AI agent tell them where the disconnect is?

This is where the analyst realizes (to no one's surprise) that the agent can't. It can summarize the chart; it can tell them what filters are applied. But it has no real understanding of the business logic or the transformations that produced those numbers.

So, the analyst digs deeper. They open Looker and check the LookML. That points to a dbt model, so they jump into the model and read the SQL. That model leads to three upstream marts, so they open more SQL in more tabs. They eventually run a few validation queries in Databricks and discover that the models have miscategorized a popular drink as food.

Looking at the architecture of a typical AI chatbot system in BI tooling, it's easy to see why the bot couldn't unearth this issue. The BI copilot can see only the topmost layer of the data stack:

• The BI tooling itself
• The semantic layer that defines a unified layer for key metrics and governance
• The mart models containing the gold standard data

[Slide 5]

However, it can't see everything under that—in this case, an errant CASE statement. The agent can't see the business logic built into the dbt intermediate models, or the sources in Databricks it could use to validate and correct this error.

MCP: Your USB-C for LLM tools

Dauer knew that data was available, which meant the answer was somewhere. The issue was supplying it to the BI copilot so that it could solve the issue in minutes, not hours.

The answer his team hit on: MCP.

MCP defines a standardized framework that enables AI applications, such as agents, to talk to tools and understand their capabilities without needing to know their internal APIs. Dauer refers to MCP as the USB-C for large language models (LLMs): the agent has one kind of port, and any tool that exposes an MCP server with the right shape can plug into it.

Before MCP, every integration meant a new bespoke client. With MCP, tools advertise their capabilities, and any MCP-compatible agent can discover and utilize them.

For the project, Dauer's team needed three MCP servers to solve the issues they'd detected:

• The dbt MCP server (the structured context layer), which connected the agent to tested, version-controlled, and documented model definitions — including model metadata, data lineage, SQL, and field/table descriptions;
• A Databricks SQL MCP server (governed data validation layer), which enabled read-only query execution and Unity Catalog governance; and
• A Looker MCP server (the BI on-ramp), providing access to SQL parsing for explore URLs and dashboard tiles.

The team had been using all these MCPs for a while in coding agents like Cursor, Claude Code, and Visual Studio Code. Using them in conversational/analytics agents felt like the logical next step.

How the analytics agent works

The agent has five core capabilities. Dauer thinks about them in three buckets:

Lineage and logic. Given a column or metric, it traces that object from the mart back to the source. It reads the compiled SQL at each hop, and explains in plain language, what each transformation is doing.

Validation. Once it has the lineage, the agent can validate against the actual data in Databricks using read-only SQL. It can also perform freshness checks and monitor pipeline health.

Impact analysis. If you change a column upstream, the agent tells you what breaks downstream, and because it reads the logic in each downstream model, it can reason about whether your change matters semantically, not just structurally.

The agent has two personas depending on who's using it.

In analyst mode, it returns the answers that data producers and analysts need: full technical details, including model names, compiled SQL, column catalogs, directed acyclic graph (DAG)-aware lineage, and raw validation query results.

In business mode, it gives only the information that matters to decision-makers: plain English answers (without jargon or model names), business context, and summarized findings.

As Dauer emphasizes: "One agent, two voices: analyst mode shows model names and compiled SQL; business mode strips both for plain English. Same investigation, different answer for a CMO vs a data engineer."

For Integral Ad Science, Looker was the primary point of entry. The agent was in the BI layer so that users didn't have to context-switch. The agent runs as a window to the right in the main Explore to provide the best user experience.

The backend is a FastAPI server running on Cloud Run. It handles auth through Google OAuth and an authorized group, manages sessions, and streams responses back over Server-Sent Events.

Then there's the agentic runtime, which uses Google's Agent Development Kit. It's composed of a single root agent and four sub-agents. The root agent takes the user's question, decides which specialists to call, fans out the work, collects the results, and formats the final answer.

The LLM layer here is deliberately provider-agnostic via the LiteLLM library. This means each subagent can target Databricks Foundation Model APIs, Gemini Enterprise Agent Platform, Anthropic, OpenAI - whatever best fits the job. This means subagents can use smaller, less expensive models for simpler jobs, such as routing or analyzing metadata.

Finally, the MCP layer connects to dbt platform, Databricks SQL, Looker, and a few internal tools. All of the company's source systems are dbt projects built upon Unity Catalog in Databricks.

Why MCP, and other design decisions

A key question is: why MCP? Why build this using a universal adapter as opposed to creating custom integrations? A few reasons:

Speed. Adding a new tool source meant pointing at a new MCP server, not writing a custom API client. This enabled dbt and Databricks to come online in days, not weeks. That speed compounds when you're still experimenting.

Decoupling. Using MCP means the agent doesn't need to know how dbt, Databricks, or Looker work. Dauer's team could swap out any of these tools, and the agent's code wouldn't have to change.

Governance. This is the one that matters most to security. The MCP server controls what's exposed. Integral can scope tool access, audit at the server boundary, and avoid handing raw API credentials directly to the agent.

Databricks provides governed query execution; Looker provides the BI on-ramp. dbt provides the semantic and lineage layer that makes the whole investigation possible. It's the reason the agent can trace a metric from a dashboard tile all the way back to a source table — and trust what it finds there.

Why rely on dbt MCP for lineage? Because dbt treats lineage as a first-class concept. The agent doesn't reconstruct the graph from scratch or hope documentation keeps pace with reality — it reads dbt's tested, version-controlled graph of how data actually flows.

Alongside the graph, the agent reads the compiled SQL itself — and that's the ground truth. LookML is a model of a model. Documentation is what people intended (or hoped) the model did. Compiled SQL is what actually runs in the warehouse. The lineage tells the agent where to look; the SQL tells it what's happening there.

Trade-offs and lessons learned

Every architectural choice was a trade-off. Some of the key trade-offs that Dauer's team made:

Multi-agent vs. single-agent

The team started with a single agent. As tool complexity grew and prompts got longer, they decided to go multi-agent — specialists under a main routing agent. They landed at four. Every additional sub-agent adds a routing failure mode. The orchestrator has to choose the right specialist, and when it chooses wrong, they wouldn't always get a clear error.

That led Dauer to make a rule: decompose only when the specialist has a genuinely different job and needs a meaningfully different system prompt. If two agents both query Databricks, and one is called "validation" while the other is called "exploration," they probably should be one agent.

Embedded vs. standalone chat

A standalone chat is tempting because you can ship it quickly. But it forces the user to copy context, meaning that every investigation starts with thirty seconds of context-pasting. The embedded Looker extension avoids that: it captures the dashboard/explore context automatically, so the question and the data live on the same surface.

The trade-off here is real. Supporting another BI tool means redoing some of this work each time. But the savings per investigation compound. Bottom line: if your BI tool has an extension SDK, use it.

Per-sub-agent model tiering vs. one model for everything

The easy default is to pick one frontier model, use it for every sub-agent, and move on. IAS doesn't, Dauer said. This means simple agent tasks, such as the Looker resolver, aren't forced to use the most expensive model. They can save the more expensive model for operations such as the dbt analyst, where lineage reasoning over compiled SQL greatly benefits from the extra firepower.

The rule: match the model to the work. The user doesn't feel a quality hit because the critical reasoning step still gets the strongest model.

Only scratching the surface

What used to take an analyst an afternoon, Dauer said, now takes minutes. And yet he feels like his team is only scratching the surface.

The dbt platform MCP server exposes ~37 tools. IAS's solution only uses seven of them. That's actually a testament to how teams can get started narrow and expand without rebuilding anything — the breadth of the MCP surface area means the integration grows with your use case. Some of the tools the team is looking forward to including are:

• Text-to-SQL with project context to generate SQL that knows the project's model names, joins, and conventions.
• Code generation to create staging model YAML and sources. Leveraging this, agents could not only investigate issues but scaffold a fix and submit it for human review.
• Column-level lineage via the Fusion engine — the agent already traces column-level lineage today by reading compiled SQL and inferring how columns flow. The Fusion-powered tool would give the agent that same lineage as a deterministic graph straight from dbt's compiler — replacing LLM inference with explicit column-to-column edges. Faster, cheaper, more precise.

"The most interesting agents in this space probably haven't been built yet," Dauer said. "And, honestly, that's the part I'm most excited about."