Integration

MCP for Databricks: Claude, reading your lakehouse read-only.

Your lifecycle data lives in the lakehouse. The events table, the profiles, the subscription and revenue history — the real record of who your customers are and what they did — all of it sits in Databricks, governed by Unity Catalog. When you want to draft a win-back or reason about a churn cohort, that's the source you check first. So you open a SQL editor, remember which catalog the events landed in, join to profiles, and squint at the result. Ask Claude for help and it gives you good thinking about lifecycle — general thinking. It has never seen your schema, your cohort, or last month's revenue curve. An MCP for Databricks — a way to hand Claude a read-only token on your warehouse instead of general knowledge — is what closes that gap. It's a data source, not a send channel: Claude reads the real numbers, then reasons about the work.

What "MCP" actually means here.

MCP stands for Model Context Protocol, an open standard from Anthropic that lets Claude reach outside the chat window. Think of it as a plugin system, except the plugins don't add small features — they give Claude entirely new capabilities: tools that read your data and reason over it. Orbit is one such MCP, built for lifecycle work. Install it, connect a read-only Databricks token, and Claude gains the ability to walk your Unity Catalog and query your warehouse — read-only, and nothing more. Orbit is not an official Databricks product; it's an independent MCP that calls the SQL Statement Execution API with the token you provide, and nothing leaves your machine except the queries to Databricks you configured. The full walk-through of what an MCP is and how it changes the work lives on the MCP for marketing page →.

What Orbit does with Databricks today.

No hand-waving. This is a read integration, and the reads are native: list the namespace, describe a table, run a guarded SELECT. Where there's a limit, it's named — and we're careful to separate three different things: what the warehouse genuinely allows, what Orbit simply hasn't built yet, and what Orbit holds back on purpose because a write to your lakehouse from an unattended AI is a line worth never crossing.

Check the connection and list catalogs

Works today

The SQL Statement Execution API runs a SHOW CATALOGS against your SQL warehouse, so Orbit can confirm the workspace host, token, and warehouse id are live — and show you every catalog your identity is allowed to see — before any query touches a table.

Browse schemas and tables

Works today

SHOW SCHEMAS in a catalog and SHOW TABLES in a schema walk the Unity Catalog namespace natively. Claude can map what lives where — your events, profiles, subscription, and revenue tables — without you pasting a data dictionary first.

Describe a table

Works today

DESCRIBE TABLE and the information_schema views return column names, types, and comments. Claude reads the shape of a table before it selects from it, so the SELECT it writes lines up with your real columns rather than guessed ones.

Run a guarded read-only SELECT

Works today

A parameterised SELECT with an explicit LIMIT pulls the lifecycle-relevant slice — the cohort, the event window, the churn signal you asked about. Orbit only ever issues SELECT, SHOW, and DESCRIBE; DML and DDL are refused before the statement is ever sent.

Pull events, profiles, and cohort slices

Works today

It is all SELECT underneath, so pointing Claude at your behavioural events, user profiles, or a cohort definition just works. These are your tables, named the way your warehouse names them — Orbit reads them to reason about a lifecycle question; it does not model your schema for you.

Handle large result sets

Partial — named limit

The SQL Statement Execution API chunks results and caps how much comes back inline, returning a statement id Orbit polls to completion. That is deliberate: Orbit pulls a bounded slice for analysis, not a full table dump. Ask for a billion raw rows and it will tell you to aggregate or sample instead.

Read lineage and deeper Unity Catalog metadata

Partial — named limit

Table and column metadata via DESCRIBE and information_schema come back today. The richer picture — column-level lineage, and the system tables that track access and cost — lives behind separate surfaces Orbit has not wired in yet. A named limit, not a silent gap.

Write, INSERT, MERGE, or run DDL

Held back by design

Orbit never writes to your lakehouse from an unattended chat. No INSERT, no MERGE, no CREATE or DROP — a warehouse write from an AI you are not watching is exactly the line read-only draws. This is a deliberate guardrail, not a missing endpoint.

