snowflake-labs-mcp
MCPMCP server for Snowflake
Dimension scores
Compatibility
| Framework | Status | Notes |
|---|---|---|
| Claude Code | ✓ | — |
| OpenAI Agents SDK | ~ | Complex nested Pydantic models (SnowflakeTableColumn, SnowflakeViewColumn) may not translate cleanly to OpenAI function schemas, Union types in create_object mode parameter may need explicit handling |
| LangChain | ✓ | Middleware-based SQL validation may need custom wrapping for LangChain execution |
Security findings
SQL injection vulnerability in list_objects function
In object_manager/tools.py lines 204-208, user input 'starts_with' is manually sanitized with only single-quote replacement, then directly interpolated into SQL: `statement += f" STARTS WITH '{sanitized_starts_with}'"`. This is insufficient - attackers can use backslashes or other SQL metacharacters to bypass the filter. The code even acknowledges bind variables aren't supported but proceeds with unsafe string formatting.
Arbitrary SQL execution without proper authorization
The run_query function in query_manager/tools.py executes any SQL statement passed to it. While there's middleware checking statement types (server_utils.py), the validation uses sqlglot parsing which can be bypassed with malformed SQL or comments. If parsing fails, it returns 'Unknown' which can be allowed via config. An attacker could craft SQL that parses incorrectly but still executes.
Path traversal vulnerability in file operations
In environment.py, the get_spcs_container_token() function reads from Path('/snowflake/session/token') but doesn't validate the path. While this specific path is hardcoded, the pattern suggests insufficient path validation elsewhere. Additionally, service configuration files are loaded from user-specified paths without validation against traversal attacks.
Secrets potentially logged in error messages
In utils.py (not provided but referenced), SnowflakeException is raised with raw error messages from APIs and SQL execution. In cortex_services/tools.py lines 82-86, response.text is directly included in exceptions, which may contain sensitive data. In query_manager/tools.py, raw exception messages are propagated.
Weak input validation on object creation
In object_manager/objects.py, the ObjectMetadata.parse_json_string validator accepts arbitrary JSON strings and parses them without schema validation first. An attacker could craft malicious JSON payloads that exploit deserialization vulnerabilities or pass unexpected data types to downstream operations.
Missing length limits on string inputs
Insufficient validation of database/schema/table names
Error messages expose internal implementation details
Reliability
Success rate
72%
Calls made
100
Avg latency
850ms
P95 latency
2500ms
Failure modes
- • Timeout failures on Cortex Agent/Analyst REST API calls (120s timeout) - no retry logic
- • Network errors from requests.post() only caught at top level - intermediate layers may crash
- • Snowflake connection failures raise generic exceptions without structured error responses
- • SQL validation edge cases: sqlglot.parse_one() can throw ParseError mapped to 'Unknown' type, creating ambiguous allow/disallow logic
- • Missing parameter validation in many tools - None/empty string inputs not validated before API calls
- • Unicode/special characters in SQL strings may bypass sqlglot parser leading to incorrect statement type classification
- • Filter query validation missing for Cortex Search - malformed JSON in filter_query passes through unchecked
- • No connection pooling or rate limiting - concurrent requests may exhaust resources
- • Service configuration file errors only caught at initialization - runtime changes require restart
- • SPCS token file read has bare exception handler that re-raises - no graceful degradation
Code health
License
Apache-2.0
Has tests
Yes
Has CI
Yes
Dependencies
335522
Active Snowflake Labs project with good code health signals. Strong points: Apache-2.0 license, comprehensive README (29KB), test suite present, pre-commit hooks configured (.pre-commit-config.yaml), type hints via Pydantic models, linting via ruff.toml, published to PyPI as 'snowflake-labs-mcp' v1.3.5, Docker support. The uv.lock file (335KB) indicates modern Python dependency management. Code shows professional structure with proper error handling, middleware, and service abstractions. Areas for improvement: no visible CHANGELOG, cannot verify CI/CD status from provided files (though .pre-commit-config.yaml suggests automation), test coverage metrics not visible, and static analysis cannot determine repository activity metrics. The codebase demonstrates enterprise-grade practices typical of Snowflake's engineering standards.