# Reported issues for OSS Snowflake MCP Server Pod holds 19 of 31 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user. Back to [OSS Snowflake MCP Server](/mcp/oss-snowflake-mcp-server). ## Most discussed ### ImportError: cannot import name 'FakeConnection' from 'fakeredis.aioredis' on startup When running `uvx snowflake-labs-mcp`, the server fails immediately after authenticating with: ``` ImportError: cannot import name 'FakeConnection' from 'fakeredis.aioredis' ``` Full traceback points to `docket/_redis.py` trying to import `FakeConnection` from `fakeredis.aioredis`, which no longer exists in the current version of `fakeredis`. **Environment:** - Installed via `uvx snowflake-labs-mcp` - FastMCP 2.14.6 - Python 3.11.14 on macOS aarch64 **Root cause:** `docket` depends on `faker [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/184) · 2026-04-09 · open · external user · 4 comments ### SQL statement parser misclassifies VARIANT colon syntax as "Unknown" statement type # Description The MCP server's SQL statement classifier fails to recognize Snowflake's semi-structured data colon notation (data:field), categorizing queries that use it as "Unknown" statement type. This causes them to be blocked by sql_statement_permissions even when SELECT statements are allowed. # Steps to Reproduce 1. Configure the MCP server with sql_statement_permissions that allows SELECT statements 2. Run a query using VARIANT colon syntax: `select data:a::int as a, data:b::varchar a [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/174) · 2026-03-12 · closed · external user · 2 comments ### Option to disable or specify SECONDARY_ROLES (Avoid inheriting all permissions) **Description of the issue** Currently, the Snowflake MCP server does not provide a way to handle SECONDARY_ROLES. In many modern Snowflake accounts, DEFAULT_SECONDARY_ROLES is set to 'ALL' by default for users. When connecting via the MCP server, even if a specific --role is provided, the session automatically inherits permissions from all other roles assigned to the user. This makes it impossible to strictly sandbox the LLM's access to a specific subset of data using a dedicated "MCP_ROLE" w [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/165) · 2026-02-03 · open · external user · 3 comments ### COPY statements incorrectly classified as "Unknown" instead of "Copy" ## Summary Snowflake COPY statements are misclassified as "Unknown" statement type, causing them to be rejected when `sql_statement_permissions` is configured with `Copy: true` and `Unknown: false`. ## Expected Behavior When executing a Snowflake COPY statement with `Copy: true` in permissions, the statement should be recognized as type "Copy" and allowed to execute. ## Actual Behavior The statement is classified as "Unknown" and rejected. Setting `Unknown: true` is required as a workaround [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/161) · 2025-12-23 · closed · external user · 4 comments ### Unrecognized option "--verbose" As per the readme, `--verbose` argument could be added for debug logging. however executing the latest version from Pypi, I receive an error: ``` snowflake-labs-mcp: error: unrecognized arguments: --verbose ``` Can you add guidance on how to enable verbose logging or change the log level to DEBUG? [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/155) · 2025-12-02 · closed · external user · 7 comments ### Snowflake MCP server fails to connect via `stdio` — `Invalid connection_name 'default', known ones are []` ### Bug: Snowflake MCP server fails to connect via `stdio` — `Invalid connection_name 'default', known ones are []` **Description** When starting the Snowflake MCP server with `stdio` transport, the server fails to establish a persistent connection and reports that the `connection_name` "`default`" is invalid, with no known connections loaded. **Steps to Reproduce** 1. Configure environment for Snowflake MCP (env vars and `tools_config.yaml` present locally). 2. Run the MCP server with `stdi [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/130) · 2025-10-14 · closed · external user · 9 comments ### MCP Agent name in claude chat ignores service name No matter what I name the service the agent name in the chat window still shows Cortex Agent or Cortex Analyst. I want the actual name of the agent from the configuration and also the option to hide the debug request and response in the chat window. It doesn’t look great in demos. Is there some configuration missing to enable this? [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/110) · 2025-09-24 · closed · external user · 3 comments ### Augment - Snowflake MCP | Accidentally disconnect and unable to restore I have been using an Augment and Snowflake MCP and it seems to be working as usual. However, once I accidentally closed my browser without fully authenticating the session and now I am unable to restore the connection I used `externalbrowser` as `authenticator`. I tried clearing cache, but no luck [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/85) · 2025-09-06 · closed · external user · 2 comments ## Most recent ### Consider exposing an HTTP /health endpoint for deployments behind load balancers / orchestrators ## What Add a simple HTTP `/health` endpoint to the server (alongside the MCP protocol endpoint). The handler probes Snowflake with a warehouse-engaging query and returns: - **HTTP 200** with `{"status": "healthy"}` when Snowflake is reachable and the account has a usable warehouse - **HTTP 503** with `{"status": "unhealthy", "snowflake": {"connected": false, "error": "..."}}` when the probe fails ## Why Three deployment scenarios benefit: 1. **Kubernetes readiness/liveness probes** — opera [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/191) · 2026-05-14 · open · external user · 0 comments ### send_initial_query doesn't verify compute availability — suspended/warehouseless accounts pass the connection check ## Summary `send_initial_query` (in `mcp_server_snowflake/server.py`, called during persistent connection creation) runs: ```python cur.execute("SELECT 'MCP Server Snowflake'").fetchone() ``` Snowflake's cloud-services layer answers string-constant SELECTs without engaging compute. A connection where the underlying account has no usable warehouse — suspended for non-payment, warehouse not granted to the role, warehouse paused with no auto-resume, etc. — will pass this check and the server wil [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/190) · 2026-05-14 · open · external user · 0 comments ### Extract SHOW command as a new sql_statement_permissions The current implementation categorizes the new `SHOW AGENT` syntax under the Command SQL statement type. This creates a security friction point because the Command type also encompasses high-risk DDL and DML operations like **DROP**, **DELETE**, and **UPDATE**. In production environments, users are often restricted from executing destructive commands, yet they still require the ability to describe or list resources (in this case **agent**s). We need to introduce a distinct sql_statement_permis [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/188) · 2026-05-05 · open · external user · 0 comments ### Dependency constraints on snowflake-connector-python<4.0.0 and fastmcp<3.0.0 block multiple security fixes Several security vulnerabilities in transitive dependencies cannot be patched because of version upper bounds in `snowflake-labs-mcp`. This issue tracks the full chain so it can be addressed in one go. --- ### Blocked vulnerabilities | CVE / Advisory | Package | Fix version | Severity | |---|---|---|---| | [GHSA-vv7q-7jx5-f767](https://github.com/PrefectHQ/fastmcp/security/advisories/GHSA-vv7q-7jx5-f767) | fastmcp | ≥ 3.2.0 | Critical — SSRF & Path Traversal | | [GHSA-rww4-4w9c-7733](https:// [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/187) · 2026-04-23 · open · external user · 0 comments ### SNOWFLAKE_PRIVATE_KEY / --private-key (PEM string in env/flag) does not work: PEM must be deserialized to DER bytes before passing to connector ### Problem The MCP server supports authentication/connection via: - `--private-key` CLI flag - `SNOWFLAKE_PRIVATE_KEY` environment variable **Documentation and CLI args suggest you can pass the PEM text (i.e. the output of `cat mykey.p8`).** However, tracing the usage in the code reveals that: - The raw PEM string (i.e. `-----BEGIN PRIVATE KEY-----...`) is passed straight into the `private_key` parameter of `snowflake.connector.connect()` - The Snowflake connector does NOT accept PEM strings [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/177) · 2026-03-20 · open · external user · 1 comment ### Authentication token expiry causes all tool calls to fail until server restart (no auto-reconnect on expired token) ### Problem When using key pair authentication (private key file), after several hours of inactivity the Snowflake MCP server's authentication token expires (error code 390114). When this happens, all subsequent tool calls fail with a fatal error: ``` 390114 (08001): Authentication token has expired. The user must authenticate again. ``` **Expected:** The server should detect a stale or expired authentication token in `get_connection()` and automatically attempt to re-establish a fresh connec [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/176) · 2026-03-20 · open · external user · 2 comments ### "Temporary error" when connecting from Claude to Cortext Analyst MCP Issue: Snowflake Managed MCP Server fails to connect from Claude.ai after successful OAuth Error Message: ============ Error connecting to the MCP server. Please confirm that you have permission to access the service, that you're using the correct credentials, and that your server handles auth correctly. (McpServerError: Connected successfully but the integration may not be available right now due to a temporary error.) If this persists, share this reference with support: "f21c5bd94f2d65ef" == [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/169) · 2026-02-20 · open · external user · 1 comment ### Semantic view tools bypass permission middleware; if/elif logic error in validators # Semantic view tools bypass permission middleware; if/elif logic error in validators Three related bugs in the SQL permission validation system: 1. `validate_semantic_view_tool` exists in `semantic_manager/tools.py` but is never imported or called from `CheckQueryType` middleware in `server_utils.py`. All semantic tools (`list_semantic_views`, `query_semantic_view`, etc.) bypass configured `sql_statement_permissions` entirely. 2. Both `validate_semantic_view_tool` and `validate_object_tool` [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/166) · 2026-02-09 · open · external user · 0 comments ### SSL issues with zScaler and mcp from claude desktop? We are running into not being able to allow this to run on premise in our offices but this runs when not in office and we use zscaler - we've tried to troubleshoot this with our security and ensuring we are running this with paths, but our python tests all show this should work on our network but does not. I've inclued our latest log file as well. [mcp-server-snowflake.log](https://github.com/user-attachments/files/24623285/mcp-server-snowflake.log) [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/164) · 2026-01-14 · closed · external user · 0 comments ### Pydantic V2 Deprecation Warnings in snowflake.core Generated Models The `snowflake.core` package contains auto-generated model files that use deprecated Pydantic V1-style class-based `config`, triggering numerous `PydanticDeprecatedSince20` warnings when imported: ``` PydanticDeprecatedSince20: Support for class-based `config` is deprecated, use ConfigDict instead. Deprecated in Pydantic V2.0 to be removed in V3.0. ``` **Affected Files:** - `snowflake/core/warehouse/_generated/models/warehouse.py` - `snowflake/core/user/_generated/models/*.py` - `snowflake/co [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/163) · 2026-01-07 · open · external user · 0 comments ### Support dynamic QUERY_TAG values from HTTP request headers ## Problem When deploying MCP server behind an authentication layer, user identity is available in request headers but cannot be passed to Snowflake's `QUERY_TAG`. All queries appear in `QUERY_HISTORY` with the same static tag, making it impossible to attribute queries to specific users. **Current behavior:** - Auth layer validates request → identifies user "alice" → sets header - MCP executes query with static tag: `{"origin": "sf_sit", "name": "mcp_server"}` - Query history shows no user att [Read the thread](https://github.com/Snowflake-Labs/mcp/issues/162) · 2025-12-23 · open · external user · 1 comment The remaining reports are on [the project's issue tracker](https://github.com/Snowflake-Labs/mcp/issues).