Data Warehouse MCP Servers in 2026: BigQuery, Databricks, Snowflake

Every analytics team runs the same queue. Twenty people waiting on questions that are one query away from an answer.

"What did churn look like for accounts that opened a ticket last month?" That is ten minutes of work and four days of waiting.

A data warehouse MCP server is the thing that clears that queue. It gives a model governed query tools instead of a connection string.

The idea is not new. What changed in 2026 is that the warehouses started hosting these servers themselves.

BigQuery, Databricks and Snowflake all run managed endpoints now. No container to deploy, no wrapper to maintain, and your existing permission model does the enforcing.

This guide covers what these servers actually give an agent, the one design rule that decides whether answers are correct, and how to connect one without handing over the warehouse.

What a Data Warehouse MCP Server Actually Is

An MCP server exposes tools with typed inputs that a model can call. If the protocol is new to you, start with what the Model Context Protocol is.

A warehouse server is a specific and unusually well-behaved case of that.

What it is not is a database driver with a chat interface. That distinction is the whole article.

A good warehouse MCP server exposes three kinds of tool:

• Semantic query — ask a business question against definitions a human wrote
• Retrieval — search unstructured text that lives alongside your tables
• Gated SQL — raw queries, usually read-only, for exploration and engineering

Most also expose metadata tools. The agent lists datasets, describes a table, and reads column comments before it writes anything.

That discovery step matters more than it looks. An agent that reads the schema first writes far better SQL than one that guesses.

Why the Warehouse Is the Highest-Leverage Thing to Connect

People usually connect the flashy servers first. GitHub, Slack, a ticket tracker.

Those are useful. The warehouse is the one that changes what the agent can answer.

Three reasons, and they compound.

1. The joins already happened

Your warehouse is where six source systems were reconciled into one story. Customers, subscriptions, events, tickets, invoices.

Point an agent at Stripe and it sees billing. Point it at the warehouse and it sees why the billing changed.

That is the difference between a lookup tool and something that answers a real question.

2. The governance already exists

This is the underrated one. Your warehouse has spent years accumulating roles, grants, row filters and masking policies.

An agent connecting through the warehouse inherits all of it for free. Nobody has to invent a new permission model for AI.

Compare that to the usual alternative — copying data into a vector store and rebuilding access control badly.

3. The answers are auditable

Every query the agent runs lands in query history, attributed to an identity, with a cost attached.

When someone asks how the agent got a number, you can show them the SQL. Try that with a model that summarised a spreadsheet.

The Semantic Layer Rule: Right Answers vs Plausible Ones

Here is where most warehouse agents quietly fail.

Give a model raw SQL access and it will answer everything. It sees a column called REV_NET_ADJ and decides that means revenue.

Maybe it does. Maybe it excludes refunds, or includes an intercompany adjustment that finance strips out every month.

The failure mode is not an error. It is a confident wrong number in a Slack thread. Nobody catches it until it reaches a board deck.

A semantic layer is the fix. Someone defines, once, what revenue means, which tables it comes from, and how it is filtered.

The agent asks the question. The semantic layer decides the SQL. The model never gets to invent your business definitions.

Every serious warehouse MCP server now leads with this. It goes by different names — Genie, Cortex Analyst, semantic views, conversational analytics — but it is the same idea.

That last point is not theoretical. A model treats an empty semantic result as a dead end and retries with whatever else is available.

The Data Warehouse MCP Landscape in 2026

The shift this year is that warehouses stopped leaving this to the community. Three of the majors host their own servers now.

Two patterns fall out of that table, and both are worth naming.

Hosted servers are per-account, not per-vendor. Only BigQuery has one fixed URL. Databricks and Snowflake endpoints live on your own hostname, which is what makes inherited identity work.

Semantic layers are the dividing line. BigQuery, Databricks, Snowflake, dbt and Looker have one. The smaller engines hand you SQL and trust you to supervise it.

