MCP field guide / Snowflake
// mcp field guide · data warehouse
Snowflake's data cloud, exposed to an agent through Cortex search/analytics and raw SQL. The good news: it has real built-in controls — the managed server is read-only by default, and the local one lets you allow/deny whole SQL statement types. The catch, as always with SQL: the same execution tool is a harmless SELECT or a DROP TABLE.
GUARD FIT · READ-ONLY / RESTRICTED
LOWManaged read_only=true (the default) or local perms limited to Select/Describe/Use + Cortex retrieval — no mutation to gate.
GUARD FIT · WRITE / DDL / DROP
STRONGOnce mutation is permitted, one SQL tool can DROP/TRUNCATE/DELETE — effectively irreversible outside Time Travel.
Overall fit: STRONG for write-enabled deployments; low when the built-in read-only controls are on.
Managed (current, GA) — Snowflake-hosted, running inside your account and governed by Snowflake RBAC; provisioned with CREATE MCP SERVER. Its SQL tool SYSTEM_EXECUTE_SQL takes a read_only parameter that defaults to true (SELECT-only), and access is layered: USAGE on the server is required but not sufficient — each tool needs its own grant.34 Local — snowflake-labs-mcp (Snowflake Labs, Apache-2.0, v1.4.2) is a self-hosted Python server that carries the per-statement permission system below — but it is now deprecated, with the README directing users to the managed server.1 Both surface Cortex Search (retrieval), Cortex Analyst (NL→SQL over semantic views), and Cortex Agent.
There's no fixed list of named tools — Cortex tools are generated per configured service, and SQL runs arbitrary statements. Risk is governed by the permission controls, not tool identity.
| Tier | What runs |
|---|---|
| read-only | Cortex Search & Analyst retrieval; semantic-view discovery/query; object list/describe; SQL limited to Select/Describe/Use |
| mutating | SQL Insert/Update/Merge/Copy/Create/Alter; object create/alter (database, schema, table, warehouse, role, user…) |
| destructive | SQL Drop/Delete/TruncateTable; object drop |
The key built-in control — sql_statement_permissions (local server). A config maps SQL statement types (Select, Insert, Update, Merge, Create, Alter, Drop, Delete, TruncateTable, Describe, Use, …) to allow/deny. A statement marked false is stopped before execution and never reaches Snowflake. A read-only posture sets Select/Describe/Use = true and the rest false. On the managed server, the equivalent is read_only (default true) plus RBAC.14 The generic SQL-executor tool's literal name is config-generated and UNVERIFIED here.
Conversational analytics. An agent answers business questions over governed semantic views via Cortex Analyst — read-only SELECTs.
RAG over enterprise docs. Cortex Search retrieves from unstructured corpora indexed in Snowflake to ground answers.
Agentic warehouse ops. With mutation enabled, an agent runs ETL/DDL — insert/create/alter, or destructive drop/truncate — the high-risk surface.
Read-only / restricted → low. Locked to Select/Describe/Use (local) or read_only=true (managed, the default) plus Cortex retrieval, there's no mutation to approve. Credit the built-in controls — they block whole statement classes outright.
Write-enabled → strong. The instant a deployment permits Insert/Update/Create/Alter/Drop/Delete/Truncate, each statement is a real mutation, and DROP/TRUNCATE/hard DELETE are effectively irreversible outside Snowflake's Time-Travel window.
Built-in control vs. guard — complementary, not redundant. Snowflake's sql_statement_permissions / read_only are coarse: they allow or deny a whole statement type, statically, at start. A guard adds the finer layer — per-instance human approval on the specific statement at call time: allow DELETE as a type, but require a person to approve this DELETE … WHERE after seeing its predicate and blast radius. Correct design: classify by statement content, treat SELECT/Describe as read, route Insert/Create/Alter → approve, and Drop/Delete/Truncate → approve-with-irreversibility-warning. Time Travel may allow a restore, but a guard must never assume it — that's the compensation-is-not-undo discipline.
ChronoMCP reads risk from the statement — layering per-call human approval on top of Snowflake's statement permissions.
Read the quickstart → More MCP profilessql_statement_permissions, deprecation notice): github.com/Snowflake-Labs/mcpsnowflake-labs-mcp (v1.4.2, Apache-2.0): pypi.org/project/snowflake-labs-mcpCREATE MCP SERVER reference (SYSTEM_EXECUTE_SQL read_only default true): docs.snowflake.com — create-mcp-serverProfiles describe third-party software from its public sources; ChronoMCP is not affiliated with Snowflake. Cortex/SQL tool names are config-generated and vary by deployment; risk groupings are our classification. Capabilities reflect sources current as of Aug 2026 (the local server is deprecated in favor of the managed one) — check the source links.