Databricks MCP Server: What to Know First

⏱️ 3 min read 🔌 MCP Server

What it is, honestly: Databricks MCP support is a genuinely moving target — Databricks Labs (the vendor's incubator GitHub org for experimental tooling, separate from GA products) and independent community authors have both published integrations at various points, generally exposing SQL execution against a SQL warehouse and Unity Catalog metadata browsing. Rather than name one repo with confidence it may not deserve by the time you read this, this page covers the shape these servers share and what to verify before installing one — check the Databricks Labs GitHub org and the MCP registry directly for what's current.

Quick answer: Whatever specific server you land on, expect it to authenticate against a Databricks workspace using either a personal access token or OAuth machine-to-machine credentials, and to run queries against a named SQL warehouse. Scope the token to a service principal with the narrowest Unity Catalog grants the task needs — never your own admin-level PAT.

Why it matters for data work

Databricks sits at the center of a lot of lakehouse workflows — the tables Unity Catalog governs, the notebooks that built them, the SQL warehouses analysts query directly. An agent with scoped access can answer schema and data questions against that catalog the same way it would against any other warehouse, and because Unity Catalog already models fine-grained permissions, a well-built MCP server can inherit that governance rather than reinventing it.

Install & configure

Regardless of which specific implementation you use, expect this general shape — a workspace URL, a SQL warehouse HTTP path, and a credential:

// Claude Desktop / Cursor config — pattern; confirm exact env vars per implementation
{
  "mcpServers": {
    "databricks": {
      "command": "uvx",
      "args": ["<package-name>"],
      "env": {
        "DATABRICKS_HOST": "https://your-workspace.cloud.databricks.com",
        "DATABRICKS_HTTP_PATH": "/sql/1.0/warehouses/<warehouse-id>",
        "DATABRICKS_TOKEN": "<personal-access-token-or-oauth-token>"
      }
    }
  }
}

Generate the token from your Databricks workspace (Settings → Developer → Access tokens) or set up OAuth machine-to-machine auth via a service principal if your workspace supports it — check the specific server's docs, since exact variable names differ between implementations.

Personal access token or OAuth machine-to-machine?

A personal access token authenticates as you — anything your user account can see in Unity Catalog, the agent can see. OAuth machine-to-machine auth via a dedicated service principal is the better fit for anything beyond solo experimentation: you create a service principal, grant it specific catalog/schema/table permissions through Unity Catalog's own grant system, and the agent's reach is exactly what that principal was granted — independent of your own permissions, and revocable without touching your account.

How do I keep it safe?

Lean on Unity Catalog's existing grant model rather than trusting the MCP layer to add its own restrictions — grant the connecting principal SELECT on specific catalogs/schemas rather than workspace-wide admin, and use a SQL warehouse with a sensible timeout so a runaway query from a misinterpreted request doesn't run up compute costs unchecked. As with any warehouse integration, keep write and DDL grants off any credential used for exploratory agent access.

Troubleshooting

Because implementations vary, verify these basics before assuming a bug:

Author & links

Author: Unsettled — check Databricks Labs and the MCP registry for the current maintainer

Start here: github.com/databrickslabs

License: Varies by implementation — check each repo

Related skills

For the data these workspaces often sit on top of, see the AWS S3 MCP server. For comparable warehouse-scale SQL access, see the Snowflake MCP server or BigQuery MCP server. For transformation-layer context, see the dbt MCP server.

← Back to MCP Servers