Loading ToolBench
MCP server for Snowflake that enables seamless integration with Snowflake's Cortex AI services, semantic views, and object management capabilities
The Snowflake MCP server demonstrates good structural quality with 15 tools that are clearly named, mostly well-described, and have complete input schemas. Tool names follow verb-noun conventions (cortex_agent, cortex_search, create_object, drop_object, list_objects, run_snowflake_query, describe_semantic_view). Descriptions are substantive and context-rich. Input schemas use proper JSON Schema with type definitions and descriptions for all parameters. However, there are notable gaps: (1) output schemas are not documented in the source, responses are not formally specified, making it difficult for LLMs to plan downstream calls; (2) error handling guidance is minimal, tools do not consistently guide recovery actions; (3) some parameter descriptions lack format/range specifications (e.g., 'object_type' accepts a free-form string with an informal constraint list); (4) tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent despite the Risk field being populated in the specification. Per-tool assessment shows strong naming and description quality across the board, solid schemas with minor gaps in output documentation, and missed opportunities for safety annotations.
Cortex Agent tool that combines structured and unstructured data querying and may include additional custom tools in a configured Cortex Agent object in Snowflake. Each service service can be identified by its database_name, schema_name, and service_name. The user's query string is passed to the agent service as the query parameter. Available agent services include: {agent_services}
Analyst tool that performs natural language to SQL conversion against a configured Cortex Analyst service using Snowflake's REST API. Supports semantic model or semantic view. Each service service can be identified by its service_name and semantic_model. The value of the semantic_model should be a fully-qualified path to a YAML semantic file or Snowflake Semantic View. For example, "@my_db.my_schema.my_stage/my_semantic_file.yaml" or "MY_DB.MY_SCH.MY_SEMANTIC_VIEW". The user's query string is passed to the analyst service as the query parameter. Available analyst services include: {analyst_services}
Search tool that performs semantic search against a configured Cortex Search service using Snowflake's REST API. Supports filtering, column selection, and limit for refined search results. Each service service can be identified by its database_name, schema_name, and service_name. Columns and filters are optional. The user's query string is passed to the search service as the query parameter. Available search services include: {search_services}
Output schemas are not documented. The source code defines input schemas clearly but does not specify the structure of tool responses. LLMs cannot plan downstream tool calls or extract relevant fields without knowing what each tool returns. This violates pattern:tool and pattern:response-shaper.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are missing despite Risk classification being defined. Tools marked DESTRUCTIVE (drop_object) or WRITE (create_object, create_or_alter_object, run_snowflake_query) should include explicit safety annotations to guide agent behavior and indicate whether operations are reversible. This is critical for preventing accidental destructive actions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 76 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Create a Snowflake object (database, schema, table, view, warehouse, compute pool, role, stage, user, or image repository)
Create or alter a Snowflake object (database, schema, table, view, warehouse, compute pool, role, stage, user, or image repository)
Describe a Snowflake object and return its properties (database, schema, table, view, warehouse, compute pool, role, stage, user, or image repository)
Describe a semantic view and return its structure including dimensions, metrics, and facts.
Drop a Snowflake object (database, schema, table, view, warehouse, compute pool, role, stage, user, or image repository)
Get the DDL statement for a semantic view.
List Snowflake objects (databases, schemas, tables, views, warehouses, compute pools, roles, stages, users, or image repositories) filtered by database, schema, and pattern matching
List all semantic views in the account, database, or schema.
Query a semantic view with support for dimensions, metrics, facts, filtering, ordering, and limiting results.
Execute a SQL query against Snowflake and return all results. Supports SELECT, DML, and DDL statements based on configured permissions.
Show semantic dimensions for semantic views or the entire account.
Show semantic metrics for semantic views or the entire account.
Parameter 'object_type' in create_object, drop_object, create_or_alter_object, and describe_object is defined as a free-form string with an informal constraint list in the description. Should be an enum: ['database', 'schema', 'table', 'view', 'warehouse', 'compute_pool', 'role', 'stage', 'user', 'image_repository']. Enums are machine-parseable and prevent LLM hallucination of invalid values.
Error handling lacks recovery guidance. The cortex_services/tools.py code raises SnowflakeException with generic messages ('Request timed out', 'Invalid input') but does not guide the LLM on what to do next (retry, ask user, check constraints). Error responses should follow pattern:recovery-guide.
create_object and create_or_alter_object accept a free-form 'target_object' parameter of type object without specifying its structure. Documentation says 'Always pass properties of target_object as an object, not a string' but does not define what properties are required or valid for each object_type. This forces LLMs to guess the correct structure.
No rate limiting, timeouts, or retry guidance documented. The cortex_agent tool has a 120s timeout and cortex_search has 60s, but these are hardcoded and not documented in descriptions. If a timeout occurs, the LLM has no guidance on whether to retry or escalate.
query_semantic_view 'dimensions', 'metrics', and 'facts' parameters are arrays of objects but their internal structure is not documented. What fields should each object contain? Without this specification, LLMs cannot construct valid payloads.
run_snowflake_query accepts any SQL statement but does not document which DDL/DML operations are actually permitted based on configured permissions. Description mentions 'Supports SELECT, DML, and DDL statements based on configured permissions' but does not explain what 'configured permissions' means or how to determine what is allowed.
list_objects 'like' and 'starts_with' parameters are alternatives but this is not documented. It is unclear to the LLM whether both can be specified, or if one takes precedence. Dependencies between parameters should be explicit.