You could get the same guarantee from a Snowflake role with no write grants, and you should still do that — but roles get edited and reused, and a keyword filter in the server is a second lock that does not depend on someone else's decision. The narrowing on table names is the same instinct applied to injection. What you give up is anything that needs a temp table or a session setting, which is the honest price of the restriction.
A Snowflake client for assistants that only reads. The restriction is enforced in the server rather than left to the warehouse role: a list of SQL keywords is rejected outright, and table names are constrained to alphanumerics, underscores and dots. Connection details go in as a single JSON string on the command line.
- Read-only query access to a Snowflake database, warehouse, schema and role you specify
- A rejected-keyword list covering INSERT, UPDATE, DELETE, DROP, TRUNCATE, ALTER, CREATE, GRANT, REVOKE, COMMIT and ROLLBACK
- Table names restricted to alphanumeric characters, underscores and dots
- Docker and uvx launch paths, plus one-line installation through Smithery
Snowflake credentials passed as a `--connection` JSON string containing account, user, password, warehouse, database, schema and role. Run it with `uvx mcp-snowflake-reader` (package `mcp-snowflake-reader`, version 0.2.0) or the Docker image, or install it for Claude Desktop through the Smithery CLI. The connection string carries a password in your client config, so protect that file the way you would any credential store.
One command plus a key — npx -y @smithery/cli install @fnf-deepHeading/mcp-snowflake-reader --client claude, then supply credentials