Run jobs, notebooks, or manage clusters

Held back by design

Orbit reads data; it does not operate your compute. Triggering a job, running a notebook, or resizing a cluster stays in Databricks, in your hands. Orbit is the analyst reading the warehouse, not the platform engineer running it.

The short version: with a read-only token, Orbit can walk your entire Unity Catalog, describe any table you've granted, and pull the exact slice a lifecycle question needs — a cohort, an event window, a revenue curve. The one thing it won't do, ever, from a chat you're not watching, is write. The warehouse stays yours to change.

List, describe, select — in that order.

This is where a read-only token earns its place. Orbit navigates the warehouse the way a careful analyst does — never a blind query against a table it hasn't read the shape of first.

  • List the namespace. SHOW CATALOGS, then SHOW SCHEMAS in a catalog, then SHOW TABLES in a schema. Claude maps where your events, profiles, and revenue tables actually live in Unity Catalog before it writes a single query.
  • Describe before you select. DESCRIBE TABLE and the information_schema views hand back column names, types, and comments — so the SELECT that follows matches your real columns instead of a guess about what a table probably contains.
  • Select the slice, not the table. A parameterised SELECT with an explicit LIMIT pulls the churn cohort, the onboarding funnel, or the revenue-by-signup-week aggregate you asked about — enough to reason over, never a raw table dragged across the wire.

None of this needs write access. The whole loop runs on a token that can only read — which is exactly how you should start, and where you should stay.

How to connect it.

Three things, and you decide how little the token can do. Orbit needs your workspace host, a personal access token, and the id of a SQL warehouse to run against. Paste them into Orbit's config and you're connected.

  • Read-only isn't a token flag — so grant it at the identity. Databricks doesn't scope a token read-only the way an ESP scopes an API key; a token inherits the Unity Catalog grants of whoever it belongs to. So mint it for an identity — a service principal is cleanest — granted only SELECT plus USE on the catalogs and schemas you want read, and nothing that can write. That token physically cannot mutate your lakehouse.
  • Orbit guards it a second time. Even with a broader grant, Orbit only ever issues SELECT, SHOW, and DESCRIBE, and refuses DML and DDL before the statement leaves your machine. Belt and braces: the grant is the wall, the guard is the second wall.

The token is stored as a secret and never leaves your machine in plain text. That's the whole setup — no OAuth dance, no app to install on the Databricks side. If a query needs a grant you haven't given, Orbit tells you which catalog or schema to open up rather than failing silently.

A data source, not a send channel — and why that's the honest split.

Orbit's lifecycle depth is email-first, and the sending — journeys, campaigns, the whole outbound machine — lives in an ESP. Its deepest single-platform integration there is Braze, built around concepts that only exist in Braze: Canvas flows, Content Blocks, its media library. Databricks sits on the other side of that line entirely. It's the warehouse Claude reads to understand a customer, not a place it messages one.

So the natural shape is simple: Orbit reads Databricks to inform the work — sizing the cohort, reading the churn signal — then builds and QAs the email against your ESP. The warehouse is the read; the ESP is the write. If you're deciding where the durable lifecycle record should live in the first place, the lifecycle stack without vendor lock-in guide → makes the case for a warehouse-first spine.

The half that isn't about the query at all.

Reading Databricks is the connection. The reason to bother is everything Claude does once it has the numbers. Orbit ships 79 lifecycle skills — structured protocols for the actual jobs: reading a churn cohort, laddering a win-back, scoring a subject line, composing an email. Those are source-agnostic; they work the same whether the data underneath came from Databricks or anywhere else.

Underneath sit 130 tools — an MJML pipeline that compiles to clean, dark-mode-safe HTML, a render-and-QA gate that catches the clipping and inbox breakage before you send, and the calculators a real test needs: sample size, holdout, replenishment timing. Databricks gives you the data. Orbit is the practitioner sitting next to it, reading the same tables you do and turning the read into a lifecycle decision.

Is this for you?

