Snowflake MCP Server

The Snowflake-managed MCP server is the official Model Context Protocol server for the Snowflake data cloud platform, fully hosted and operated by Snowflake itself. Unlike most entries in this catalog, it is not a downloadable package that runs locally or in your own container: it is created directly inside a Snowflake account via SQL and is then reachable through an account-specific HTTPS endpoint. According to Snowflake, this lets AI agents securely retrieve data and functionality from a Snowflake account "without needing to deploy separate infrastructure." Per the official release notes, the feature reached general availability on November 4, 2025.

How the server is created

A Snowflake MCP server is a database object. It is created with the SQL statement CREATE MCP SERVER <name> FROM SPECIFICATION $$ ... $$, inside a schema; the specification is a YAML structure describing a list of tools. Each tool has a name, a type, and a description intended for the model. Per the documentation, a single server supports up to 50 tools across all types combined.

Tool types per the documentation

Five tool types are available: CORTEX_ANALYST_MESSAGE attaches a semantic view for structured, natural-language queries; CORTEX_SEARCH_SERVICE_QUERY exposes a Cortex Search service for searching unstructured text; SYSTEM_EXECUTE_SQL allows direct execution of model-generated SQL; CORTEX_AGENT_RUN invokes an existing Cortex Agent; and GENERIC wraps a user-defined function or stored procedure. This combination lets a single server expose structured metrics, unstructured documents, and free-form SQL together.

Access, authentication, and governance

The endpoint follows the pattern https://<account>.snowflakecomputing.com/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<server_name>. For production access from MCP-capable clients, Snowflake defaults to its own OAuth 2.0 service; alternatively, the server can be bound to an external identity provider such as Okta or Microsoft Entra ID. For local development and initial testing, a Programmatic Access Token (PAT) used as a bearer token is the common approach. Governance runs through Snowflake's regular role-based access control (RBAC): creating a server requires the CREATE MCP SERVER privilege on the schema plus USAGE on the schema, the referenced Cortex Search service, SELECT on referenced semantic views, and USAGE on referenced warehouses, functions, or agents. At runtime, each tool acts with exactly the permissions of the calling role — an agent can only see and change what the connected role is already authorized to.

Difference from the earlier community project

Before the hosted server existed, an open-source community project at Snowflake-Labs/mcp (Apache-2.0) offered similar functionality and was installed locally via uvx or Docker. That repository now explicitly states it is no longer maintained and points to the officially managed server described here as the recommended successor. This entry covers only the current, hosted service; since that service is not itself published as open-source code, the entry carries no repository and no license field.

Cost

The documentation does not list a separate license fee for the MCP server itself; it is a feature of the Snowflake platform. Using it, however, incurs regular Snowflake costs: an existing Snowflake account, a warehouse for executing SQL and generic tools, and, depending on the tool types used, Cortex-specific consumption costs. Without an existing, paid Snowflake account, the server cannot meaningfully be used; concrete amounts are listed on Snowflake's official pricing page.

Who the server is for

The Snowflake-managed MCP server suits teams already working with Snowflake who want to make their data — structured tables via semantic models, unstructured documents via Cortex Search, or both combined through a Cortex Agent — accessible to AI assistants and agents, without operating their own bridging server or managing credentials outside Snowflake. For organizations without a Snowflake account, the server is naturally irrelevant; those looking for a lightweight, self-hosted SQL connection to a different data platform can find alternatives such as ClickHouse MCP Server or PlanetScale MCP Server elsewhere in this catalog.

An existing Snowflake account with a role that has CREATE MCP SERVER on the target schema and access to the referenced objects (semantic views, Cortex Search services, warehouses, functions); an MCP-capable client that supports OAuth or bearer tokens.

Create the server with CREATE MCP SERVER <name> FROM SPECIFICATION $$ ... $$ in a schema, naming the desired tools (Cortex Analyst, Cortex Search, SQL execution, custom functions, Cortex Agent) in the YAML specification. In the client, configure the endpoint https://<account>.snowflakecomputing.com/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<server_name> and authenticate via OAuth or a Programmatic Access Token.

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

Snowflake's own OAuth 2.0 by default, alternatively bound to an external identity provider (e.g. Okta, Microsoft Entra ID) at the account/database/schema level. For local development and testing, a Programmatic Access Token (PAT) used as a bearer token.

Each tool acts with the permissions of the connected Snowflake role: SQL execution requires warehouse usage and the underlying table privileges, Cortex Analyst tools require read access to the referenced semantic view, and Cortex Search tools require usage rights on the search service. Roles should be scoped as narrowly as the use case allows.

Requests and model-generated SQL or search terms go to the Snowflake platform; responses such as query results, search hits, and agent outputs return to the MCP client and the connected AI provider. The exact data involved depends entirely on the objects wired into the server specification.

A SYSTEM_EXECUTE_SQL tool lets an agent run model-generated SQL against real production data; without tightly scoped role privileges and review of sensitive objects, this can expose confidential data. Because all permissions flow through the connected role, MCP access should use a dedicated, narrowly scoped role rather than reusing a broadly privileged existing one. Cortex Search results drawn from document content can also contain embedded, misleading instructions (prompt injection).