Connecting a coding agent to a warehouse takes minutes. Connecting it safely takes three decisions: which identity the agent runs as, which tools it may call, and who patches the server. This guide compares the managed and self-hosted MCP options for Snowflake, Databricks, BigQuery, Fabric, Redshift, and ClickHouse, then walks through a working ClickHouse setup in Claude Code. Atlan’s context layer for AI agents sits above those servers, so an agent registers once and reaches governed definitions, lineage, and read-only SQL across every connected warehouse.
The setup takes five moves:
- Choose the server: Vendor-managed servers run in the vendor’s cloud. Self-hosted servers run on your machine or your infrastructure.
- Create an agent identity: Give the agent a dedicated warehouse user or role that holds only the permissions it needs.
- Authenticate: Use OAuth for hosted servers and environment variables or a secret store for local ones.
- Register the server: Add it to the harness config, in
.mcp.json,.vscode/mcp.json, or.cursor/mcp.json. - Scope and verify: Allow named tools only, then ask the agent to list databases and tables before any real query.
| What it is | A coding agent acting as the MCP client for a data warehouse’s MCP server, so it runs queries through governed tools and never holds a connection string |
| Two server types | Vendor-managed (hosted and patched by the vendor) and self-hosted (installed and patched by you) |
| Where permissions live | In the warehouse, on the agent’s identity, and in the agent, as tool-level allow and deny rules |
| Where it gets hard | Several warehouses and several harnesses, because each pairing needs its own server, identity, and tool list |
| What Atlan adds | One registration per harness, plus governed context and read-only SQL on Snowflake, Redshift, BigQuery, and Databricks connections |
Why does a warehouse MCP connection need more than credentials?
A connection string gets an agent into a database. It does not tell the agent which table is the certified revenue table, what “active customer” means in your business, or which columns it must never read. Text-to-SQL for enterprise data fails in exactly that gap, which is why the connection and the context are two separate jobs.
MCP handles the first job. The coding agent in Claude Code, Cursor, or GitHub Copilot becomes the client, and the warehouse’s MCP server exposes a short list of tools. The agent calls those tools and nothing else. That is the same pattern behind why MCP matters for AI agents: a governed, inspectable interface in place of a driver and a password.
According to the MCP specification (2025), the protocol defines two standard transports: stdio, where the client launches the server as a subprocess, and Streamable HTTP, where the server runs as an independent process. The same specification says authorization is optional, that HTTP-based servers should follow its OAuth-based flow, and that stdio servers should retrieve credentials from the environment instead. Those two rules explain most setup differences below: hosted servers ask you to sign in, local servers read environment variables.
That pattern works well for one warehouse. Large organizations rarely have one. Two questions follow: how do agents reach several data systems, and how do they get the right context at the right time? Giving AI agents access to enterprise data covers the second at length. First, the server options.
Which data warehouses offer MCP servers, and what do they expose?
Most major warehouse vendors now publish an MCP server. A vendor-managed server runs on the vendor’s infrastructure, and you connect to it over Streamable HTTP with OAuth. A self-hosted server runs locally or on your own cloud, and you install and patch it. Either way the agent sees only the tools the server lists.
Vendor-managed and self-hosted options by warehouse
| Warehouse | Vendor-managed | Self-hosted |
|---|---|---|
| Snowflake | Snowflake-managed MCP server, generally available since November 2025. Tool types cover Cortex Agent, Cortex Search, Cortex Analyst, and SQL execution. | The Snowflake Labs server is deprecated and no longer maintained. Its README points users to the Snowflake-managed server. |
| Databricks | Managed MCP servers, in Public Preview at the time of writing. The documented servers are Genie One, Genie Agent, AI Search, Databricks SQL, and Unity Catalog functions. | The Unity Catalog server in Databricks Labs is marked deprecated. The README recommends the managed servers instead. |
| BigQuery | BigQuery remote MCP server, with execute_sql, execute_sql_readonly, and tools to list and describe datasets and tables. |
MCP Toolbox for Databases is an open-source server whose sources include BigQuery, Snowflake, ClickHouse, and Trino. |
| Microsoft Fabric | Fabric Data Warehouse MCP server, a hosted endpoint that exposes one tool, executeSQL. |
The Fabric MCP Server runs locally and never connects to your Fabric environment. It supplies API specifications and best practices, not warehouse data. |
| Redshift | The AWS MCP Server, generally available since May 2026, lets agents invoke AWS APIs under your IAM credentials. | The AWS Labs Redshift MCP server handles cluster discovery, metadata exploration, and read-only SQL. |
| ClickHouse | ClickHouse Cloud remote MCP server, with 13 read-only tools for querying, schema exploration, services, backups, ClickPipes, and billing. | mcp-clickhouse, with three tools: run_query, list_databases, and list_tables. |
Three details in that table change how you plan. The Fabric self-hosted server is a documentation helper, so it cannot answer a data question. The Snowflake Labs and Databricks Labs servers are deprecated, so a tutorial that points at them is out of date. And the BigQuery server separates a read-only SQL tool from a general one, so you can allow the first and withhold the second.
Other platforms may publish servers of their own, so check the vendor’s documentation. The registration pattern stays the same. The Snowflake MCP server guide, the Databricks MCP server guide, and the guide to Fabric MCP servers go deeper on each vendor.
How do you register a warehouse MCP server in your coding agent?
Registration is a config entry plus an authentication step. Start with the choices that decide everything after: server type, agent harness, and identity. A harness is the runtime wrapped around the model, and what an agent harness is explains why the same model behaves differently in Claude Code than in Cursor. For a Databricks take on the harness idea, see what Databricks Omnigent is.
- Choose the MCP server. Managed and self-hosted servers usually expose different tools, as the table shows.
- Create an agent identity in the warehouse. Assign the minimum permissions the job needs, on a user or role used by nothing else.
- Set up authentication. Use OAuth for hosted servers. For local servers, pass credentials through environment variables or a secrets manager.
- Add the server to the agent’s MCP config. The file differs by harness, as the next table shows.
- Verify with a read-only prompt. Ask: “List all databases and their tables.”
| Harness | Config location | Notes |
|---|---|---|
| Claude Code | .mcp.json at the project root, or ~/.claude.json for user scope |
Claude Code supports ${VAR} expansion in .mcp.json and OAuth sign-in through /mcp. |
| VS Code with GitHub Copilot | .vscode/mcp.json |
The VS Code docs use a top-level servers object and recommend input variables for secrets. |
| Cursor | .cursor/mcp.json or ~/.cursor/mcp.json |
Cursor uses an mcpServers object and resolves ${env:NAME} in command, args, env, url, and headers. |
The harness comparison matters more than it looks. Cursor, Windsurf, and Claude Code each load MCP tools differently, and the Claude Code and Codex context gap shows what each one still lacks once the connection works. For the server side of the same job, the MCP server implementation guide and the guide to building MCP servers for enterprise data cover what vendors build underneath.
How do you set up a local ClickHouse MCP server in Claude Code?
The worked example uses ClickHouse because the self-hosted server is small and its defaults lean safe. Before you start, create a ClickHouse user for the agent with read-only grants, the same role-based access control discipline you would apply to a human analyst.
Install uv, then confirm the server starts:
uv run --with mcp-clickhouse mcp-clickhouse
According to the mcp-clickhouse README (2026), queries run in read-only mode by default through CLICKHOUSE_ALLOW_WRITE_ACCESS=false, the query timeout defaults to 30 seconds, and TLS and certificate verification default to on. Keep those defaults. The example below sets CLICKHOUSE_SECURE to false only because it targets a ClickHouse server on localhost over plain HTTP. For any server beyond your own machine, leave TLS on.
Register the server in a project-level .mcp.json. Claude Code launches it over stdio each time it starts, and ${CLICKHOUSE_PASSWORD} reads the password from your shell so the file holds no secret and is safe to commit:
{
"mcpServers": {
"clickhouse": {
"type": "stdio",
"command": "uv",
"args": ["run", "--with", "mcp-clickhouse",
"mcp-clickhouse"],
"env": {
"CLICKHOUSE_HOST": "localhost",
"CLICKHOUSE_PORT": "8123",
"CLICKHOUSE_USER": "mcp_agent",
"CLICKHOUSE_PASSWORD": "${CLICKHOUSE_PASSWORD}",
"CLICKHOUSE_SECURE": "false",
"CLICKHOUSE_ALLOW_WRITE_ACCESS": "false"
}
}
}
}
The claude mcp add command with --transport stdio and --env writes the same entry, and its --scope project option targets .mcp.json, according to the Claude Code MCP docs (2026). Project-scoped servers need your approval in an interactive session before they load.
Next, create a subagent that works only with this server. Claude Code reads user-level agents from ~/.claude/agents/ and project-level agents from .claude/agents/. Save this as ~/.claude/agents/clickhouse.md:
---
name: clickhouse
description: ClickHouse data engineer. Explores databases,
tables, and schemas and runs read-only SQL through the
clickhouse MCP server.
tools: mcp__clickhouse__list_databases, mcp__clickhouse__list_tables, mcp__clickhouse__run_query
model: inherit
---
Answer from the clickhouse MCP server only. Never attempt
writes. State the SQL you ran with every answer.
Permissions apply on both sides. ClickHouse enforces the grants on the mcp_agent user. Claude Code enforces its own rules on which MCP tools may run. Claude Code permission rules name MCP tools as mcp__<server>__<tool>, so this allow list in ~/.claude/settings.json approves exactly three tools and nothing else from the server:
{
"permissions": {
"allow": [
"mcp__clickhouse__list_databases",
"mcp__clickhouse__list_tables",
"mcp__clickhouse__run_query"
]
}
}
Test it with a prompt that cannot change data, such as “List every database and the tables inside each.” If the agent answers and shows the SQL, the connection, the identity, and the tool scope all work.
How do you scope a coding agent’s permissions on a warehouse?
Least privilege has two layers, and skipping either one leaves a gap. The warehouse layer decides what the agent’s identity can touch. The agent layer decides which tools the harness will call at all.
On the warehouse side, each vendor expresses this differently:
- Snowflake: The documentation says access to the MCP server does not give access to the tools, so each role needs explicit privileges on each tool and underlying object. It recommends OAuth over hardcoded tokens.
- Databricks: Managed servers take OAuth scopes per server. According to the Databricks managed MCP docs, Databricks SQL uses the
sqlscope and Genie One usesai-gateway. - BigQuery: The server uses OAuth 2.0 with IAM and requires the
roles/mcp.toolUserrole, per the BigQuery docs. Itsexecute_sql_readonlytool rejects DML and DDL. - Fabric: The server uses the signed-in user’s identity and respects Fabric permissions, and Microsoft’s security guidance is to require approval on
executeSQLcalls and start with read-only queries.
On the agent side, use tool-level allow and deny rules, as the ClickHouse example does. The wider design question, how identity follows an agent across systems, is the subject of AI agent identity and AI agent access control. If you want those controls enforced in one place rather than per server, context layer role-based access control shows how policy travels with the context. The enterprise AI agent guardrails checklist turns this into a review list.
Two habits catch most mistakes. Start every new server read-only and widen deliberately. And review the SQL the agent writes before approving write-capable tools, because AI agent tool use goes wrong most often at the point where a plausible query meets a permissive tool.
Where does the per-warehouse pattern stop scaling?
Each pairing of harness and warehouse needs a server entry, an identity, a tool allow list, and someone who tracks which servers are deprecated. Four harnesses and five warehouses make twenty pairings. Data teams keep adding agents and harnesses, so the mapping grows faster than anyone reviews it. That is agent sprawl applied to data access.
A gateway or registry helps with discovery and policy. An MCP gateway centralizes routing, and an MCP registry lists approved servers. Both leave a question open, and the MCP gateway versus single MCP server and MCP gateway versus context layer comparisons name it: a gateway routes calls, but it does not tell the agent what the data means.
A single question can also cross servers. A revenue query may need a Snowflake table, a dbt definition, and a Databricks lineage trace. The agent needs types of metadata it can read in one place: ownership, certification, definitions, and data lineage. That is context engineering work, and it is what AI-ready data means in practice.
How do you connect a coding agent to several warehouses through Atlan?
Atlan is the Context Layer for AI. It connects to 109 supported connectors across categories that include data warehouses, databases, BI tools, ETL tools, and orchestration, per the Atlan documentation (2026). Its MCP server lists Claude Code, Cursor, VS Code, Codex, Windsurf, Gemini CLI, ChatGPT, Databricks, Google ADK, n8n, and other clients. The Google ADK entry matters if your agents are built on that framework.
The agent registers Atlan’s MCP server once per harness. Atlan has already crawled the source systems, so the agent asks one server for context instead of holding a server entry per warehouse. Sign-in works through OAuth, where each person authenticates with their own Atlan account and tools run with that person’s permissions. API keys cover automation and service accounts. The guide to the Atlan MCP server and the piece on MCP-connected data catalogs cover the architecture.
According to the Atlan MCP tools reference (2026), the server exposes 39 tools in nine categories. They include search and discovery, lineage, asset metadata, business glossary, data domains, and data quality. The query_assets tool runs read-only SQL against a connected Snowflake, Redshift, BigQuery, or Databricks warehouse, rejects statements that modify data, returns up to 100 rows per call, and requires query permission on the connection.
The video above shows Cursor reading Atlan’s context through the MCP server. The agent works from governed definitions and lineage, then queries the warehouse. Both halves matter: MCP for data lineage lets the agent trace where a number came from, and a semantic layer for AI agents fixes what the metric means. Together they are the enterprise context layer that sits between the agent and the warehouse. Agent skills and MCP compares the two ways to package that knowledge for a harness.
Where does each approach fit?
Use the warehouse’s own MCP server when the agent needs something only that vendor exposes: Snowflake’s Cortex Analyst tool, Databricks’s Genie One, or a write path. The Cortex Analyst versus text-to-SQL and Genie One pages explain what those tools do.
Use Atlan’s MCP server when the agent needs discovery, definitions, lineage, policy context, and read-only SQL across several warehouses. It runs query_assets on four warehouses today, so a ClickHouse query, or any statement that changes data, still goes through that warehouse’s own server. Teams on Google Cloud can see how that split plays out in Knowledge Catalog versus a neutral catalog for BigQuery, and teams on AWS in Amazon Bedrock Knowledge Bases versus an external data catalog.
Most teams end up running both: Atlan for context and read paths, vendor servers for vendor-specific and write paths. Which warehouse deserves its own direct server entry first is a question your own query logs answer better than any guide.
FAQs about connecting an AI coding agent to a data warehouse with MCP
1. How do you connect a coding agent to a data warehouse using MCP?
The coding agent becomes the MCP client for the warehouse’s MCP server. For a hosted server, you add its URL to the agent’s MCP config and sign in with OAuth. For a local server, you add a launch command and pass credentials through environment variables. Then you verify with a read-only prompt that lists databases and tables.
2. What is the difference between vendor-managed and self-hosted MCP servers?
A vendor-managed server runs in the vendor’s cloud, and the vendor patches it. A self-hosted server runs on your machine or infrastructure, and you install and patch it. Some warehouses offer both. Others deprecate their self-hosted server and point users to the managed one.
3. What permission controls restrict an AI agent’s access to data?
Controls exist at two levels. At the warehouse level, you assign roles, grants, or OAuth scopes to the agent’s dedicated identity, and some servers offer read-only tools or modes. At the agent level, the harness applies tool-level allow and deny rules, so the agent can call only the tools you name.
4. Can one Atlan connection reach multiple warehouses?
Yes. The agent registers Atlan’s MCP server once per harness, and Atlan serves context from every connected source. Read-only SQL through the query_assets tool covers Snowflake, Redshift, BigQuery, and Databricks connections. The caller needs query permission on each connection.
5. When should you still use the warehouse’s own MCP server?
Use it for tools only that vendor exposes, such as Snowflake Cortex Analyst or Databricks Genie One. Use it too for SQL on a warehouse that Atlan’s query_assets tool does not cover, such as ClickHouse, and for any statement that modifies data. Atlan supplies discovery, definitions, lineage, and policy context alongside.
Sources
- Specification: Transports, Model Context Protocol, 2025. https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
- Specification: Authorization, Model Context Protocol, 2025. https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
- Snowflake-managed MCP server, Snowflake Documentation. https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp
- Snowflake-managed MCP server (General availability), Snowflake Release Notes, 2025. https://docs.snowflake.com/en/release-notes/2025/other/2025-11-04-cortex-agents-mcp
- Snowflake-Labs/mcp (deprecated), GitHub. https://github.com/Snowflake-Labs/mcp
- Databricks managed MCP servers, Databricks Documentation. https://docs.databricks.com/aws/en/generative-ai/mcp/managed-mcp
- databrickslabs/mcp, GitHub. https://github.com/databrickslabs/mcp
- Use the BigQuery remote MCP server, Google Cloud Documentation. https://docs.cloud.google.com/bigquery/docs/use-bigquery-mcp
- googleapis/genai-toolbox (MCP Toolbox for Databases), GitHub. https://github.com/googleapis/genai-toolbox
- Connect to Fabric Data Warehouse MCP Server, Microsoft Learn. https://learn.microsoft.com/en-us/fabric/data-warehouse/data-warehouse-mcp-server
- Fabric MCP Server README, microsoft/mcp, GitHub. https://github.com/microsoft/mcp/blob/main/servers/Fabric.Mcp.Server/README.md
- The AWS MCP Server is now generally available, AWS What’s New, 2026. https://aws.amazon.com/about-aws/whats-new/2026/05/aws-mcp-server/
- AWS MCP Server, AWS Documentation. https://docs.aws.amazon.com/agent-toolkit/latest/userguide/mcp-server.html
- Amazon Redshift MCP Server, AWS Labs MCP Servers. https://awslabs.github.io/mcp/servers/redshift-mcp-server
- Remote MCP in Cloud, ClickHouse Docs. https://clickhouse.com/docs/products/cloud/features/ai-ml/remote-mcp
- ClickHouse/mcp-clickhouse, GitHub. https://github.com/ClickHouse/mcp-clickhouse
- Connect Claude Code to tools via MCP, Claude Code Docs. https://code.claude.com/docs/en/mcp
- Configure permissions, Claude Code Docs. https://code.claude.com/docs/en/permissions
- Create custom subagents, Claude Code Docs. https://code.claude.com/docs/en/sub-agents
- Add and manage MCP servers in VS Code, Visual Studio Code Docs. https://code.visualstudio.com/docs/copilot/customization/mcp-servers
- Model Context Protocol (MCP), Cursor Docs. https://cursor.com/docs/mcp
- Atlan MCP server overview, Atlan Documentation. https://docs.atlan.com/product/capabilities/atlan-ai/how-tos/remote-mcp-overview
- Atlan MCP tools, Atlan Documentation. https://docs.atlan.com/product/capabilities/atlan-ai/references/mcp-tools
- Connectors and capabilities, Atlan Documentation. https://docs.atlan.com/product/connections/references/connectors-and-capabilities
- uv installation, Astral Documentation. https://docs.astral.sh/uv/getting-started/installation/
- Watch a Contact Center Agent Bootstrap Itself: Cursor + Atlan MCP, Atlan on YouTube, 2026. https://www.youtube.com/watch?v=Wv99JChZ3JM
