Platform services

Beyond the core source and harness workflow, the integration connects to Databricks platform services for LLM serving, analytics, RAG, and governance. All features reuse the PAT or OAuth auth established when you set up the source.

Mosaic AI Model Serving provider

Mosaic AI Model Serving lets you use Databricks-hosted LLMs (Claude, Llama, GPT-OSS, DBRX, and custom fine-tuned models) as the agent's model provider.

Note: Mosaic AI is a first-class LLM provider in Fabric Agents — see Databricks Mosaic AI provider for the recommended setup, including automatic endpoint discovery, per-dialect AI Gateway routing, and guardrail/cost-attribution headers. The steps below only cover creating the serving endpoint on the Databricks side.

Create a serving endpoint

1. In your Databricks workspace, go to Machine Learning → Serving.
2. Click Create serving endpoint.
3. Choose a model (e.g. a pay-per-token foundation model or a custom fine-tuned model).
4. Select a workload size (start with Small for dev, Medium for team use).
5. Click Create and wait for the endpoint state to reach READY.
6. Copy the Endpoint name.

Then follow the provider setup with your workspace URL — the provider discovers available endpoints and routes each one through the correct API dialect automatically. Costs are attributed to the endpoint's workload and can be tracked via Databricks usage dashboards.

AI Gateway route configuration

AI Gateway is optional but recommended for production. It adds guardrails, rate limiting, and cost attribution tags to all LLM traffic.

With AI Gateway (recommended)

1. In your Databricks workspace, go to Machine Learning → AI Gateway.
2. Click Create route.
3. Set the Route name (e.g. fabric-agents-route).
4. Select the Target endpoint (your Mosaic AI serving endpoint).
5. Configure guardrails:
   • Content filtering: enable PII redaction and toxicity detection.
   • Rate limiting: set requests per minute (e.g. 100 for dev, 1000 for production).
   • Cost attribution tags: add project=fabric-agents, env=dev, team=databricks-accelerator.
6. Click Save.

Point the Mosaic AI provider at the gateway route. Fabric Agents sends guardrail configuration (X-Guardrail-Config) and cost attribution tags (X-Cost-Attribution-Tags) as request headers on gateway-routed traffic.

Without AI Gateway

Skip route creation and point the provider directly at the serving endpoint. All features work without AI Gateway — you just lose centralized guardrails and cost attribution.

Genie MCP source setup

Genie provides natural-language analytics on Databricks data. Fabric Agents connects to the managed Genie MCP server hosted in your own workspace over streamable HTTP — there is no local process to install and no query data leaves Databricks.

1. Create a Genie space

1. In your Databricks workspace, go to Genie.
2. Click New space → name it (e.g. Fabric Agents Analytics).
3. Select the SQL warehouse to use for queries.
4. Add tables or semantic models to the space.

You do not need to note the space ID — the MCP endpoint is workspace-level, and Genie resolves the space while answering.

2. Generate a PAT for Genie

The token owner needs CAN USE on the Genie space and on the underlying SQL warehouse, plus SELECT on the tables in the space.

GRANT USE ON WAREHOUSE `sql-warehouse-id` TO `fabric-agent-sp`;

3. Configure the MCP source

Create the source folder:

mkdir -p ~/.fabric-agent/workspaces/{workspaceId}/sources/databricks-genie

Write config.json:

{
  "id": "databricks-genie",
  "name": "Databricks Genie",
  "slug": "databricks-genie",
  "type": "mcp",
  "provider": "databricks",
  "tagline": "Natural-language analytics via Databricks Genie — powered by Genie.",
  "icon": "🔷",
  "enabled": true,
  "mcp": {
    "transport": "http",
    "url": "https://<workspace-host>/api/2.0/mcp/genie",
    "authType": "bearer"
  }
}

Replace <workspace-host> with your workspace hostname — the part after https:// in your Databricks URL, such as adb-1234567890123456.7.azuredatabricks.net on Azure or mycompany.cloud.databricks.com on AWS.

4. Authenticate

fabric-cli source test databricks-genie