That is not a knock on ClickHouse or Postgres. A read-only Postgres server is a fine analytics agent — the Postgres analytics agent recipe walks through one.

You just have to supply the missing guardrail yourself, usually as curated views the agent queries instead of base tables.

See what your warehouse server really exposes Paste the URL, complete auth, and read the real tool list and raw responses in your browser. Test any MCP server free →

The BigQuery MCP Server: One URL, Six Tools

BigQuery is the only warehouse here with a single fixed address. Every project connects to https://bigquery.googleapis.com/mcp over Streamable HTTP.

You sign in with Google Cloud credentials, an OAuth client, or an agent identity. IAM decides the rest.

The managed BigQuery MCP server exposes six tools, and the split is worth reading closely:

• list_dataset_ids and list_table_ids — discovery
• get_dataset_info and get_table_info — schemas, column descriptions, partitioning
• execute_sql_readonly — SELECT only
• execute_sql — any statement, DDL and DML included

Those last two are the entire security decision. An agent that can see execute_sql will call it eventually.

Close it at the identity, not in the prompt. A service account holding only roles/bigquery.dataViewer cannot write, whichever tool the model picks.

Where the semantic layer actually lives

Notice what is missing from that list. None of the six tools is a semantic tool.

Conversational Analytics is a separate surface. You reach it through the Conversational Analytics API, or through the Looker server described below.

That catches people out. They read that BigQuery has conversational analytics and assume the MCP endpoint speaks metrics.

It does not. Out of the box, the BigQuery server is metadata plus SQL. Pair it with a semantic source if non-engineers will act on the answers.

Google documents the managed endpoint in detail, and the BigQuery Migration Service ships a second, narrower server for translation work.

Databricks vs Snowflake MCP Servers

The two lakehouse vendors reached the same place from opposite directions, and the difference is worth one section.

Databricks splits by concern. Five managed servers already live in your workspace, and you scope an agent by choosing which URL it connects to.

There is one for Genie analytics across the workspace, one scoped to a single Genie space, one for Databricks SQL, one for AI Search indexes, and one that turns your Unity Catalog functions into tools.

That last one is underrated. A reviewed SQL function becomes a tool the model calls by name, instead of logic it rewrites from scratch each run. It also carries system.ai.python_exec, so the agent can compute on results rather than dragging rows into context.

Unity Catalog grants do the enforcing throughout, and each server has its own OAuth scope.

Snowflake composes by definition. You write one CREATE MCP SERVER statement listing exactly which tools it carries, and Snowflake hosts what you defined.

A specification can carry Cortex Analyst, Cortex Search, Cortex Agents, gated SQL that defaults to read_only: true, and your own procedures wrapped as generic tools.

Snowflake's own documentation gives good advice here: do not put raw SQL on the same server as a Cortex Agent, because a client can then bypass semantic validation entirely.

Worth knowing that there are two Snowflake servers. The managed one above, and Snowflake-Labs/mcp, an open-source server you run yourself over stdio for local work.

Between the two platforms, pick on where your data already lives. Neither server is good enough to justify moving a warehouse, and both are good enough to build on.

dbt, Looker and the Semantic-Layer Servers

Your semantic layer may not live in the warehouse at all. For plenty of teams it lives in dbt or Looker.

Both ship an MCP server now, and both beat raw SQL as a starting point.

The dbt MCP server

dbt Labs runs a remote MCP server on the dbt platform, plus a self-hosted one you start with uvx dbt-mcp.

The remote server carries the Semantic Layer, Discovery metadata, the admin API, and a text_to_sql tool.

Pick it when your metrics already live in dbt. The definitions your BI tool reads become the definitions your agent reads.

The self-hosted one adds dbt CLI commands, so an agent can run and test models rather than only query them.

Watch two quotas. The remote server shares the dbt API rate limit, and text_to_sql draws on your dbt Copilot allowance.

The Looker MCP server

Looker's server ships inside Google's MCP Toolbox for Databases, which you run yourself over stdio or on Cloud Run.

