Set up Snowflake MCP Server

The Snowflake-managed MCP server is not a program to download but a database object inside a Snowflake account. This guide covers the basic steps from creation to a first connection with an AI client.

Prerequisites

You need an existing Snowflake account and a role with the CREATE MCP SERVER privilege on the target schema, plus USAGE privileges on the objects the server should expose later — for example a semantic view for Cortex Analyst, a Cortex Search service, or a warehouse for SQL execution.

Create the server via SQL

The server is created with a YAML specification listing the available tools:

CREATE OR REPLACE MCP SERVER my_server
FROM SPECIFICATION
$$
tools:
  - name: "query_metrics"
    identifier: "my_db.my_schema.my_semantic_view"
    type: "CORTEX_ANALYST_MESSAGE"
    description: "Answer questions about revenue and metrics in natural language."
    title: "Metrics"
$$;

Other tool types are CORTEX_SEARCH_SERVICE_QUERY for unstructured search, SYSTEM_EXECUTE_SQL for direct SQL execution, CORTEX_AGENT_RUN for an existing Cortex Agent, and GENERIC for custom functions or stored procedures. Per the documentation, a server allows up to 50 tools in total.

Endpoint and authentication

The server is then reachable at https://<account>.snowflakecomputing.com/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<server_name>. For production use, Snowflake's own OAuth 2.0 is the default path; for a quick first test, a Programmatic Access Token (PAT) used as a bearer token in the client works well. Use hyphens rather than underscores in hostnames to avoid connection issues.

Connecting an MCP client

In a CLI client such as Claude Code, the server can be registered for testing with a command following this pattern, replacing the angle-bracketed placeholders with your own values:

claude mcp add --transport http snowflake https://<account>.snowflakecomputing.com/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<server_name>

When connecting, the client will ask for the bearer token or start the OAuth flow, depending on how the server is configured at the account level.

Keep permissions narrow

Create a dedicated, narrowly scoped role for MCP access instead of reusing an existing, broadly privileged role. This matters especially for the SYSTEM_EXECUTE_SQL tool, since an agent uses it to run model-generated SQL against real data. Before enabling it, check exactly which tables, semantic views, and search services the role can actually see.

Verifying the setup

Start with a simple, read-only question in the client that matches the configured tool, such as a metrics question for Cortex Analyst. If the agent responds with a plausible result based on real data instead of a permission or connection error, the setup is correct.

Common pitfalls

A frequent mistake is using an underscore instead of a hyphen in the account identifier of the endpoint — this causes TLS or connection errors, since Snowflake consistently uses hyphens in hostnames. A second pitfall is missing privileges on referenced objects: if the semantic view or Cortex Search service lives in a different schema than the server, the role additionally needs USAGE on that schema, otherwise CREATE OR REPLACE MCP SERVER itself fails. If a tool returns an empty or implausible answer instead of an error, check the underlying semantic view or Cortex Search configuration first — the cause is often incomplete semantic modeling rather than the MCP connection itself. Anyone covering several use cases should also prefer several lean servers with clearly separated tools over one server mixing many different tool types, since that makes later permission management and troubleshooting noticeably easier.