Snowflake MCP Server: Connect Claude to Your Warehouse

⏱️ 3 min read 🔌 MCP Server

What it is: Snowflake's official MCP server from Snowflake-Labs, which exposes warehouse object discovery, SQL execution with statement-type permissions, and Cortex services (Search and Analyst) to any MCP client. Community alternatives (like isaacwasserman/mcp-snowflake-server) offer a simpler query-only surface. Either way, Claude gets governed access to the same tables your BI stack uses.

Quick answer: Install Snowflake's official MCP server (uvx snowflake-labs-mcp), authenticate with a programmatic access token or key pair for a least-privilege role, and allow only SELECT-type statements in its config. Your agent can then discover schemas and answer questions in SQL against live warehouse data.

Why it matters for data work

The warehouse is where the questions are — but pasting schemas into a chat window doesn't scale to hundreds of tables. Through MCP the agent lists databases, inspects columns, and writes its own SQL, and the official server's SQL permissions config lets you decide exactly which statement types (select, show, describe…) are allowed. Teams already invested in Cortex get Search and Analyst as agent tools from the same server.

Install & configure

For Claude Code, with a service config file defining connection and permitted statement types:

claude mcp add snowflake \
  -e SNOWFLAKE_ACCOUNT=myorg-myaccount \
  -e SNOWFLAKE_USER=CLAUDE_RO \
  -e SNOWFLAKE_PAT=your_token \
  -- uvx snowflake-labs-mcp --service-config-file config.yaml

Claude Desktop (claude_desktop_config.json) and Cursor (.cursor/mcp.json) use the same JSON shape:

{
  "mcpServers": {
    "snowflake": {
      "command": "uvx",
      "args": ["snowflake-labs-mcp", "--service-config-file", "/path/config.yaml"],
      "env": {
        "SNOWFLAKE_ACCOUNT": "myorg-myaccount",
        "SNOWFLAKE_USER": "CLAUDE_RO",
        "SNOWFLAKE_PAT": "your_token"
      }
    }
  }
}

How should I handle auth and permissions?

Create a dedicated user with a read-only role and authenticate with a programmatic access token (PAT) or key pair — not your personal password. The role is the real security boundary: grant USAGE on the relevant database/schemas and SELECT on the tables, nothing else. In the server's config, disable non-SELECT statement types so even a confused agent can't attempt DDL.

Will an AI agent run up my Snowflake bill?

It can, the same way a curious analyst can — every query resumes a warehouse. Point the MCP role at an XSMALL warehouse with AUTO_SUSPEND = 60, set a resource monitor with a credit quota on it, and the worst case becomes a few cents of exploration rather than a surprise invoice. This also keeps agent queries from queueing behind production workloads.

Troubleshooting

Account identifier errors: use the org-account format (visible in the Snowsight account menu), not the legacy locator URL.
Token authentication fails: PATs require the user's network policy to allow your IP; check the token hasn't expired.
Agent sees no tables: the role lacks USAGE on the database or schema — grants on tables alone aren't enough.
Queries hang: the warehouse is suspended and the role lacks OPERATE to resume it, or a resource monitor already hit its quota.

Author & links

Author: Snowflake-Labs (official), plus community implementations

Repo: github.com/Snowflake-Labs/mcp

License: Apache-2.0

Related skills

Also see the BigQuery MCP server for the GCP equivalent, the Postgres MCP server for operational databases, and the DuckDB MCP server for local-file analytics. Background on the platform itself: Snowflake review.

← Back to MCP Servers