It answers in natural language against LookML explores rather than base tables.

LookML has been a semantic layer for years. Pointing an agent at it means nobody writes the definitions twice.

Which layer should win

Pick the one your humans already trust. If finance argues about a number, they argue in front of one definition.

Connecting dbt and Cortex Analyst and Looker at once is the mistake here. Three semantic sources means three answers and no tiebreaker.

One semantic server, one SQL server, and a rule about who gets which.

Text-to-SQL vs a Warehouse MCP Server

People ask whether this is text-to-SQL with a protocol bolted on. It can be, and that is the version that burns you.

The difference is one question: who wrote the SQL that produced the number?

A warehouse MCP server can serve either. Which is why the tool list you connect matters more than the vendor you chose.

Text-to-SQL is not worthless. It is genuinely good at exploration, and at drafting a query an engineer then corrects.

The natural-language SQL assistant recipe walks through that flavour end to end.

Just do not put it behind a Slack bot that answers board questions. Failure there is silent.

Read-Only Is the Whole Game

Ask any data team what worries them about an agent on the warehouse. Nobody says hallucination first. They say writes.

The fix is boring and it works. Enforce it at the identity, never in the prompt.

Create a dedicated service identity for the agent. Not a shared account, and never a person's credentials.

Grant it nothing by default. Then add one object at a time, as the agent proves it needs each one.

A system prompt saying "do not modify data" is a preference. A role without write grants is a fact.

Most managed servers help here. Snowflake defaults its SQL tool to read-only. Databricks routes everything through Unity Catalog grants. BigQuery uses IAM.

Read-only still is not harmless

This is where teams stop too early. A read-only agent cannot corrupt your warehouse. It can still leak it.

If a tool description or a returned row carries injected instructions, the agent can be steered into reading data and forwarding it somewhere.

That class of attack is well documented — the tool poisoning and OWASP MCP Top 10 breakdown covers how it plays out.

Warehouse servers raise the stakes. The blast radius of a poisoned tool is every table the role can see.

Which is one more argument for granting narrowly. The smallest useful grant is also the smallest possible leak.

Check the server before it reaches your data Scan tool descriptions, auth behaviour and injection surface against the OWASP MCP Top 10. Scan your MCP server →

How to Connect a Warehouse MCP Server in Seven Steps

Every one of these servers is a remote HTTP endpoint with OAuth or a bearer token. The order below is the part people get wrong.

1. Read tools/list first. Before any code, paste the URL into a browser tester and read the real tools and schemas.
2. Create a dedicated identity. A service account or service user for the agent alone, never a person's credentials.
3. Grant nothing, then add one object. Start from zero and widen only when a run fails on something it genuinely needs.
4. Split semantic from raw SQL. Two servers, two audiences. A model falls back to SQL the moment a semantic call returns nothing.
5. Cap the compute. A small dedicated warehouse, aggressive auto-suspend, a resource monitor, and a query timeout.
6. Scan the server. Check tool descriptions and auth behaviour against the OWASP MCP Top 10 before it touches production data.
7. Run a real model against it. Tool choice varies by model, so test the one you will ship in Agent Studio.

Step one saves the most time. Docs describe the server the vendor intended; tools/list describes the server your role can see.

Those are different documents more often than you would like, especially on Databricks, where each managed server carries its own OAuth scope.

Five Warehouse Agents Worth Building

A connected server does nothing on its own. These five earn the setup.

1. The analyst that answers in Slack

Warehouse server plus Slack. Someone asks a metric question in a channel and gets an answer grounded in the semantic layer.

This is the one that clears the queue. Model: Claude Sonnet 5, because the job is ask, then sanity-check the number before posting.

Cheaper models do the asking and skip the checking, which is the step that matters.

2. The metric watchdog

Same server, run on a schedule instead of a prompt. It queries the same six metrics every morning and reports only what moved.

Anomaly detection you can read. It reports the number, the delta, and the query that produced it.

