Snowflake Labs MCP

What Snowflake-Labs/mcp MCP server does

Snowflake-Labs/mcp MCP server was a community implementation for connecting MCP clients to Snowflake workloads. It exposed selected Cortex services and database operations as tools, based on a YAML service configuration loaded when the process started.

The project supported Cortex Search for retrieving unstructured data, Cortex Analyst for querying structured data through semantic models, and Cortex Agents for orchestrating retrieval across structured and unstructured sources. Additional tool groups covered common Snowflake object operations, LLM-generated SQL execution, and discovery or querying of Snowflake Semantic Views.

This repository is deprecated and no longer maintained. Snowflake recommends migrating both new and existing use cases to its official Snowflake MCP Server.

How it works

A configuration file determines which tools become available. Administrators could list Cortex Agent, Search, and Analyst services with their Snowflake locations and descriptions. Separate switches enabled object management, SQL query execution, and semantic view functionality.

SQL-changing operations were governed by an allowlist of statement categories. Administrators could permit or deny operations such as Create, Alter, Insert, Update, Delete, Drop, Select, and transaction commands. Unmapped statement types could also be rejected by leaving the Unknown category disabled.

The server connected through the Snowflake Python Connector and used the role supplied in the connection parameters, or the user’s default role when no role was supplied. Snowflake RBAC therefore remained part of access control alongside the server’s SQL statement permissions.

Setup and configuration

The legacy command supported a YAML configuration file, passed with --service-config-file. A documented local invocation used uvx snowflake-labs-mcp --service-config-file config.yaml with stdio as the default transport.

Connection settings could be supplied as command-line arguments or environment variables. Supported connection options included the account or host, user, password, role, warehouse, MFA passcode, private key, private-key password, authenticator, and a named connection from a Snowflake configuration file. The connector supported username and password, key pair, OAuth, SSO, and MFA authentication methods.

The available transports were stdio for local MCP client connections, legacy SSE for streaming applications, and streamable HTTP for container or remote deployments. The repository cautioned that older account-identifier and personal-access-token options were deprecated in favor of account and password settings.

Tools and capabilities

Snowflake-Labs/mcp MCP server provided configuration-controlled access to:

• Cortex Search services for unstructured-data retrieval.
• Cortex Analyst services backed by semantic models or Semantic Views.
• Cortex Agent services spanning structured and unstructured retrieval.
• Basic creation, modification, and deletion operations for common Snowflake objects.
• SQL execution constrained by configured statement permissions.
• Semantic View discovery and querying.

Search behavior could be driven dynamically by the user’s prompt. When search columns were not specified, the service’s default columns and a limit of 10 were returned.

Limitations and notes

Snowflake-Labs/mcp MCP server should not be selected for a maintained production integration because the repository is explicitly deprecated and unsupported. Its documentation is retained for legacy reference only. The supported migration target is Snowflake’s official MCP Server, which Snowflake continues to develop and support.

The configuration controlled which Cortex services were exposed, so a client could not use services omitted from that file. SQL permissions also required explicit review: enabling broad statement categories could allow tools to change Snowflake objects within the connected role’s privileges.