There is no schema-discovery layer here and no allowlist of statements: what the assistant writes is what runs. That makes the database user you put in SNOWFLAKE_USER the real permission boundary, which is also the simplest one to reason about — grant read-only and the blast radius is a slow query.
A Python server that holds one Snowflake connection and executes the SQL an assistant sends it, returning results or the error.
- SQL executed against your Snowflake database and the results handed back
- The connection opened on the first query rather than at startup, so bad credentials surface with a clear error
- Connection state tracked, timeouts handled, and a dropped connection reconnected automatically
- Connections closed and resources released when the server stops
A .env file with SNOWFLAKE_USER, SNOWFLAKE_PASSWORD, SNOWFLAKE_ACCOUNT, SNOWFLAKE_DATABASE and SNOWFLAKE_WAREHOUSE. The client launches server.py with your Python interpreter, both as absolute paths. Access is bounded by the Snowflake user you configure — the author's own note is that a read-only user is the right choice if you only need to read.
One command plus a key — npx -y @smithery/cli install @datawiz168/mcp-service-snowflake --client claude, then supply credentials