Your agent needs to reach into Databricks. It has to query governed tables, run a SQL job, check why last night's pipeline failed, and pull a Genie answer for a sales rep. Databricks now ships two ways in. There are managed MCP servers, in Public Preview, that expose Unity Catalog data and functions over Model Context Protocol.
And there is the REST API surface your data team has scripted against for years. They cover overlapping but not identical ground, they put you on different auth paths, and for a background data agent one of those differences decides the architecture. Here is how to pick.
Databricks exposes MCP in three forms. Managed MCP servers are Databricks-hosted and connect agents to Unity Catalog data, AI Search indexes, Genie Spaces, and custom functions. MCP Services proxy third-party apps such as GitHub, Slack, and Google Drive through the Unity AI Gateway. Databricks-hosted MCP servers run your own code on Databricks Apps.
Managed MCP servers are in Public Preview as of mid-2026. Transport is Streamable HTTP, and every call runs under Unity Catalog permissions. Agents connect the same way they connect to any remote MCP server: point at the server URL, authenticate, and call tools.
Auth is OAuth (recommended) for all three MCP types, with personal access tokens supported for managed servers and MCP Services. OAuth supports both public and confidential clients, plus service-principal machine-to-machine. Official docs: managed MCP servers and client setup.
The REST API is the complete control plane for a workspace and account. It spans Databricks SQL (Statement Execution, SQL Warehouses, Queries), Jobs, Clusters, Unity Catalog administration (Catalogs, Schemas, Tables, Functions, Connections), Model Serving, Vector Search and AI Search, Secrets, DBFS and Files, and IAM (Users, Groups, Service Principals, Permissions).
Auth supports personal access tokens (now treated as legacy), OAuth user-to-machine, and OAuth machine-to-machine with a service principal client ID and secret. Machine-to-machine access tokens are valid for one hour and refresh automatically under the Databricks SDKs. Official docs: REST API reference and Statement Execution API.
This section lists what is real on each path, sourced from Databricks documentation, so you can see precisely what is not possible on one side versus the other.
Each managed server is scoped by an OAuth scope. The list below is from the official managed MCP documentation.
The REST API is organized into the groups below. This is not the full endpoint list; it is the shape of the surface.
The gap is real and specific. Name it precisely before choosing. Managed MCP cannot start or stop a cluster, trigger a job, manage a SQL warehouse, administer Unity Catalog objects, manage Secrets, or manage IAM. Those are REST-only operations. Managed MCP also does not do high-volume programmatic extraction; the Databricks SQL server targets AI-assisted authoring in coding tools, while bulk result retrieval belongs to the Statement Execution API with chunked results. The REST API, in turn, does not expose Genie answers or AI Search retrieval as native tools without extra wiring; those exist as first-class managed MCP servers.
The managed MCP servers are built for governed data access. The REST API owns operations and administration. The table uses plain text, not symbols.
Both paths support the same core methods, so the auth decision is narrower than it looks. Managed MCP and the REST API both accept OAuth user-to-machine, OAuth machine-to-machine via a service principal, and personal access tokens. A background agent authenticates as a service principal on either path and operates without a browser in the loop.
The one place MCP diverges is client registration. Databricks does not support Dynamic Client Registration for managed MCP servers, MCP Services, or Databricks-hosted MCP servers. An account admin must create the OAuth application in the account console and hand you a client ID, plus a client secret for confidential clients. MCP clients and IDEs that require Dynamic Client Registration cannot use OAuth against Databricks.
Personal access tokens work for managed MCP servers and MCP Services, but not for MCP servers you host on Databricks Apps. Those require OAuth. Plan the credential type per MCP layer, not once for all of them.
The structural point holds on both paths. In a multi-tenant B2B agent, every tenant workspace needs its own Databricks credential. OAuth gives you a token per identity; a service principal gives you a credential per workspace. Neither the MCP path nor the REST path stores, rotates, or revokes that credential for you. That is infrastructure you build or adopt, regardless of which path you pick. For a deeper look at this challenge, see access control for multi-tenant AI agents.
Databricks manages hosting, tool schemas, and Unity Catalog enforcement. You own OAuth app registration per client, credential storage and refresh, the one-hour lifetime of machine-to-machine tokens, and IP allowlisting for cloud-hosted agents that reach your workspace. You also own the poll loop: Genie and long-running SQL return asynchronously and require polling.
You own everything above, plus adapter code for each API group you touch, pagination and chunked result handling for large SQL results, and version handling across the surface. You choose the endpoints, and you own their error and retry models.
Databricks added Unity AI Gateway agent tracing and the Lakewatch SIEM at Summit 2026, so managed MCP activity is captured in a governed telemetry layer. This is real and worth using. It covers Databricks-side activity; it does not cover the credential and identity layer across the other tools in a multi-tool agent.
Whichever path you choose, the agent ends up holding a Databricks credential per tenant: an OAuth token or a service principal secret. Databricks governs what that identity can do through Unity Catalog. Databricks does not give you a vault, rotation logic, or a revocation flow.
In a multi-tenant B2B data agent, each customer workspace is its own service principal with its own grants. That is N credentials to store encrypted, refresh before the one-hour machine-to-machine token expires, and revoke when a customer offboards. The problem is identical whether you chose MCP or the REST API; the token type differs, the infrastructure required does not. This is the same credential ownership challenge that surfaces across every tool-calling pattern.
Scalekit's Databricks Workspace connector authenticates as a Service Principal over OAuth 2.0, holds that credential in an encrypted vault namespaced per tenant, resolves it server-side on every tool call, and never places it in the LLM context. The same auth layer works whether you reach Databricks through Scalekit's tool API or through a Scalekit-generated MCP URL. Connector page: Databricks Workspace; docs: connector reference.
The connector wraps the REST operations most data agents need: SQL execution and paging, Jobs, Clusters, SQL Warehouses, Unity Catalog listing, INFORMATION_SCHEMA discovery, SCIM, and Secret scopes. Representative tools include databricksworkspace_sql_statement_execute, databricksworkspace_jobs_list, databricksworkspace_job_run_now, databricksworkspace_clusters_list, and databricksworkspace_unity_catalog_tables_list.
The connection name must match the connection you created in the Scalekit dashboard exactly; it is the single most common integration error.
Scalekit returns tool schemas in Anthropic's native input_schema format, so no conversion is needed. list_scoped_tools returns only the tools this identity is authorized to call.
actions.langchain.get_tools returns native StructuredTool objects, already scoped to the identity you pass.
The list_scoped_tools call returns only the tools this tenant's identity is authorized to reach, not a full catalog. Surface reduction is the lever for tool-calling accuracy: a smaller decision space produces more reliable selection and fewer hallucinated parameters, and it cuts the token overhead of carrying every tool in context. Model upgrades help; they are not the lever.
Scope is a function of identity, not connector configuration. Each tenant's Databricks credential lives in its own vault namespace, so an agent acting for tenant Acme cannot reach tenant Globex data on the same connection. Unity Catalog grants on the service principal define the ceiling: what the service principal cannot do, the agent cannot do.
Every Databricks tool call is written to Scalekit's auth logs with the identity that authorized it, the tool invoked, and the result, with a queryable history and SIEM-ready export. In a multi-tool agent that also touches Salesforce, Slack, or GitHub, this is one identity-level audit trail across every connector, complementing the Databricks-side telemetry in Unity AI Gateway.
The connector covers the REST operations above; it does not yet expose the Genie, AI Search, or Unity Catalog function managed-MCP servers as native tools. If your agent needs those, or a Databricks capability not listed here, request it: join the Scalekit community, talk to the team, or book time with an engineer.
If your agent is interactive and data-facing, analysts asking Genie questions or retrieving from AI Search inside their assistant, build on Databricks managed MCP. Unity Catalog does the scoping for you, and there is no adapter code to write.
If your agent operates the platform, runs on a schedule, or needs Jobs, Clusters, Warehouses, Model Serving, Secrets, or IAM, build on the REST API with a service principal. That is where headless execution and the full control plane live.
Most production Databricks agents will use both. The credential problem does not change with the path: a per-tenant service principal that has to be vaulted, refreshed before its one-hour token expires, and revoked on offboarding. That is the layer that needs production-grade token vault infrastructure, whichever path you are on.
Browse the Scalekit Databricks Workspace connector: scalekit.com/connectors/databricks-workspace
