Letting other agents call Genie: Genie One MCP vs Genie Agent MCP vs the API

A question we expect to hear more of: “We already have an agent, or a Copilot Studio flow, or a coding assistant. How do we let it ask Genie questions without building a second analytics stack?”

It is not hypothetical. A few months ago someone on the Databricks Community forum asked whether a Copilot Studio agent could reach a Genie space. The answer from a Databricks employee was yes, through the Genie Conversation API, called from an HTTP request node or a Power Automate flow, with polling because responses are asynchronous. They also flagged a default timeout of roughly 30 seconds on the HTTP node, which complex questions can exceed, and recommended a service principal with OAuth over a personal access token once you leave proof-of-concept.

That advice still holds. What has changed is that there are now more routes, and they differ in governance more than in convenience. Here is how we would choose.

The three routes, as documented today

Genie One MCP server (system.ai.genie_one_mcp). An MCP endpoint for natural-language business questions across the workspace. Databricks’ docs list it as generally available, governed through Unity Gateway grants and policies plus the underlying permissions.
Genie Agent MCP server. An MCP endpoint scoped to one curated Genie Agent (formerly a Genie Space). The docs list it as Public Preview, and calls to it do not go through Unity Gateway.
The API route. Calling Genie from an application without MCP, as in the Copilot Studio example above. Check the current API reference for endpoint details, since this area moves quickly.

Sources are at the end of this post. Verify status on the docs pages before you commit to a design, because the labels have been changing month to month.

What the Genie One MCP server gives you

According to the docs, you send a natural-language question and the server searches enterprise data, writes SQL and returns an answer with deep links to the cited sources. It uses Genie Ontology, the governed semantic layer, to resolve business terms and metric definitions, which Databricks presents as more reliable than an agent writing SQL against raw tables.

Practical details worth knowing:

Four tools plus one. genie_ask starts a question, genie_poll_response fetches progress and the answer, genie_get_query_result returns the full result, and genie_cancel_response cancels. On clients that support MCP Apps, view_ask replaces genie_ask and returns an interactive view.
It is asynchronous. Your agent polls until the status is completed, incomplete or failed. Follow-ups reuse the conversation ID.
Results are truncated in the ask and poll calls to protect context size, so design agents to fetch full results only when they need them.
Auth. On-behalf-of user OAuth is recommended, with the ai-gateway scope. Service principals are supported for automated workloads.
Prerequisites. Unity Gateway in the workspace, EXECUTE on system.ai.genie_one_mcp for callers, and Genie One configured in the workspace.

The deprecation you should not miss

If anyone on your team wired an agent to the earlier Beta endpoint at /api/2.0/mcp/genie, the docs say it is deprecated and reaches end of life on November 30, 2026. Migration is small: change the server URL, request the ai-gateway scope instead of genie, and make sure callers have EXECUTE. Tool names and arguments are unchanged. Put it on a calendar now rather than finding out from a failing flow.

When the Genie Agent MCP server is still the right call

The per-agent server is useful when you want an agent to talk to exactly one curated domain, say a finance agent with five or so well-modeled tables, and nothing else. The documented limits matter here:

It is Public Preview, and a workspace admin has to enable Managed MCP Servers on the Previews page.
It is read-only.
It does not pass conversation history to Genie, so it is a poor fit for multi-turn chat. The docs point to the AI Bridge Python route for that.
Calls bypass Unity Gateway, so MCP grants, tracing, policies and guardrails there do not apply. Access depends on the permissions on the Genie Agent and its data.

That last point is the one governance teams will care about. Data access is still evaluated with Unity Catalog permissions, but you lose the central place where you would normally see and control which agents call what.

Our opinion: choose by governance first

Most comparisons start with features. We would start with who needs to see and control the traffic.

Cross-workspace business questions from agents or assistants: use the Genie One MCP server. It is the GA option and it sits behind Unity Gateway, so your platform team gets grants and policies in one place.
A tightly scoped domain agent: consider the Genie Agent MCP server, but treat it as Preview. Decide deliberately whether bypassing Unity Gateway is acceptable for that data, and write the decision down.
A custom application with its own UI and orchestration: use the API route and own the polling, timeout and error handling yourself. Do not run long Genie questions through a short-timeout HTTP node.

Whichever route you pick, the same groundwork decides whether answers are any good: documented tables and columns, metric views for the numbers that matter, a small number of tables per agent (the docs recommend five or fewer, with a hard maximum of 50), and a benchmark set you re-run on every change. Exposing Genie to more callers raises the cost of a wrong answer, because the person reading it may be an agent that does not push back.

Questions to settle before you connect anything

Who is the caller: a person, or a service principal acting for a team? Prefer user-level OAuth where a person is behind the request.
What happens when a poll returns incomplete or failed? Agents need a defined fallback, not a retry loop.
Are results being truncated in a way that changes the answer the agent gives?
Which route bypasses central governance, and is that written down and approved?
Who owns the November 30 migration if you have Beta-era integrations?

The short version

Genie One MCP (GA, behind Unity Gateway) for workspace-wide questions; Genie Agent MCP (Public Preview, bypasses Unity Gateway, read-only, no history) for one curated domain.
The API route still works for custom apps, but you own polling, timeouts and errors.
The Beta /api/2.0/mcp/genie endpoint ends on November 30, 2026. Migration is a URL, scope and permission change.
Choose by governance, then features. Keep agents small and benchmarked either way.

If you are planning to connect agents to Genie and want a second pair of hands on readiness, pilots or governance, see our Databricks Genie implementation page.

Sources: Genie One MCP server, Genie Agent MCP server, Databricks managed MCP servers, Genie best practices.