This is for the lifecycle or data person whose customer truth lives in Databricks and who wants Claude to read it before it drafts anything — the person who already writes the cohort SQL by hand and would rather hand Claude a read-only token than paste query results into a chat. If that's your week, Orbit gives you a Claude that walks your Unity Catalog and pulls the real slice through a token you scoped yourself. It's a weaker fit if you wanted something that runs pipelines or writes back to the lakehouse — Orbit doesn't, on purpose. It reads your warehouse and reasons like a lifecycle analyst, instead of guessing like a search engine — and it gives you a straight answer about what it will and won't touch, which is rarer than it should be.

Try it.

Orbit is free — every skill and tool included, no seats and no subscription. Mint a read-only token, paste in your host and warehouse id, and Claude goes from general advice to reading your real cohorts the same afternoon.

Get Orbit free

Read a different source?

The same honest treatment, per platform:

Frequently asked.

What is an MCP for Databricks?

An MCP — Model Context Protocol, an open standard from Anthropic — gives Claude real tools instead of general knowledge. Connected to Databricks through Orbit with your own workspace host and access token, Claude can list the catalogs, schemas, and tables in your Unity Catalog, describe a table, and run a read-only SELECT against your SQL warehouse to pull the lifecycle-relevant slice. It is a data source, not a send channel — Orbit reads the warehouse to inform lifecycle work, it does not message your customers through it. It is not an official Databricks product; it is an independent MCP that calls the SQL Statement Execution API with the token you provide.

Is the Databricks connection read-only?

Yes, and there is an honest wrinkle worth knowing. Databricks does not put a read-only flag on a personal access token the way an ESP scopes an API key. A token inherits the Unity Catalog grants of the identity it belongs to, so read-only is enforced two ways: mint the token for an identity — a service principal is cleanest — granted only SELECT plus USE on the catalogs and schemas you want read, and nothing that can write. Then Orbit itself only ever issues SELECT, SHOW, and DESCRIBE, and refuses DML and DDL before a statement is sent. Belt and braces, because a warehouse write from an unattended AI is exactly the line worth never crossing.

How does Orbit find its way around my warehouse?

The same way you would in a SQL editor, in order. First it lists: SHOW CATALOGS, then SHOW SCHEMAS in a catalog, then SHOW TABLES in a schema — walking the Unity Catalog namespace so Claude can map where your events, profiles, subscription, and revenue tables actually live. Then it describes: DESCRIBE TABLE and the information_schema views return column names, types, and comments, so the query it writes matches your real columns instead of guessed ones. Only then does it select the slice you asked about. List, describe, select — never a blind query against a table it has not read the shape of first.

Can Orbit pull events, profiles, and cohorts?

Yes — it is all SELECT underneath. Point Claude at your behavioural events, your user or account profiles, or a cohort definition, and it reads the slice it needs to reason about a lifecycle question: who churned last month, which cohort stalled after onboarding, what the revenue curve looks like by signup week. One caveat stated plainly: these are your tables, named the way your warehouse names them. Orbit reads them; it does not model your schema for you or invent a canonical events table that isn't there. It works with the lakehouse you already have.

What about very large tables?

The SQL Statement Execution API chunks results and caps how much comes back inline, returning a statement id that Orbit polls to completion. That shapes the honest posture: Orbit pulls a bounded slice for analysis — a cohort, an aggregate, a windowed sample with an explicit LIMIT — rather than dragging a billion-row fact table across the wire. Ask it for a whole raw table and it will tell you to aggregate, filter, or sample instead. Reading the warehouse is for reasoning about the data, not exporting it.

Where does Databricks sit in a lifecycle stack?

As the source of truth, not the send layer. Databricks is where the durable lifecycle data lives — the events, the profiles, the revenue and subscription history — which makes it the place Claude should read to understand who a customer is before it drafts anything. Orbit's lifecycle depth is email-first, and the sending, journeys, and campaign machinery live in an ESP like Braze. So the natural shape is: Orbit reads Databricks to inform the work, then builds and QAs the email against your ESP. The warehouse is the read; the ESP is the write.