MCP Server for Snowflake: 3 Options Compared

There are three realistic ways to run an MCP server for Snowflake today: the Snowflake Labs server (Cortex AI plus SQL and object admin), the community mcp-snowflake-server (read-safe SQL with schema discovery), and CentralMind Gateway (auto-generates its own API over your warehouse). All three run locally over stdio, which puts them in the same camp as roughly 90% of MCP servers. Below is which one to reach for, the trade-offs, and the exact config to paste into Claude Desktop or Cursor.

If you just want the short version: use mcp-snowflake-server for ad-hoc querying, the Snowflake Labs server if you already live in Cortex, and CentralMind Gateway if you want a curated, PII-filtered API instead of raw SQL access.

The three servers at a glance

Pick by what you actually want the agent to do — chat with Cortex, run raw SQL, or hit a controlled API. They are not interchangeable.

Server	Best for	Transport	Auth	Default write access	License
snowflake-labs-mcp-server	Cortex Search/Analyst + object admin	stdio (Docker/SSE optional)	Snowflake connector (password, key-pair, OAuth, SSO, MFA)	Gated by sql_statement_permissions	Apache-2.0
mcp-snowflake-server	Read-only SQL, schema discovery	stdio	password / key-pair / external browser	Off — needs --allow-write	GPL-3.0
centralmind-gateway	Curated API with PII redaction	stdio + SSE + REST/OpenAPI	connection string in gateway.yaml	Read-only by design	Apache-2.0

A note before you commit to the Labs option: the Snowflake-Labs/mcp repo is now marked deprecated and points to Snowflake's officially supported Cortex Agents MCP server. The PyPI package still installs and runs, but don't build a long-lived deployment on it. More on that below.

snowflake-labs-mcp-server: pick it if you use Cortex

Use the Snowflake Labs server when you want an agent to answer business questions over governed data, not just fire SQL. It bundles Cortex Search (RAG over unstructured data), Cortex Analyst (text-to-answer over semantic models), and Cortex Agent, plus an Object Manager, Query Manager, and Semantic Manager — six capability groups behind one server.

The part worth caring about is the sql_statement_permissions block in its service config. Because the Query Manager runs LLM-generated SQL, you can allow SELECT and deny DROP/DELETE explicitly. Do that. The Object Manager can create and drop databases, schemas, and warehouses, so a wide-open role plus a hallucinated DROP is a genuinely bad afternoon.

Minimal Claude Desktop / Cursor config:

{
  "mcpServers": {
    "snowflake": {
      "command": "uvx",
      "args": [
        "snowflake-labs-mcp",
        "--service-config-file", "/absolute/path/to/tools_config.yaml",
        "--connection-name", "default"
      ],
      "env": {
        "SNOWFLAKE_ACCOUNT": "<your-account-identifier>",
        "SNOWFLAKE_USER": "<your-user>",
        "SNOWFLAKE_PASSWORD": "<your-password-or-pat>"
      }
    }
  }
}

What to skip: don't enable every manager in tools_config.yaml on day one. Turn on Cortex Analyst or the Query Manager, confirm it works, then add the rest. Given the deprecation notice, treat this as the on-ramp to Snowflake's official Cortex server rather than a permanent fixture.

mcp-snowflake-server: the safe default for querying

Reach for mcp-snowflake-server when you want an agent to explore and read a warehouse without any risk of it mutating data. Reads (SELECT) are on by default; write_query and create_table only appear if you start the server with --allow-write. That single default makes it the least scary server to hand a production connection.

It ships eight tools: read_query, write_query, create_table, list_databases, list_schemas, list_tables, describe_table, and append_insight. The last one is the interesting one — append_insight accumulates findings into a live memo://insights resource, so the agent builds up an analysis log as it explores. You can also hide databases, schemas, or tables with exclusion patterns and drop individual tools with --exclude_tools.

Eight tools is a comfortable footprint. A typical client (Cursor, Claude) starts degrading somewhere around a ~40-tool budget, so this server leaves plenty of headroom to run alongside your GitHub and filesystem servers. Config:

{
  "mcpServers": {
    "snowflake": {
      "command": "uvx",
      "args": [
        "--python=3.12", "mcp_snowflake_server",
        "--account", "your_account",
        "--warehouse", "your_warehouse",
        "--user", "your_user",
        "--password", "your_password",
        "--role", "your_role",
        "--database", "your_database",
        "--schema", "your_schema"
      ]
    }
  }
}

Trade-off: it's a community project (GPL-3.0, unverified, ~183 stars) with no Cortex features. If you want AI-native retrieval over Snowflake, this isn't it. For "let the agent read my tables," it's the cleanest choice.

centralmind-gateway: an API, not raw SQL

Choose CentralMind Gateway when you'd rather expose a curated, PII-filtered API than hand an agent arbitrary SQL. It's a Go binary that runs a one-time discover stage — an LLM reads your schema and sample data and writes a gateway.yaml where each endpoint becomes an MCP method. Those generated methods are the tools; there is no fixed tool list.

That design is the whole pitch. Instead of read_query("SELECT ..."), the agent calls named, reviewable endpoints you've seen in the YAML. On top it adds PII detection and redaction (regex or Microsoft Presidio), row-level security via Lua scripts, and OpenTelemetry auditing. It also speaks SSE and REST/OpenAPI 3.1, not just stdio — useful when you outgrow a single local client (see local vs remote MCP).

{
  "mcpServers": {
    "snowflake": {
      "command": "PATH_TO_GATEWAY_BINARY",
      "args": ["start", "--config", "PATH_TO_GATEWAY_YAML_CONFIG", "mcp-stdio"]
    }
  }
}

Two caveats. The discover stage needs an AI provider key (OpenAI, Anthropic, Gemini, Bedrock, or Vertex) — a one-time cost, not per-query. And the README notes MCP-level API-key/OAuth auth is still on the roadmap, so the stdio server relies on the connection string in gateway.yaml rather than authenticating clients. It's Apache-2.0 and the most-starred of the three (~529), but it's still community-maintained.

How to actually wire one up

Same four steps for all three: install the runtime (uv/uvx for the Python servers, Docker or a built binary for Gateway), drop the JSON above into your client config, add credentials, and restart the client so it loads the server. For the full walkthrough with per-client paths, see how to add an MCP server, and generate a validated snippet with the config generator.

One rule that saves grief on all three: create a dedicated Snowflake role scoped to the exact warehouse, database, and schema the agent needs, and start read-only. You can always widen it. Compare these against other database options on the best MCP servers list or browse by capability if you need Postgres or BigQuery too.