Wiring Databricks Genie into MCP: Turning Natural-Language Data Queries into a Standard Tool

The problem MCP is solving here

If you've built agent tooling around Databricks before, you know the drill: every data source gets its own bespoke client, its own auth flow, its own way of shaping requests and parsing responses. Genie — Databricks' natural-language-to-SQL assistant — was no exception. You'd hit the REST API directly, manage conversation state yourself, and hope the next SDK version didn't break your integration.

Model Context Protocol changes that shape. It's an open standard that lets an agent discover and call tools through a uniform interface, rather than the host application needing bespoke code for each backend. As one breakdown of the Databricks side puts it, the agent "only needs to know what tool to call, not how it is implemented" — MCP handles the protocol, capability discovery, and isolation between servers.

What Databricks actually shipped

There are two distinct things worth separating here, because the naming is confusing if you haven't looked closely.

First, there's the Genie One MCP server — a Databricks-managed endpoint that exposes Genie as a conversational tool over MCP. It's served at /api/2.0/mcp/genie, and it answers questions across your whole workspace using Chat in Genie One, grounding responses in what Databricks calls Genie Ontology, with links back to source data. It's distinct from the per-agent server at /api/2.0/mcp/genie/{genie_space_id}, which targets a single Genie Agent instead of the workspace-wide chat experience.

Second, there's Genie Code (the renamed Databricks Assistant) gaining native MCP client support inside notebooks, the SQL editor, jobs, and dashboards. In Agent mode, Genie Code can now reach out to Unity Catalog functions, vector search indexes, Genie spaces, Unity Catalog connections, or custom Databricks Apps — all wired in through the same MCP settings panel, and it draws on them automatically without you needing to reference them explicitly in a prompt.

Both matter, but they solve different problems: Genie One MCP lets external agents query Databricks data; Genie Code's MCP integration lets Databricks' own assistant reach outward to Confluence docs, GitHub, or internal APIs.

The practical mechanics

A few details matter if you're actually wiring this up:

• Read-only by design. The Genie Agent MCP server invokes Genie as a tool but doesn't pass conversation history to the Genie API — if you need multi-turn context preserved, you're expected to put Genie inside a proper multi-agent system rather than relying on the raw MCP call.
• Result truncation. Both genie_ask and genie_poll_response return truncated results to protect the model's context window. If you need the full table, there's a separate genie_get_query_result call — worth knowing before you assume a summary is the whole answer.
• Permissions are enforced, not advisory. Unity Catalog permissions apply at the MCP layer too, so an agent can't see data the underlying user or service principal isn't already authorized for.
• Tool budgets exist. In Genie Code's Agent mode, MCP access is currently capped at 20 tools across all connected servers, so you'll want to be deliberate about which servers you enable rather than connecting everything.
• On self-hosted setups, several community MCP servers (the Databricks Labs one included) expose Genie spaces alongside vector search indexes and Unity Catalog functions as MCP tools, deployable via the databricks bundle CLI with genie_space_ids passed as a bundle variable.

Where this actually helps

The honest use case isn't "chat with your data" as a novelty — it's removing the custom glue code between an agent framework (LangGraph, the OpenAI Agents SDK, whatever) and a Genie space. The structured-retrieval-tools pattern from Databricks shows this cleanly: point a DatabricksMCPServer at the Genie space URL, pull tools via DatabricksMultiServerMCPClient, and hand them to a standard create_react_agent. No bespoke polling loop, no manual conversation-state tracking.

If you're building agents that need to answer "what were the top customers last quarter" against governed Unity Catalog tables, this is now the path of least resistance rather than a REST client you maintain yourself.