Labsco
MCP SERVER

MCP Snowflake Server NSP

by nsphung

Snowflake for AI assistants with write disabled by default, six ways to authenticate, and a TOML file for prod, staging and dev.

Relational SQL Databases
Summary
Built for having more than one Snowflake.

The single connection string is where most database servers stop, and it is also where the accidents happen. Here the TOML file gives each environment its own profile with its own role and authenticator, so pointing a client at production is a deliberate choice of profile name rather than an edited string. Combined with writes being absent unless enabled, and exclusion patterns hiding whole databases from discovery, this is a server you can hand to an assistant without holding your breath.

What it is

A Snowflake MCP server — SQL queries, schema exploration and data insights from an LLM client. It is a fork of `isaacwasserman/mcp-snowflake-server` whose additions are aimed at running it against more than one environment safely: multiple authentication methods, a multi-connection TOML config, and a write guard that is off unless you turn it on.

What you get
  • Query tools split by risk: `read_query` for `SELECT`, and `write_query` for `INSERT`, `UPDATE` and `DELETE` plus `create_table` for `CREATE TABLE` — both of which require `--allow_write` and are simply absent otherwise
  • Schema exploration — `list_databases`, `list_schemas`, `list_tables`, and `describe_table` returning column name, type, nullability, default and comment for a `database.schema.table`
  • `append_insight`, which adds a finding to a running memo exposed as the `memo://insights` resource
  • Prefetch mode, which pre-loads table schemas as `context://table/{table_name}` resources instead of leaving them to be fetched on demand — it disables `list_tables` and `describe_table` in exchange
  • Six authentication paths: password, key-pair with RSA or ECDSA keys, external browser, OAuth 2.0 client credentials, a pre-fetched OAuth bearer token, and a TOML connection file
  • A TOML connections file holding several named environments — production, development, reporting, an OAuth profile — each with its own account, warehouse, database, role and authenticator, selected by name at launch
  • Exclusion patterns in a runtime config file that filter databases, schemas or tables out of every discovery tool, matched case-insensitively as substrings
  • `--exclude_tools` to disable named tools outright, and `--exclude-json-results` to omit embedded JSON resources from responses and cut context use
Requirements

A Snowflake account plus credentials in whichever form you chose — every connection parameter is available both as a CLI flag and as a `SNOWFLAKE_<PARAM>` environment variable, and `SNOWFLAKE_DATABASE` and `SNOWFLAKE_SCHEMA` are required. The recommended path is a TOML connections file, passed with `--connections-file` and a profile named by `--connection-name`; both flags are required together. Run it with `uvx --python=3.13 --from mcp-snowflake-server-nsp mcp_snowflake_server`, or from the published Docker image `nsphung/mcp-snowflake-server-nsp` — with `docker run`, `-i` is required to keep stdin open for the stdio transport and `-d` must not be used. The image is hardened: nonroot user, no shell in the runtime. Writes stay off until `--allow_write` is passed. MIT licensed.

Setup effort

One command plus a key — uvx --python=3.13 --from mcp-snowflake-server-nsp mcp_snowflake_server --connections-file ~/snowflake_connections.toml --connection-name myconn, then supply credentials