3. The pipeline debugger

Warehouse plus GitHub. The agent reads the broken table, then reads the transform that wrote it, then proposes the fix.

This one justifies raw SQL access, because the audience is engineers who can check the query.

4. Retrieval inside the perimeter

Search support transcripts and internal docs where they already live, under the same grants as your tables.

No second copy of sensitive text in a third-party index. That argument is what gets these past a security review.

5. The schema explainer

The unglamorous one that pays off immediately. New joiners ask what a table means and which column is authoritative.

Metadata tools answer that without a single row of data leaving the warehouse.

Whatever you build, keep the connected server count low. Two or three is the ceiling before tool selection degrades — the MCP agent use cases guide covers the pattern by role.

What a Warehouse Agent Actually Costs

Teams budget for tokens and get surprised by compute. The compute bill is the bigger one.

An analyst thinks, then writes one query. An agent writes six, three of which were wrong and re-run after an error.

Three controls handle it:

1. A dedicated warehouse or compute pool, sized small, so agent spend is visible on its own line.
2. Aggressive auto-suspend. Agent traffic is bursty, and idle compute is pure waste.
3. A hard quota — a resource monitor, a credit cap, a billing limit. A cap you set beats a bill you discover.

Add a query timeout wherever the server supports one. A runaway generated query is a routine event, not an edge case.

One more habit worth building: make the agent aggregate in SQL rather than returning rows. Ten thousand rows in context is expensive twice over.

Where Warehouse Agents Go Wrong

1. Raw SQL when a semantic layer exists. You trade correct answers for flexible ones.
2. Reusing a human's credentials. The agent inherits their grants and muddies their audit trail.
3. Returning rows instead of answers. Aggregate in the warehouse, not in the context window.
4. Connecting every server at once. Each tool schema costs context on every request — see MCP context bloat.
5. Assuming every call is synchronous. Some semantic tools generate SQL, run it, then return. Agents time out waiting.
6. Trusting the docs over the server. Docs drift. The tools/list response does not.

Warehouse MCP Glossary

Five terms do most of the work in this space, and vendors name them differently.

How MCP Playground Helps

Managed warehouse servers are remote HTTP endpoints with bearer or OAuth auth, which means you can inspect one in a browser before writing any agent code. Paste the URL into the MCP server tester, complete auth, and read the real tool list, the real input schemas and the raw JSON-RPC responses. That is how you find out a semantic call is asynchronous, or that a tool you designed around is not visible to the role you connected with. From there you can open the Snowflake server page or the full server directory for setup details, then run a live model against your tools in Agent Studio.

Frequently Asked Questions

What is a data warehouse MCP server?+

It is an MCP server that exposes your warehouse to an AI agent as a set of governed tools rather than a database connection. A good one offers three kinds of tool: semantic query, where the agent asks a business question against definitions a human wrote; retrieval over unstructured text stored alongside your tables; and gated SQL, usually read-only, for exploration. Most also expose metadata tools so the agent can describe a table before querying it.

Which data warehouses have official MCP servers?+

BigQuery, Databricks and Snowflake all host managed servers. BigQuery has a single fixed endpoint at bigquery.googleapis.com/mcp with OAuth sign-in. Databricks hosts several servers on your own workspace hostname under /api/2.0/mcp/. Snowflake hosts a server you define yourself with a CREATE MCP SERVER statement, reachable on your account URL. ClickHouse and the Postgres family have official open-source servers you run locally instead.

Should the agent use a semantic layer or raw SQL?+

Use the semantic layer for anyone who will act on the number without reading the query. It answers against definitions a human wrote, so the model never infers what a column means from its name, which is where confident wrong answers come from. Keep raw SQL for engineers who can spot a bad query, and put it on a separate server so a model cannot fall back to it when a semantic tool returns nothing.

How do I stop an agent writing to the warehouse?+