Paste the PAT when prompted. The test validates that the endpoint is reachable and responds to a tools/list request.

5. Use Genie in chat

The server exposes four read-only tools — genie_ask starts a question, genie_poll_response follows it to completion, genie_get_query_result fetches the underlying rows, and genie_cancel_response stops a turn in flight.

Note: The "Powered by Genie" badge appears in responses when Genie handles the query. The agent delegates NL analytics to Genie and falls back to direct SQL for structured queries.

Vector Search source setup

Vector Search enables RAG (Retrieval-Augmented Generation) by indexing documents or table rows and querying them via vector similarity.

1. Create a Vector Search index

1. In your Databricks workspace, go to Machine Learning → Vector Search.
2. Click Create index.
3. Select the source table (e.g. main.default.support_tickets) and the text column to index.
4. Choose an embedding model (e.g. bge-small-en-v1.5 or gte-large-en-v1.5).
5. Set the sync mode (Triggered or Continuous).
6. Click Create and wait for the index to reach ACTIVE.
7. Copy the Index name (e.g. main.default.support_tickets_index).

2. Grant permissions

GRANT USE ON WAREHOUSE `sql-warehouse-id` TO `fabric-agent-sp`;
-- Vector Search uses the same warehouse for query execution

3. Configure the source

{
  "id": "databricks-vector-search",
  "name": "Databricks Vector Search",
  "slug": "databricks-vector-search",
  "type": "api",
  "provider": "databricks",
  "tagline": "Vector similarity search for RAG — query documents and table rows via Databricks Vector Search.",
  "icon": "🔷",
  "enabled": true,
  "api": {
    "baseUrl": "https://<workspace-host>.cloud.databricks.com/",
    "authType": "bearer",
    "authScheme": "Bearer",
    "defaultHeaders": { "Content-Type": "application/json" },
    "testEndpoint": {
      "method": "GET",
      "path": "api/2.0/vector-search/indexes"
    }
  }
}

4. Use Vector Search in chat

The RAG flow:

1. User asks a question.
2. Agent embeds the query (via the same embedding model used for the index).
3. Agent calls POST /api/2.0/vector-search/indexes/{index_name}/query with the query embedding.
4. Vector Search returns top-k similar documents/rows.
5. Agent injects retrieved context into the LLM prompt and generates an answer.

SQL Warehouse source setup

The SQL Warehouse source lets the agent execute SQL queries directly via the Statement Execution API. It reuses the same PAT/OAuth auth as the main Databricks source.

1. Identify your warehouse

1. In your Databricks workspace, go to SQL Warehouses.
2. Select the warehouse to use (Serverless recommended for auto-start).
3. Copy the Warehouse ID from the URL or the warehouse details page.

2. Grant permissions

GRANT USE ON WAREHOUSE `sql-warehouse-id` TO `fabric-agent-sp`;

For write operations (CREATE TABLE, INSERT):

GRANT CREATE TABLE ON SCHEMA main.default TO `fabric-agent-sp`;
GRANT USAGE ON SCHEMA main.default TO `fabric-agent-sp`;

3. Configure the source

{
  "id": "databricks-sql-warehouse",
  "name": "Databricks SQL Warehouse",
  "slug": "databricks-sql-warehouse",
  "type": "api",
  "provider": "databricks",
  "tagline": "Direct SQL execution via Databricks Statement Execution API.",
  "icon": "🔷",
  "enabled": true,
  "api": {
    "baseUrl": "https://<workspace-host>.cloud.databricks.com/",
    "authType": "bearer",
    "authScheme": "Bearer",
    "defaultHeaders": { "Content-Type": "application/json" },
    "testEndpoint": {
      "method": "GET",
      "path": "api/2.0/sql/warehouses"
    }
  }
}

4. Safe query execution

By default, the SQL Warehouse source runs in read-only mode. The agent only executes SELECT and DESCRIBE statements. To enable writes, update permissions.json:

{
  "allowedSqlStatements": [
    { "type": "SELECT", "comment": "Read-only queries" },
    { "type": "CREATE TABLE", "comment": "Create result tables" },
    { "type": "INSERT", "comment": "Write results back" }
  ]
}

