Databricks Opens Genie One MCP as Beta Endpoint Nears Sunset

Databricks’ September 22 announcement made Genie One MCP generally available to Databricks users, giving MCP-capable agents a way to ask questions against governed business data. For teams connected through the beta service, the release also creates a migration: the old address is scheduled to close, and the replacement uses a different OAuth scope and governance path.

The Genie One MCP documentation identifies the bare beta endpoint, /api/2.0/mcp/genie, as deprecated and sets its sunset for October 31, 2026. Its replacement is the generally available service system.ai.genie_one_mcp at /ai-gateway/mcp-services/system.ai.genie_one_mcp. On-behalf-of-user OAuth clients need the ai-gateway scope for the new service; the deprecated endpoint uses genie.

What moves behind Unity Gateway

The new route makes Genie One a named MCP Service in Unity Gateway. An agent can submit a natural-language question, while Genie searches governed enterprise data, writes SQL and returns an answer grounded in Genie Ontology, with links to the Databricks sources behind it. That is a different job from passing an agent’s own finished SQL query to a database tool: Genie interprets business terms and relationships before producing the answer.

The service route also changes where access is decided. Unity Catalog grants control who may invoke the MCP Service, and permissions on the underlying data still restrict what a caller can query. Service policies are described as a way to allow or deny individual tool calls. Every invocation through the new service is recorded for usage and audit, so changing the endpoint affects both the permission check and the record of the call.

An OAuth token carrying ai-gateway therefore does not, by itself, grant access to every result. The caller still needs the applicable Databricks permissions. Account users hold EXECUTE on system.ai by default, which usually removes the need for another grant, while other principals need their effective privileges checked. On-behalf-of-user authentication preserves a user-facing identity and supports clickthrough to sources; service principals are supported for automated workloads.

The beta-to-GA migration, field by field

This comparison applies to clients configured for the bare Genie One beta endpoint. The workspace hostname remains specific to the deployment; the path and authorization requirements are the parts that change.

URL — before and after: Replace https://<workspace-hostname>/api/2.0/mcp/genie with https://<workspace-hostname>/ai-gateway/mcp-services/system.ai.genie_one_mcp. The latter names the MCP Service in Unity Gateway.
OAuth scope — before and after: The bare endpoint uses genie. On-behalf-of-user access to the GA service requires ai-gateway, so an authorization configured only for the old scope is insufficient for the replacement route.
Permissions and policies — before and after: The GA route is governed as a Unity Catalog MCP Service, with invocation grants, underlying data permissions and service-policy controls. The beta deprecation notice does not establish that the old bare route had an equivalent Unity Gateway policy model.
Tool discovery — before and after: A client should discover tools from its new connection rather than reuse a cached inventory from the beta server. The GA server lists genie_ask, genie_poll_response, genie_get_query_result and genie_cancel_response. Clients supporting MCP Apps may receive view_ask instead of genie_ask.
Audit behavior — before and after: Usage and audit recording is documented for invocations through the GA service. That does not establish that the beta endpoint produced no logs; it establishes the recorded behavior of the new route.
Result handling — after: genie_ask starts an asynchronous response and genie_poll_response follows its progress. Both return truncated query results to protect the model’s context window. genie_get_query_result can retrieve the full schema and rows, although very large results remain subject to a size limit.

A successful connection alone cannot show that this migration is complete. An end-to-end question can establish whether the new identity may invoke the service, whether the client discovers the expected tools and whether polling reaches an answer with source links. An integration that consumes query rows also has to distinguish the truncated results in the initial response from the fuller result available through the separate tool.

Why a similar Genie URL is a different case

An independent migration analysis distinguishes the deprecated bare path from /api/2.0/mcp/genie/{genie_space_id}, the route for a Genie Agent MCP server scoped to a particular Genie Agent. Both begin with /api/2.0/mcp/genie, so a search through client configurations can flag both. The extra path segment matters: the published sunset notice names the bare endpoint, while the per-agent server remains separately listed with the genie OAuth scope.

That distinction does not amount to a promise that the per-agent route will never change. The notice does not name it, and no separate exemption or retirement date for that route is established by the available pages. A configuration containing the shared prefix should therefore be classified by its complete path before it is treated as a Genie One beta client.

What the sunset notice leaves unanswered

The published migration target is specific: use the named Unity Gateway service and its ai-gateway OAuth scope for workloads on the bare beta address. The documentation does not describe a redirect or compatibility shim for requests that continue to reach that address after its scheduled sunset. It also does not specify the error those requests would return.

The service is generally available now, while retirement of the bare endpoint remains scheduled rather than completed. The open questions concern post-sunset behavior at that old address and the longer-term status of the separately named per-agent route; neither changes the documented migration path for existing bare-endpoint clients.