Snowflake MCP Server

About

Snowflake ships a first-party, Snowflake-managed MCP server that is Generally Available and needs no infrastructure of your own: you create it as a database object with CREATE MCP SERVER ... FROM SPECIFICATION, and clients reach it over Streamable HTTP at https://<account_url>/api/v2/databases/{database}/schemas/{schema}/mcp-servers/{name}. The specification YAML lists the tools the server exposes, drawn from five types — CORTEX_AGENT_RUN (a Cortex Agent, the configuration Snowflake recommends for governed business questions), CORTEX_ANALYST_MESSAGE (text-to-SQL over a semantic view), CORTEX_SEARCH_SERVICE_QUERY (unstructured retrieval), SYSTEM_EXECUTE_SQL (query execution, read_only by default), and GENERIC (any UDF or stored procedure, exposed with its signature as the input schema). Because the server is an object in a schema, access is ordinary Snowflake RBAC: USAGE on the MCP server lets a client discover tools, and each underlying agent, search service, semantic view, function or procedure needs its own grant before that tool can actually be invoked. Authentication is Snowflake OAuth by default, with External OAuth available to bind the server to Okta or Entra ID; dynamic client registration is not supported. The server implements MCP revision 2025-11-25, supports tools only — no resources, prompts, roots or sampling — is non-streaming, and caps each server at 50 tools. The older community server at Snowflake-Labs/mcp (snowflake-labs-mcp on PyPI, last released 1.4.2 in May 2026) is now explicitly deprecated in favour of the managed server; isaacwasserman/mcp-snowflake-server remains as an unaffiliated self-hosted read/write SQL alternative.

Installation

https://<account_url>/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<name>

Creating and connecting a Snowflake-managed MCP server

1. 1.Create the MCP server object in a database and schema

   The server is created with CREATE MCP SERVER and a specification YAML that lists its tools. For governed business questions Snowflake recommends exposing exactly one Cortex Agent and letting the agent orchestrate its own Analyst, Search and custom tools — the client then has one interface to choose from and the semantic layer stays in the loop.

   sql

   CREATE OR REPLACE MCP SERVER <database_name>.<schema_name>.<server_name>
   FROM SPECIFICATION $$
   tools:
     - title: "Governed business data agent"
       name: "business_data_agent"
       type: "CORTEX_AGENT_RUN"
       identifier: "<database_name>.<schema_name>.<agent_name>"
       description: "Use this agent for governed business data questions."
   $$;

2. 2.Add the other tool types only if you actually want the client choosing between them

   Five types are supported: CORTEX_AGENT_RUN, CORTEX_ANALYST_MESSAGE (semantic views only — the managed server does not support semantic models), CORTEX_SEARCH_SERVICE_QUERY, SYSTEM_EXECUTE_SQL and GENERIC for a UDF or stored procedure. SYSTEM_EXECUTE_SQL takes read_only (default true), query_timeout and warehouse in its config block. Snowflake warns explicitly against putting SYSTEM_EXECUTE_SQL on the same server as an agent: direct SQL lets the client route around the agent’s semantic views and verified queries. If you need both, make it a second MCP server with its own least-privileged role.

   specification yaml

   tools:
     - title: "SQL Execution Tool"
       name: "sql_exec_tool"
       type: "SYSTEM_EXECUTE_SQL"
       description: "A tool to execute SQL queries against the connected Snowflake database."
       config:
         read_only: true
         query_timeout: 600
         warehouse: "<warehouse_name>"

3. 3.Grant the access role — twice over

   This is the step that produces the most "the tool is listed but it will not run" reports. USAGE on the MCP SERVER only lets a client connect and discover tools. Every tool needs a second grant on the object behind it: USAGE on the Cortex Agent, USAGE on a Cortex Search service, SELECT on a semantic view, USAGE on a function or procedure. Access to the server is not access to the tools.

   sql

   CREATE ROLE <mcp_access_role>;
   GRANT DATABASE ROLE SNOWFLAKE.CORTEX_AGENT_USER TO ROLE <mcp_access_role>;
   GRANT USAGE ON WAREHOUSE <warehouse_name> TO ROLE <mcp_access_role>;
   GRANT USAGE ON DATABASE <database_name> TO ROLE <mcp_access_role>;
   GRANT USAGE ON SCHEMA <database_name>.<schema_name> TO ROLE <mcp_access_role>;
   GRANT USAGE ON MCP SERVER <database_name>.<schema_name>.<server_name> TO ROLE <mcp_access_role>;
   GRANT USAGE ON AGENT <database_name>.<schema_name>.<agent_name> TO ROLE <mcp_access_role>;
   GRANT ROLE <mcp_access_role> TO USER <username>;