Warning: Always use a dedicated schema for agent writes (e.g. main.fabric_agent_results). Never grant DROP or DELETE unless absolutely necessary.

5. Example prompts

Unity Catalog browser source setup

The Unity Catalog browser is a read-only source for exploring catalog metadata, lineage, and grants. It does not execute queries or mutate data.

1. Grant read-only permissions

GRANT USE CATALOG ON CATALOG main TO `fabric-agent-sp`;
GRANT BROWSE       ON CATALOG main TO `fabric-agent-sp`;
GRANT USE SCHEMA   ON SCHEMA main.default TO `fabric-agent-sp`;
GRANT BROWSE       ON SCHEMA main.default TO `fabric-agent-sp`;

No SELECT, CREATE, DROP, or ALTER grants are needed. The browser is intentionally limited to metadata.

2. Configure the source

{
  "id": "databricks-uc-browser",
  "name": "Unity Catalog Browser",
  "slug": "databricks-uc-browser",
  "type": "api",
  "provider": "databricks",
  "tagline": "Read-only Unity Catalog browser — catalogs, schemas, tables, lineage, and grants.",
  "icon": "🔷",
  "enabled": true,
  "api": {
    "baseUrl": "https://<workspace-host>.cloud.databricks.com/",
    "authType": "bearer",
    "authScheme": "Bearer",
    "defaultHeaders": { "Content-Type": "application/json" },
    "testEndpoint": {
      "method": "GET",
      "path": "api/2.1/unity-catalog/catalogs"
    }
  }
}

3. Set read-only permissions

Create permissions.json to enforce read-only access:

{
  "allowedApiEndpoints": [
    { "method": "GET", "path": "api/2.1/unity-catalog/.*", "comment": "UC metadata read-only" },
    { "method": "GET", "path": "api/2.1/lineage/.*", "comment": "Lineage read-only" }
  ]
}

No POST, PUT, PATCH, or DELETE endpoints are allowed. The agent will refuse any mutation request.

4. Example prompts

Consumption and cost attribution

Cost attribution tags

Tag all resources the agent touches so costs can be traced back to the Fabric Agents project:

-- Catalog-level tags
ALTER CATALOG main SET TAGS (
  'cost_center' = 'engineering',
  'project'     = 'fabric-agents',
  'env'         = 'dev',
  'team'        = 'databricks-accelerator'
);

-- Table-level tags
ALTER TABLE main.default.customers SET TAGS (
  'project' = 'fabric-agents',
  'pii'     = 'true',
  'refresh' = 'hourly'
);

Also tag SQL warehouses, clusters, and Model Serving endpoints in the Databricks UI:

• cost_center: engineering
• project: fabric-agents
• env: dev

In-session consumption capture

Fabric Agents captures consumption events for the current app run from three signals:

• Cost headers — X-Databricks-Query-Id, X-Databricks-Cost, X-Databricks-DBUs on any Databricks API response.
• Token usage — the usage block in Model Serving / AI Gateway responses (both OpenAI-style and Anthropic-style token counts).
• SQL lineage — table reads and writes heuristically extracted from Statement Execution API calls (FROM/JOIN/INSERT INTO/CREATE TABLE AS/MERGE).

Ask the agent for a "Databricks consumption report" (the databricks_consumption_report tool) to see per-source totals and lineage. Everything is held in memory for the current run; persistence to Lakebase or Unity Catalog is on the roadmap.

Viewing consumption

1. In Databricks, go to Account Console → Usage.
2. Filter by tag project = fabric-agents.
3. Break down by resource type (SQL warehouse, Model Serving, Vector Search).

Agent traffic is also identifiable in audit logs via the fabric-agents/<version> User-Agent. For per-query cost attribution on LLM traffic, enable AI Gateway cost tags (see above).

Related

• Databricks Mosaic AI provider — first-class LLM provider setup
• Authentication — the source these services build on
• Genie docs
• Vector Search docs
• AI Gateway docs
• Mosaic AI Model Serving docs