What is new here, in four lines
- The model explores the catalog before it queries. The tools are exposed in the natural order of an investigation — catalogs, schemas, tables, and only then SQL — so the query gets built on names that actually exist rather than on what the model thinks it remembers.
- It is MCP, not a plugin. The server speaks an open protocol, so it is not married to one chat client: anything that speaks MCP connects to the same place with nothing new to write.
- The surface is deliberately small. The model does not get a warehouse connection: it gets four tools with typed parameters and their reach decided in advance.
- Formatting is part of the tool. Returning raw rows makes the model spend context rearranging them; returning them already tabulated leaves that context free for reasoning about the data.
The problem it solves
Asking a warehouse a question carries a cost that is not in the query but in everything before it: knowing which catalog the data lives in, what the table is called, which columns it has, and remembering the exact dialect. For anyone who does not write SQL daily, that cost is the whole barrier — and it usually turns into a ticket for the data engineering team.
This integration puts the AI model in between: whoever is asking asks in their own language, and the model walks the catalog, finds the table, writes the SQL and returns the result already presented.
How it works
An MCP server publishes a handful of tools against a Databricks workspace. The model calls them in sequence, and each call returns something it uses to decide the next one:
| Tool | What it is for |
|---|---|
| List catalogs | Getting oriented: what exists in the workspace |
| List schemas | Narrowing down the chosen catalog |
| Describe tables | Real column names and types before writing anything |
| Run SQL | The query, with the result returned already formatted |
The sequence matters more than it looks. A model given only “run SQL” invents plausible table names and fails; a model that can look first writes a query that runs on the first try. It is the same idea behind any decent agent: give it a way to explore before it acts.
The decisions that define it
- Tools, not a connection. The model never receives credentials or an open session against the warehouse: it receives functions with typed parameters. Anything not exposed as a tool simply cannot be done.
- An open protocol before a bespoke integration. MCP means that the day the chat client changes, the server stays as it is. A proprietary integration would have to be rewritten from scratch.
- Formatting lives on the server. It is tempting to return JSON and let the model present it, but that spends context and tokens on work a function does better and identically every time.
What it actually buys you
This does not replace an analyst: it removes the part that is not analysis. Exploring the catalog, recalling the exact table name and typing the syntax stop being human work, and the conversation stays on the business question — the one thing a model cannot do for you.