4. 4.Create the OAuth security integration

   One integration can serve every user in the account and every MCP server in it — each user still authenticates individually, but the client id and secret are shared. Set OAUTH_REDIRECT_URI to the exact callback the client shows you, keep OAUTH_USE_SECONDARY_ROLES = NONE, and restrict ALLOWED_ROLES_LIST to the MCP access role. If the client registers more than one callback — VS Code does — add the rest with OAUTH_ALTERNATE_REDIRECT_URIS. To authenticate against Okta or Entra ID instead, set OAUTH_AUTHORIZATION_SERVER to bind the server to an External OAuth integration. Dynamic client registration is not supported, so you will always be pasting a client id and secret.

   sql

   CREATE OR REPLACE SECURITY INTEGRATION <integration_name>
     TYPE = OAUTH
     OAUTH_CLIENT = CUSTOM
     ENABLED = TRUE
     OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
     OAUTH_REDIRECT_URI = '<redirect_URI>'
     OAUTH_USE_SECONDARY_ROLES = NONE
     ALLOWED_ROLES_LIST = ('<mcp_access_role>');
   
   -- integration name is case sensitive and must be uppercase here
   SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('<INTEGRATION_NAME>');

5. 5.Set DEFAULT_ROLE and DEFAULT_WAREHOUSE on every user who will connect

   Not optional, and not a nicety. A session with no default warehouse fails to initialise at all. And because several clients — Claude among them — request the session:role:all scope rather than a named role, the session runs as the user’s DEFAULT_ROLE whatever else you advertise in OAUTH_SCOPES_SUPPORTED. If different users need different data, the reliable answer is separate MCP servers with separate roles, not scopes.

   sql

   ALTER USER <username> SET DEFAULT_ROLE = '<mcp_access_role>' DEFAULT_WAREHOUSE = '<warehouse_name>';

6. 6.Point the client at the server URL

   The URL is fully qualified down to the server name — a truncated path authenticates fine and then fails to connect, which is the second entry in Snowflake’s own troubleshooting table. In Claude, add it under Settings → Connectors as a custom connector with the client id and secret; in ChatGPT, enable Developer mode and create a Connector with OAuth; in Cursor, add a url entry to ~/.cursor/mcp.json and then click Sign in under Cursor Settings → MCP.

   server URL and Cursor config

   https://<account_url>/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<name>
   
   // Cursor — ~/.cursor/mcp.json
   {
     "mcpServers": {
       "snowflake": {
         "url": "https://<account_url>/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<name>",
         "auth": {
           "CLIENT_ID": "${env:MCP_CLIENT_ID}",
           "CLIENT_SECRET": "${env:MCP_CLIENT_SECRET}"
         }
       }
     }
   }

7. 7.Open the network policy if you have one

   A remote MCP client connects from its provider’s infrastructure, not from the user’s browser, so an account network policy will block it even though the same user can log into Snowsight fine. The tell is misleading: a blocked token request comes back as error: invalid_client from /oauth/token-request, the same error as wrong credentials. Anthropic publishes Claude’s outbound IPs; other providers publish their own.

   sql

   CREATE NETWORK RULE mcp_client_ingress_rule
     MODE = INGRESS
     TYPE = IPV4
     VALUE_LIST = ('<client_provider_ip_1>', '<client_provider_ip_2>');
   
   ALTER NETWORK POLICY <your_policy_name>
     ADD ALLOWED_NETWORK_RULE_LIST = ('mcp_client_ingress_rule');

8. 8.Inspect what you built

   DESCRIBE returns the stored server_spec as JSON, which is the fastest way to confirm the client is seeing the tool list you think you wrote.

   sql

   SHOW MCP SERVERS IN SCHEMA <schema_name>;
   DESCRIBE MCP SERVER <server_name>;
   DROP MCP SERVER <server_name>;

The five tool types

The managed server has no fixed tool list — you compose it. Each entry in the specification YAML becomes one tool, named by you, with one of these five types. Maximum 50 per server.

What people use it for

Which one should you use?

Three projects answer to "Snowflake MCP server". Two of them are the same lineage and only one is supported.

Categories

Works With

Frequently Asked Questions

Related Guides