Skip to main content
In this lesson we build a churn-detection LLM agent that queries customer signals stored in a Databricks Genie space. The implementation reuses the same LLM/agent logic as a BigQuery-based version — the only differences are the MCP transport (Databricks hosts an MCP endpoint) and the connection details (host URL + personal access token). The agent issues plain-English queries to the Genie space and reasons over streamed results to produce a churn-risk assessment. Below you’ll find:
  • a recommended .env layout (never commit .env),
  • a consolidated, corrected Python example showing how to configure the Databricks MCP connection,
  • a concise explanation of the two MCP transports (STDIO vs streamable HTTP),
  • and an example of the script output for a sample customer assessment.
Never commit .env files. Keep credentials and tokens out of source control.

.env example

Copy these entries into a local .env file and fill in the values appropriate for your environment. These variables are used by the sample script to configure the model provider (Claude via KodeKey in this demo), Google/BigQuery hints, Databricks Genie access, and an example Snowflake fallback.
Protect your Databricks personal access token (PAT) and any API keys. Rotate credentials regularly and grant the minimal permissions required (read-only where possible).

Consolidated Python example

The following consolidated example highlights the essential pieces:
  • environment loading,
  • model initialization (Claude via KodeKey for this demo),
  • and the Databricks MCP connection using streamable HTTP (no local MCP binary required).
Keep the code intact as your runnable starting point; tweak the agent invocation to match your project’s runner or ADK utilities.
Notes:
  • The only Databricks-specific configuration is the StreamableHTTPConnectionParams URL (targets the hosted MCP endpoint for your Genie space) and the Authorization header with the Databricks PAT.
  • Everything else — model initialization, agent instruction, and toolset usage — remains identical to a BigQuery-based agent implementation.
  • For Databricks specifics and PAT guidance, see Databricks authentication docs: https://docs.databricks.com/dev-tools/api/latest/authentication.html

How Databricks Genie space data maps to the agent

Within the Databricks Catalog, the Genie space exposes curated tables (or views) that the agent queries via MCP. In the churn demo the agent expects columns typically found in analytics and support tables, for example:
  • customer identifiers (e.g., customer_id)
  • usage metrics (e.g., daily_active, 30d_usage, usage_delta)
  • support ticket counts and ticket-level details (ticket id, category, priority, sentiment, resolved_at)
  • tenancy or signup timestamp (for tenure calculations)
The agent uses the customer ID as the primary lookup key and issues queries such as:
  • “Show me the last 90 days of support tickets for CUST-0003115”
  • “Return usage and delta for the last 30 days for CUST-0003115”
Because the Genie space exposes these tables through MCP, the MCP toolset streams row-level results back to the agent. The agent can then aggregate counts (e.g., ticket count, usage decline) or cite specific ticket rows (ID, priority, sentiment) when producing a churn assessment.

Example script run & sample output

A typical run of the Databricks churn agent produces a concise assessment with risk level, supporting signals, and a recommended action. Below is a cleaned example of the script output for a sample customer:
The agent interprets aggregated signals (counts, deltas) and, when available, cites granular ticket-level details (ticket IDs, priorities, sentiments) streamed from Databricks tables.

Key takeaway: MCP transports

MCP supports two primary transport modes. Choose the transport that matches how your MCP server is hosted or how your environment runs the MCP compatible tooling. When the MCP server is hosted (Databricks or another provider exposing an MCP endpoint), prefer StreamableHTTPConnectionParams and pass the MCP URL and authentication headers. This approach simplifies deployment and removes the need to manage a local MCP binary. That’s it — by swapping only the MCP transport configuration and adding Databricks connection environment variables, you can reuse the same LLM agent logic used in BigQuery-based implementations against a Databricks-hosted Genie space.

Watch Video