What is the Best Way to Connect AI Agents to a Data Warehouse via MCP?

The best way to connect AI agents to a data warehouse via MCP is to start with the warehouse vendor's own managed MCP server when one exists, because it inherits the vendor's OAuth and role-based access control: Snowflake's managed MCP server caps a server at 50 tools and requires a separate grant for each one. Add an open-source gateway or an agent layer only for the gaps that remain.

Key Takeaways

• •MCP stands for Model Context Protocol, an open protocol for exposing tools to AI clients. It is not a "Modular Control Plane", as an earlier version of this page wrongly said.
• •Prefer the warehouse's managed MCP server for governed, read-mostly access. Snowflake documents 50 tools per server and per-tool grants, so access control stays in the warehouse and out of the agent.
• •Databricks documents 11 managed MCP servers, including one for SQL on a warehouse that runs with the caller's permissions.
• •Use an open-source gateway such as Google's MCP Toolbox for Databases when you need a custom, parameterized tool surface across several databases.
• •Use an agent layer, such as our swarm, when the job spans catalog, quality, schema and pipelines, not just running a query.

What is the best way to connect AI agents to a data warehouse via MCP?

There are three layers to decide on. The first is transport and auth: how an MCP client such as Claude Code, Cursor or VS Code reaches the warehouse and proves who it is. The second is the tool surface: which operations the agent can call (run SQL, search a semantic layer, describe a table). The third is the orchestration above the tools: who decides which tool to call, in what order, and what happens after a failure.

We recommend deciding in that order. Transport and auth belong as close to the warehouse as possible, because that is where your roles, row policies and masking already live. The tool surface should start small and read-only. Orchestration is where a single query tool stops being enough.

The MCP specification's tools page describes tools as model-controlled and says there should always be a human in the loop with the ability to deny invocations. Treat that as a design requirement for any write path to a warehouse, not a suggestion.

How the leading options differ

Warehouse-managed servers are the lowest-effort route. Snowflake's documentation says its server defaults to OAuth 2.0, lets you expose Cortex Agents, Cortex Analyst semantic views, Cortex Search and SQL execution as tools, and sets the SQL tool to read_only by default. It also notes that access to the server does not grant access to its tools, so you grant USAGE or SELECT on each underlying object. The same page lists limits worth planning around: responses truncate at 250 KB for custom tools and the SQL tool, and the server supports tools only, not resources, prompts or sampling.

Databricks takes a similar approach. Its managed servers live in the system.ai schema and include Databricks SQL, which runs queries on a SQL warehouse using the caller's permissions, and Genie One for natural-language analytics. Some pieces are still in beta and need an account admin to enable them, so check the Databricks page against your workspace before committing.

Open-source gateways cover what vendors do not. Google's MCP Toolbox for Databases and the Snowflake-Labs MCP repository let you run your own server and define the tools yourself. You get control over each tool's SQL and parameters, and you also take on hosting, upgrades and auth hardening.

Data-quality and metadata tools sit next to this decision rather than inside it. Great Expectations, Monte Carlo and Bigeye produce the quality and freshness signals an agent needs to trust a table. Amundsen supplies catalog metadata. MLflow tracks the experiments that consume the data. Fivetran moves data into the warehouse. None of them is a substitute for the warehouse connection itself, but an agent that can read their output makes better decisions about which table to query.

Where Data Workers fits

We do not replace the warehouse's MCP server. Data Workers is a set of MCP servers of its own, and its Connectors Agent talks to Snowflake, BigQuery, Databricks and Postgres. The question it answers is different: what happens after the agent can run a query. When a nightly pipeline slows down, the Incidents Agent traces the cause across lineage and logs, and the Schema Agent maps what a column change would break downstream.

The open-source edition (dw-claw) is Apache 2.0, runs locally and is read-only by default. Pro adds writes, enterprise connectors, approval workflows and audit trails. If you only need governed SQL access from an IDE, the warehouse's managed server is probably enough, and we say so plainly.

Where a swarm earns its place is shared context. A schema change, a failing quality check and a governance policy are usually seen by three separate tools. When the agents share context, a question like "what's the blast radius if I drop this column?" gets answered from lineage and usage together, not from a single query result.

How to evaluate for your stack

Work through these checks before choosing:

• •Identity: does the server use your existing OAuth or SSO identity and roles, or a shared service token? Prefer per-user identity so audit logs name a person.
• •Default permissions: is the SQL tool read-only by default? Snowflake's is. Confirm the same for anything you self-host.
• •Tool surface: can you restrict the agent to a curated set of tools or semantic views, rather than raw SQL on every schema?
• •Response limits: large result sets get truncated, so check the documented caps before building analyses on top.
• •Human approval: put a person between the agent and any write, in line with the MCP specification's guidance.
• •Data residency: confirm whether query results leave your network on their way to the model provider. Our agents run in your infrastructure, but the model client you connect still matters.

Run a one-week pilot with a read-only role and a short list of questions your team really asks, such as "why did row counts drop 40% overnight?" or "who has access to PII columns in analytics?". Count how many the agent answers correctly and how many it answers with confident but wrong SQL. That ratio tells you more than any feature list.

Frequently Asked Questions

Should I use the warehouse vendor's MCP server or a self-hosted one?

Start with the vendor's server if it covers your use case. It runs inside the account boundary and uses the vendor's own OAuth and grants. Self-host when you need custom tools, need to span several databases, or are on a warehouse with no managed server.

Is it safe to give an AI agent write access to a warehouse?

Not by default. Begin with read-only roles and a read-only SQL tool, then add writes behind human approval. The MCP specification recommends a human in the loop for tool invocations, and we run our open-source edition read-only until you turn writes on.

Does MCP replace my existing connectors and ETL tools?

No. MCP is a protocol for exposing tools to AI clients. Ingestion tools such as Fivetran and orchestrators still move and schedule data. MCP gives an agent a standard way to inspect and operate on what they produce.

Can Claude Code or Cursor connect to Data Workers?

Yes. Every Data Workers agent is an MCP server, so any MCP-compatible client, including Claude Code, Cursor, Windsurf and VS Code, can call it. Whether it is the right layer for you depends on whether you need cross-tool context or just a query tool.

How many tools should one MCP server expose?

Fewer than the limit. Snowflake caps a server at 50 tools and recommends exposing a single Cortex Agent as the client-facing tool for governed business questions. A small, well-described tool set usually helps the model choose correctly.