MCP server for interacting with Snowflake databases
The Snowflake MCP server has three tools with minimal viable definitions but significant quality gaps. Tool names are verb-based (query, execute, export_to_csv), which is positive. However, descriptions are extremely brief (18-49 chars), far below the 194 char baseline for A+ tools. No output schemas are documented. Error handling is absent from tool definitions, no recovery guidance, categorization, or actionable error messages. The server lacks idempotency documentation, rate limiting, and permission gates for destructive operations (execute, export). With only basic schema structure and no descriptions for parameters, this server lands firmly in the F-D range.
Execute a SQL statement (INSERT, UPDATE, DELETE, etc.) against Snowflake
Export query results to a CSV file
Execute a SQL query against Snowflake and return results
All three tools lack parameter descriptions. Input schema defines 'query' and 'statement' types but provides no guidance on format, constraints, or expected values.
No output schemas documented for any tool. LLMs cannot plan downstream operations or extract result fields. 'query' likely returns rows but structure is undefined. 'export_to_csv' returns filename but schema is not declared.
Tool descriptions are 18-49 characters, well below 194 char baseline. 'Execute a SQL query against Snowflake and return results' (57 chars) does not answer WHEN to use query vs execute, or what prerequisite Snowflake configuration is needed. Too terse for LLM selection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
export_to_csv accepts 'filename' parameter with no path sanitization. Source code creates files in EXPORT_BASE_PATH via os.makedirs() but tool definition provides no constraints or examples. An LLM could pass '../../../etc/passwd' or other path traversal payloads. No description of allowed filename format or restrictions.
execute tool modifies state (INSERT, UPDATE, DELETE) but lacks destructive operation safeguards. No dry-run, confirmation step, or idempotency documentation. Source code does not show rollback capability. Per pattern:command-tool, destructive tools must declare this and offer confirmation.
No error handling documented in tool definitions. Agents cannot distinguish between retryable errors (connection timeout), user-fixable (invalid SQL syntax), or fatal (permission denied). Source code logs errors but tool definitions provide no recovery guidance.
No pagination or result limits documented for 'query' tool. If a SELECT returns 10,000+ rows, schema is unknown and no limit is stated.
Tool definitions do not specify required permissions (read:database, write:database, delete:database). No permission gate enforcement visible in schema. Per pattern:scope-declaration, tools must declare what they require for least-privilege agent configs and audit trails.