Databricks Connections

Databricks is not a native Firetiger connection type. Instead, you connect agents to your Databricks Delta Lake tables through Databricks’ managed MCP servers — hosted Model Context Protocol endpoints that run SQL against Unity Catalog on your behalf. Firetiger registers the endpoint as an MCP Server connection and the agent invokes its tools.

Recommended: Create and manage the connection via the web UI at https://ui.cloud.firetiger.com/integrations/mcp

How it works 

Firetiger agent
  → MCP Server connection (this guide)
  → https://<workspace-hostname>/api/2.0/mcp/sql   (Databricks managed MCP server)
  → SQL Warehouse
  → Unity Catalog (Delta Lake tables)

Databricks enforces Unity Catalog permissions for the authenticating identity, so the agent can only see and query tables that identity is allowed to read.

Prerequisites

In your Databricks workspace:

  1. A running SQL Warehouse (Databricks managed MCP uses it as the compute layer).
  2. The authenticating identity needs Unity Catalog grants on everything the agent will touch:
    • USE CATALOG on the target catalog(s)
    • USE SCHEMA on the target schema(s)
    • SELECT on the tables to be queried or described
    • CAN_USE on the SQL Warehouse
  3. Your workspace hostname, e.g. dbc-1234abcd-5e6f.cloud.databricks.com.

Managed MCP server URLs

Databricks exposes more than one managed MCP server. The two relevant for querying Delta Lake tables are:

Server URL Use it for
Databricks SQL https://<workspace-hostname>/api/2.0/mcp/sql Running SQL across Unity Catalog tables
Genie https://<workspace-hostname>/api/2.0/mcp/genie/<genie-space-id> Natural-language questions over a specific Genie Space

Use the Databricks SQL URL for direct table queries. Use Genie if you’d rather the agent ask questions in natural language against a curated Genie Space.

Setup (UI)

The UI is the quick path for the bearer-token (PAT) mode:

  1. Navigate to Settings > MCP Servers in the Firetiger UI (https://ui.cloud.firetiger.com/integrations/mcp).
  2. Click Connect Server.
  3. Enter the Server URL: https://<workspace-hostname>/api/2.0/mcp/sql.
  4. Choose Bearer token and paste a Databricks personal access token, then click Connect.

Once the connection reports Connected, Firetiger fetches the tool list from the server. The connection becomes available to agents that reference it.

For OAuth, use the API, not the UI. The UI’s static-OAuth form only submits a client ID and secret — it can’t pass OAuth scopes. Databricks requires the sql scope (and offline_access for token refresh), so set up Databricks OAuth through the API as shown in OAuth — pre-registered app below.

Authentication

The Databricks managed MCP servers authenticate with OAuth (on-behalf-of-user). Two modes work with Databricks — pre-registered (static) OAuth, or a personal access token as a bearer token. Pick based on your needs.

OAuth — pre-registered app (recommended)

Register an OAuth app (a “custom app integration”) in your Databricks account console, then connect with Static OAuth using its client_id / client_secret. This queries as the authorizing user, so Unity Catalog permissions are enforced per-user.

When you register the custom app, configure two things or the flow below will fail:

  • Redirect URL — add https://api.cloud.firetiger.com/mcp/oauth/callback (or your deployment-specific API base). Firetiger sends this exact value as the redirect_uri, and Databricks rejects the authorization with a redirect-URI mismatch if it isn’t pre-registered.
  • Scopes — grant the app the scopes Firetiger requests: sql and offline_access (or a broader scope such as all-apis). An app created without them either rejects the authorization or can’t issue the refresh token Firetiger relies on — leaving a connection that stops working when the access token expires.

Set this up through the API (the UI’s OAuth form can’t pass the required scopes):

curl -X POST "https://api.cloud.firetiger.com/v1/mcp-connections:initiateStaticOAuth" \
  -H "Authorization: Bearer $FIRETIGER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "server_url": "https://<workspace-hostname>/api/2.0/mcp/sql",
    "client_id": "<databricks-oauth-client-id>",
    "client_secret": "<databricks-oauth-client-secret>",
    "scopes": ["sql", "offline_access"],
    "display_name": "Databricks SQL — Production"
  }'

The response carries an authorization_url; open it to authorize, and the connection is created when the flow completes. Request the offline_access scope (as above) so Databricks issues a refresh token — without it, Firetiger cannot rotate the access token and the connection stops working when the token expires.

Dynamic OAuth is not supported by Databricks. Databricks managed MCP servers do not support RFC 7591 dynamic client registration, so the :initiateDynamicOAuth flow will not work here. Pre-register an OAuth app in the Databricks account console and use Static OAuth, as above.

Bearer token — Databricks PAT (simplest to validate)

For a quick end-to-end check, use a Databricks personal access token as a bearer token. This is the fastest way to confirm tool discovery and querying work, but it queries as a single identity (the token owner) rather than per-agent-user.

curl -X POST "https://api.cloud.firetiger.com/v1/mcp-connections" \
  -H "Authorization: Bearer $FIRETIGER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "mcp_connection": {
      "server_url": "https://<workspace-hostname>/api/2.0/mcp/sql",
      "display_name": "Databricks SQL (PAT)",
      "bearer_token": { "token": "<databricks-personal-access-token>" }
    }
  }'

Bearer tokens are write-only — Firetiger never returns them in responses.

Private workspaces

If your Databricks workspace is only reachable over a private network (e.g. AWS PrivateLink, no public endpoint), route the connection through a network transport such as a Tailscale tailnet. Set the connection’s network_transport to the configured transport and Firetiger sends the MCP traffic through it instead of the public internet.

Important: network_transport is only settable on the direct-create auth modes — bearer_token and no_auth. OAuth connections always connect over the public internet. So for a privately-networked workspace, authenticate with a Databricks personal access token (bearer token) and attach the network transport; OAuth is not an option until the workspace is publicly reachable. Most Databricks workspaces are publicly reachable and don’t need this.

Viewing available tools

After connecting:

  1. Open the connection card under Settings > MCP Servers.
  2. Review the Available Tools section — the Databricks SQL server typically exposes tools to list catalogs/schemas, describe tables, and execute SQL.
  3. Click Refresh Tools if Databricks publishes new tools.

Using it from an agent

Reference the connection from the agent’s plan. Once attached, the agent can call the Databricks tools to explore and query, for example:

Describe main.sales.orders, then sum revenue by region for the last 30 days.

The agent describes the table to learn its schema, then issues a SELECT through the SQL Warehouse. Results come back as structured tool output.

Best practices

  • Scope the SQL Warehouse and grants narrowly — the agent inherits exactly the Unity Catalog access of the authenticating identity. Grant only SELECT on the tables it needs.
  • Prefer OAuth over a PAT for production, so queries run per-user and tokens rotate automatically.
  • Document the connection — use the description field to tell the agent which catalogs/schemas are relevant and what the data represents.
  • Validate with a PAT first — confirm tool discovery and a sample query end-to-end, then switch to OAuth for the real deployment.
This site uses Just the Docs, a documentation theme for Jekyll.