RELATED 01
Metabase MCP server
OFFICIAL SERVERBuilt-in MCP endpoint of a Metabase instance for searching, querying, charting and editing its content
50kGitHub stars
40popularity score
Snowflake Cortex AI Model Context Protocol (MCP) Server
Deprecated Snowflake Labs server for Cortex Search, Analyst, Agents, SQL and object management
By Snowflake Labs Python Local · stdio DatabasesData and analyticsAI and ML
66 popularity score ★ 303 ↓ 44k/mo
Connect your client
Local (PyPI)
Add in one click
Opens the app, which asks before it adds the server. Then replace each <NAME> in its settings with your value.
Or add it by command or config
Claude CodeTerminal
claude mcp add snowflake-cortex-ai-model-context-protocol -- uvx snowflake-labs-mcp --service-config-file '<ABSOLUTE_PATH_TO_TOOLS_CONFIG_YAML>' --connection-name defaultClaude Desktopclaude_desktop_config.json
{
"mcpServers": {
"snowflake-cortex-ai-model-context-protocol": {
"command": "uvx",
"args": [
"snowflake-labs-mcp",
"--service-config-file",
"<ABSOLUTE_PATH_TO_TOOLS_CONFIG_YAML>",
"--connection-name",
"default"
]
}
}
}Cursor~/.cursor/mcp.json
{
"mcpServers": {
"snowflake-cortex-ai-model-context-protocol": {
"command": "uvx",
"args": [
"snowflake-labs-mcp",
"--service-config-file",
"<ABSOLUTE_PATH_TO_TOOLS_CONFIG_YAML>",
"--connection-name",
"default"
]
}
}
}VS Code.vscode/mcp.json
{
"servers": {
"snowflake-cortex-ai-model-context-protocol": {
"type": "stdio",
"command": "uvx",
"args": [
"snowflake-labs-mcp",
"--service-config-file",
"<ABSOLUTE_PATH_TO_TOOLS_CONFIG_YAML>",
"--connection-name",
"default"
]
}
}
}Codex~/.codex/config.toml
[mcp_servers.snowflake-cortex-ai-model-context-protocol]
command = "uvx"
args = ["snowflake-labs-mcp", "--service-config-file", "<ABSOLUTE_PATH_TO_TOOLS_CONFIG_YAML>", "--connection-name", "default"]Gemini CLITerminal
gemini mcp add --scope user snowflake-cortex-ai-model-context-protocol uvx -- snowflake-labs-mcp --service-config-file '<ABSOLUTE_PATH_TO_TOOLS_CONFIG_YAML>' --connection-name defaultSettings 9
SNOWFLAKE_ACCOUNT |
Optional: Account identifier, when not using a connections.toml entry. |
|---|---|
SNOWFLAKE_USER |
Optional: User name for sign-in. |
SNOWFLAKE_PASSWORD |
Optional: Password or programmatic access token. |
SNOWFLAKE_PRIVATE_KEY_FILE |
Optional: Path to a private key for key-pair sign-in (or SNOWFLAKE_PRIVATE_KEY with the key itself). |
SNOWFLAKE_PRIVATE_KEY_FILE_PWD |
Optional: Password of an encrypted private key. |
SNOWFLAKE_ROLE |
Optional: Role to connect with; the user's default role otherwise. |
SNOWFLAKE_WAREHOUSE |
Optional: Warehouse used for queries. |
SERVICE_CONFIG_FILE |
Optional: Path to the tools YAML file, instead of --service-config-file. |
SNOWFLAKE_MCP_VERBOSE |
Optional: Set to true for debug logging. |
What it does
A local Python server from the Snowflake-Labs GitHub organisation that exposes a Snowflake account to an MCP client. Its makers now mark it deprecated and no longer maintained, and point every user to the managed Snowflake MCP Server documented by Snowflake instead.
What it offers is set by a YAML file passed at start. Each Cortex Agent, Cortex Search and Cortex Analyst service listed there becomes reachable through one tool per service type (cortex_agent, cortex_search, cortex_analyst). Three optional groups can be switched on: object management (create, drop, create-or-alter, describe and list databases, schemas, tables, views, warehouses, compute pools, roles, stages, users and image repositories), a general SQL tool, and semantic view tools for listing, describing and querying Snowflake Semantic Views.
SQL statements are classified with sqlglot and checked against an allow/deny list in the same file, so an operator can, for example, allow Select but refuse Drop. Everything runs under the Snowflake role given at connection time.
At version 1.4.2 the object management group is five generic tools that take an object type, not the "dozens" of narrow tools the README describes, so a full setup has at most 16 tools (mcp_server_snowflake/object_manager/tools.py). The server also tags every session it opens with a query tag (origin sf_sit, name mcp_server), which makes its queries visible in Snowflake query history (mcp_server_snowflake/server.py).
What it needs
| Runtime | Python |
|---|
uv (for uvx) and Python; a Snowflake account and a role with access to the objects and Cortex services you configure; a tools YAML file (passed with --service-config-file or the SERVICE_CONFIG_FILE variable, the server will not start without it); credentials through a connections.toml entry (--connection-name) or SNOWFLAKE_* variables. The Docker image must be built from the repository and serves streamable HTTP on port 9000, not stdio.
Limits
Deprecated and unmaintained by its makers; no new fixes are expected. Only Cortex Agent objects already created in Snowflake can be used as agents. Cortex Search returns the service's default columns and 10 results unless the prompt asks otherwise. Some Snowflake commands are not mapped by sqlglot and fall under Unknown, which is refused unless set to True. The README's Docker examples use docker run -d with an HTTP port, so they are not stdio commands for a client. The --account-identifier and --pat flags and SNOWFLAKE_PAT are deprecated.
Who it suits
Suits teams that already run it against Snowflake and want Cortex Search, Analyst and Agents plus guarded SQL from a local client while they plan a move. For new setups its own README sends users to Snowflake's managed Snowflake MCP Server, which is maintained and supported. Pick this one only if you need a self-run process with a statement allow-list you control, and accept that it receives no updates.
Tools 16
cortex_agent- Sends a question to one of the configured Cortex Agent objects
cortex_search- Searches one of the configured Cortex Search services over unstructured data
cortex_analyst- Turns a question into SQL against a configured semantic model or view and runs it
create_object- Creates a database, schema, table, view, warehouse, role, user or other supported object
drop_object- Drops a supported Snowflake object
create_or_alter_object- Creates a supported object or alters it if it exists
describe_object- Returns the definition of a supported object
list_objects- Lists Snowflake objects of one supported type
run_snowflake_query- Runs a SQL statement after checking its type against the allow list
list_semantic_views- Lists semantic views in the account, a database or a schema
describe_semantic_view- Shows the structure of one semantic view
show_semantic_dimensions- Lists semantic dimensions in a given scope
show_semantic_metrics- Lists semantic metrics in a given scope
get_semantic_view_ddl- Returns the DDL of a semantic view
write_semantic_view_query_tool- Builds a query against a semantic view from chosen metrics and dimensions
query_semantic_view- Runs a query against a semantic view and returns rows