Enforce it at the identity, not in the prompt. Create a dedicated service identity for the agent, grant it nothing by default, and add read access one object at a time. A system prompt saying do not modify data is a preference. A role with no write grants is a fact. Server settings such as Snowflake read_only flag or Unity Catalog grants are a useful second layer, but the grant is the boundary that holds.

Is a read-only warehouse agent safe?+

Safer, not safe. Read-only removes the risk of corrupting data but not the risk of leaking it. If a tool description or a returned row carries injected instructions, the agent can be steered into reading data and forwarding it. On a warehouse the blast radius is every table the role can see, which is the strongest argument for granting narrowly and scanning servers before you connect them.

What does running a warehouse agent cost?+

More in compute than in tokens. An agent issues several queries where an analyst writes one, because it explores, gets an error and retries. Give it a dedicated small warehouse with aggressive auto-suspend so the spend is visible on its own line, set a resource monitor or billing cap, and add a query timeout where the server supports one. Also design prompts so the agent aggregates in SQL rather than returning raw rows.

What tools does the BigQuery MCP server expose?+

Six, on one fixed endpoint at bigquery.googleapis.com/mcp. Two list tools for datasets and tables, two info tools that return schemas and column descriptions, execute_sql_readonly for SELECT statements, and execute_sql for any statement including DDL and DML. There is no semantic tool in that set, so conversational answers come from the separate Conversational Analytics API rather than from the MCP server itself.

Databricks vs Snowflake MCP server: which should I choose?+

Choose on where your data already sits, because neither server justifies moving a warehouse. Databricks gives you several fixed managed servers and you scope an agent by picking which URL it connects to, with Unity Catalog grants enforcing throughout. Snowflake gives you one server you compose yourself with a CREATE MCP SERVER statement listing exactly which tools it carries, with RBAC on the server and each tool.

Does dbt have an official MCP server?+

Yes, two forms. dbt Labs runs a remote MCP server on the dbt platform that exposes the Semantic Layer, Discovery metadata, the administrative API and a text_to_sql tool over HTTP with OAuth or token auth. You can also self-host with uvx dbt-mcp, which adds dbt CLI commands so an agent can run and test models. Pick dbt when your metric definitions already live there.

Is a data warehouse MCP server the same as text-to-SQL?+

Only if you connect it that way. Text-to-SQL means the model writes the query from column names, which produces confident wrong numbers when a column is not what its name suggests. A semantic tool on a warehouse MCP server answers from definitions a human reviewed, so the model never invents your business logic. Most managed servers ship both kinds of tool, and the split you expose decides which one you get.

Is there a Redshift MCP server?+

Yes. Amazon Redshift works through the AWS MCP server with the Redshift skills, which cover metadata discovery, SQL syntax, data loading and materialized view guidance for both provisioned clusters and Serverless workgroups. AWS Labs also publishes a standalone Redshift MCP server you run yourself for discovering and querying clusters. Neither ships a semantic layer, so supply curated views if non-engineers will use it.

Can I connect a warehouse MCP server to Claude or ChatGPT?+

Yes. The managed servers are remote Streamable HTTP endpoints with OAuth or bearer auth, so any MCP-capable client can connect, including Claude, ChatGPT, Cursor and VS Code. Auth is the part that differs: BigQuery uses Google Cloud credentials or an agent identity, Databricks issues an OAuth scope per managed server, and Snowflake uses Snowflake OAuth by default. Test the URL in a browser tester before wiring up a client.

Start With One Question, Not a Platform

A warehouse MCP server is the highest-leverage thing you can hand an agent. The joins already happened, the governance already exists, and every answer is auditable.

Get two decisions right and the rest is detail. Ask through a semantic layer, and connect with an identity that can only read.

Pick the question your team waits on most this week and build that one agent. Inspect the server in a browser before it ever sees a production credential.

Test your warehouse MCP server in the browser Paste the URL, complete auth, and inspect every tool and raw response. No install, no sign-up. Test any MCP server free → Scan your MCP server →