Every analytics team has a 4:47pm Teams chat in their future. Someone in operations needs a number, the dashboard doesn't quite show it that way, and the data is technically right there in the lakehouse. Cue the hand-rolled SQL, the spreadsheet hand-off, and the question that comes back the next morning: "can you also break this down by line?"
What if any employee could just ask the lakehouse a plain-English question — "which assets are offline right now from high-vibration trips, and how does that compare to last week?" — inside Teams, mid stand-up, and get an answer that survives an audit?
That used to mean a Copilot Studio agent that minored in your data dictionary. With Azure Databricks Genie + MCP, it doesn't anymore.
If this sounds familiar, it should — I walked through the same architecture question on the Snowflake side a few posts back in Connecting Copilot Studio to Snowflake: Why Agent Architecture Matters More Than the Connector. The pattern is the same: connector-plus-SQL gets you running quickly, but where the real leverage lives is in how the agent talks to the data platform. This post is the Databricks half of that conversation.
The cast of characters
Azure Databricks Genie — natural-language analytics over governed lakehouse data, grounded in Unity Catalog. Genie spaces are curated semantic surfaces: tables, metric definitions, sample questions, and verified SQL, all in one place.
MCP (Model Context Protocol) — an open standard that lets AI agents discover and call tools and data sources without bespoke connector plumbing for each one.
Copilot Studio — Microsoft's low-code agent builder. The place where business logic, channels (Teams, Web, Microsoft 365 Copilot), and governance come together.
Where we started: bring-your-own-tools
The first version of "talk to your lakehouse" looked like this. Copilot Studio's Databricks connector ships a flat menu of actions — Execute a SQL statement, Trigger a new job run, List jobs, Cancel a run, and so on. The agent builder picks each action they want and wires it into the agent as a tool.
For analytical Q&A, the traditional workhorse is Execute a SQL statement. That means you and the agent have to write the SQL at runtime, so the schema, the joins, and the column meanings end up living in the agent's instructions or attached knowledge — and the agent builder is now responsible for keeping all of that aligned with the lakehouse.
The trade-offs that emerge:
- A schema change in Databricks means an instruction update in the agent — re-test, re-publish.
- If multiple agents query the same tables, you end up with multiple copies of the same schema knowledge, drifting independently.
- Bigger schemas eat into the agent's context window, so you cherry-pick what to expose — and hope the question doesn't land outside that slice.
None of this is broken. It just makes the agent builder responsible for things the data platform already knows.
A common middle step: Databricks as Knowledge
A natural improvement at this point is to add Databricks as a Knowledge source in Copilot Studio. Instead of pasting schema fragments into the agent's instructions (which I did to start), you point the agent at a Knowledge source over your Databricks data. At runtime, the agent's reasoning loop pulls in relevant table and column context as needed — schema-aware grounding without the manual maintenance.
This genuinely helps. Accuracy on first-attempt answers goes up. The agent stops fumbling on column names it never had in its prompt. It's a real improvement.
It also doesn't change one thing: the agent's LLM is still the one writing the SQL. Hallucinated joins, wrong aggregation grain, and inconsistent interpretations of business terms like "downtime" or "available capacity" all live downstream of who wrote the query — not who knew the schema. Knowledge fixes the schema-blindness problem. It doesn't fix the SQL-authorship problem.
The shift: Databricks Genie MCP server
Wire the same agent up to the Databricks Genie MCP server instead, and the picture changes. Copilot Studio auto-discovers the MCP server's tools at design time. For a Genie space, you get two:
- query_space_<spaceId> — the agent sends a natural-language question. Genie picks the right tables, writes the SQL, runs it against Unity Catalog, and returns the answer (plus the SQL it ran, for receipts).
- poll_response_<spaceId> — for longer-running queries, the agent polls until the result is ready.
The agent does not write SQL. It calls query_space with intent. Genie handles tables, joins, and metric definitions — because those live in the Genie space, not in the agent prompt.
What that changes for the agent builder:
- Schema add or change? Curate it once in the Genie space. Every agent using that space picks it up. No agent edit.
- New KPI definition? Define it once in the space, reusable everywhere. No agent edit.
- New question type from the business? Usually just works, because Genie has the grounding. No agent edit.
The agent stops being a schema librarian. The data platform takes that job back.
What it looked like in practice: machine reliability
To put this in concrete terms, we pointed an agent at a Genie space built over manufacturing reliability data — sensor streams, maintenance windows, and downtime events sitting across a handful of Unity Catalog tables. A reliability engineer's typical ask:
"Which lines had the worst MTBF last quarter, and what changed versus the prior quarter?"
Here's the part that matters more than any benchmark: getting from "we have data in Databricks" to "the agent answers reliability questions" with a single configuration step.
Add the Databricks Genie MCP server as a tool source in the agent. Authenticate. Pick the Genie space. Done. The agent inherits the space's tables, metrics, sample questions, and verified SQL. No tool-by-tool wiring, no schema curation in instructions, no Knowledge source to maintain on the side.
Compare that to the connector path, where you're making three or four architectural decisions in sequence:
- Which connector actions do I add as tools?
- Where do I put the schema knowledge — in instructions, in attached knowledge, in a Databricks Knowledge source?
- How do I keep that schema knowledge in sync as Databricks evolves?
- How do I keep behavior consistent across multiple agents that hit the same data?
None of those decisions are wrong. They're just decisions you have to make and then maintain. With Genie via MCP, the data team makes those choices once, in the Genie space, and every agent that connects to it inherits the same governed answers.
What it looks like when an agent has the whole semantic layer
Once the Genie space is doing the heavy lifting on schema and metric definitions, the agent gets to handle complex composite questions without the agent builder pre-defining every column or aggregation. Here's a real response from the reliability agent when asked to rank assets by a composite score across multiple inputs:
Here are the results based on a composite Reliability Score calculated from equipment status, average OEE, average downtime, and days since last maintenance.
🏆 Top 10 Most Reliable Equipment
| Rank | Equipment ID | Equipment Name | Status | Avg OEE | Avg Downtime | Score |
|---|---|---|---|---|---|---|
| 1 | EQ-012 | Boiler M1 | 🟢 Running | 98.08% | 0.0 min | 0.957 |
| 2 | EQ-005 | Extruder E1 | 🟢 Running | 93.60% | 10.0 min | 0.950 |
| 3 | EQ-002 | Centrifuge B2 | 🟢 Running | 95.66% | 3.6 min | 0.943 |
| 4 | EQ-009 | Compressor J1 | 🟢 Running | 98.90% | 0.0 min | 0.942 |
| 5 | EQ-008 | Mixer H1 | 🟢 Running | 96.48% | 4.2 min | 0.928 |
| 6 | EQ-010 | Pump K1 | 🟢 Running | 99.35% | 0.0 min | 0.926 |
| 7 | EQ-001 | Reactor Vessel A1 | 🟢 Running | 89.86% | 22.6 min | 0.912 |
| 8 | EQ-004 | Distillation Column D1 | 🟢 Running | 88.72% | 21.6 min | 0.895 |
| 9 | EQ-006 | Dryer F1 | 🟢 Running | 88.00% | 8.6 min | 0.891 |
| 10 | EQ-003 | Heat Exchanger C1 | 🔧 Maintenance | 92.40% | 0.0 min | 0.544 |
⚠️ Top 10 Least Reliable Equipment
| Rank | Equipment ID | Equipment Name | Status | Avg OEE | Avg Downtime | Score |
|---|---|---|---|---|---|---|
| 1 | EQ-011 | Conveyor L1 | 🔴 Offline | 0.00% | 480.0 min | 0.100 |
| 2 | EQ-007 | Filter Press G1 | 🟡 Warning | 77.10% | 50.0 min | 0.496 |
| 3 | EQ-003 | Heat Exchanger C1 | 🔧 Maintenance | 92.40% | 0.0 min | 0.544 |
| 4 | EQ-006 | Dryer F1 | 🟢 Running | 88.00% | 8.6 min | 0.891 |
| 5 | EQ-004 | Distillation Column D1 | 🟢 Running | 88.72% | 21.6 min | 0.895 |
📊 Key Insights
Reliability Score weighting: 40% equipment status · 30% average OEE · 20% inverse downtime · 10% days since last maintenance.
Would you like a deeper dive into any specific piece of equipment, or explore maintenance work orders for the underperforming assets?
Notice what the agent builder didn't have to do: define what OEE means, write the join from the maintenance log to the equipment master, decide that "downtime" should be averaged not summed, or pick the right tables. All of that is encoded once in the Genie space and reused across every prompt and every agent that connects to it. The agent builder owns the conversation; the data team owns the meaning.
Wiring it up
Three pieces, no bespoke connector code:
- Genie space in Databricks — curate the Unity Catalog tables, sample questions, and verified SQL the space should be able to answer.
- Databricks Genie MCP server — the published MCP endpoint that exposes the space's tools.
- Copilot Studio agent — add the MCP server as a tool source, OAuth pass-through enabled.
One thing worth calling out: identity flows end-to-end. The user's request goes through Copilot Studio → MCP → Databricks, and Genie runs the SQL as the user. Unity Catalog row- and column-level policies are still enforced at the data layer. Yes, that means your row-level security has to actually be configured. There's no hiding behind the agent anymore.
The magic of the Genie MCP connection
When you wire Genie into Copilot Studio via MCP:
- No custom REST plumbing — MCP standardizes the handshake.
- Genie spaces become first-class agent skills that the agent can discover at design time.
- Identity, permissions, and Unity Catalog policies flow through end-to-end.
When to use it (and when not)
This pattern earns its keep when:
- You already have governed Unity Catalog data (or are on a path to it).
- The questions are analytical and aggregated — "how many," "trend," "compare," "rank."
- Multiple stakeholders ask similar shapes of questions, and you want consistent answers.
You probably want a different tool when:
- You need transactional writes — Genie is read-side analytics.
- It's a one-off question for one person, and a notebook is faster.
- The data isn't in Unity Catalog and there's no plan to land it there.
Wrapping up
The connector pattern works. So does the Knowledge pattern. Both deliver value, and there are real situations where they're the right call — especially if your data isn't in Unity Catalog yet, or if you only need to call a specific Databricks job and not query data conversationally.
What Genie via MCP changes is where the work lives. Schemas, joins, metric definitions, and verified SQL all sit in the Genie space, governed at the data layer. Identity flows through end-to-end. The agent gets simpler. The data stays governed. The next agent that needs to ask the same data the same kinds of questions gets to skip the architecture decisions entirely — it just connects and inherits.
That's the part that's worth the migration. Not "a slightly better connector." A different shape of responsibility — where the data team owns the data semantics, the agent builder owns the conversation, and nobody has to re-train as a SQL minor.
And that last bit matters more than it sounds. Not every agent builder is a data architect — and they shouldn't have to be. Most of the people building agents (like myself) in Copilot Studio are skilled at conversation design, business workflows, and channel integration. They don't always know the full lakehouse schema, the join paths, or the semantic layer the data team has carefully assembled. Asking them to learn it just to build an effective data-aware agent is a tax that slows everything down and produces brittle results. Genie via MCP removes that tax. Agent builders can ship effective, data-grounded agents without first earning a minor in your warehouse — because the semantic layer comes pre-loaded in the Genie space, ready for any agent that connects to it.
Further reading
- Microsoft Learn — Extend your agent with Model Context Protocol
- Databricks — AI/BI Genie documentation
- Databricks — Model Context Protocol on Databricks
- Model Context Protocol — official spec and overview
- Databricks — Unity Catalog overview
- Microsoft Learn — Add Databricks as a knowledge source in Copilot Studio