Provides database interaction with Snowflake, enabling SQL query execution, table management, and schema exploration. Includes tools for reading data, modifying data (with appropriate permissions), creating tables, listing available tables, and describing table structures.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-snowflake-server list tables in the sales database"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server implementation that provides database interaction with Snowflake. This server enables running SQL queries via tools and exposes data insights and schema context as resources.
Related MCP server: Snowflake MCP Server
memo://insights
A continuously updated memo aggregating discovered data insights.
Updated automatically when new insights are appended via the append_insight tool.
context://table/{table_name}
(If prefetch enabled) Per-table schema summaries, including columns and comments, exposed as individual resources.
The server exposes the following tools:
read_query
Execute SELECT queries to read data from the database.
Input:
query (string): The SELECT SQL query to execute
Returns: Query results as array of objects
write_query (enabled only with --allow-write)
Execute INSERT, UPDATE, or DELETE queries.
Input:
query (string): The SQL modification query
Returns: Number of affected rows or confirmation
create_table (enabled only with --allow-write)
Create new tables in the database.
Input:
query (string): CREATE TABLE SQL statement
Returns: Confirmation of table creation
list_databases
List all databases in the Snowflake instance.
Returns: Array of database names
list_schemas
List all schemas within a specific database.
Input:
database (string): Name of the database
Returns: Array of schema names
list_tables
List all tables within a specific database and schema.
Input:
database (string): Name of the database
schema (string): Name of the schema
Returns: Array of table metadata
describe_table
View column information for a specific table.
Input:
table_name (string): Fully qualified table name (database.schema.table)
Returns: Array of column definitions with names, types, nullability, defaults, and comments
append_insight
Add new data insights to the memo resource.
Input:
insight (string): Data insight discovered from analysis
Returns: Confirmation of insight addition
Effect: Triggers update of memo://insights resource
To install Snowflake Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install mcp_snowflake_server --client claude"mcpServers": {
"snowflake_pip": {
"command": "uvx",
"args": [
"--python=3.12", // Optional: specify Python version <=3.12
"mcp_snowflake_server",
"--account", "your_account",
"--warehouse", "your_warehouse",
"--user", "your_user",
"--password", "your_password",
"--role", "your_role",
"--database", "your_database",
"--schema", "your_schema"
// Optionally: "--private_key_path", "your_private_key_absolute_path"
// Optionally: "--allow_write"
// Optionally: "--log_dir", "/absolute/path/to/logs"
// Optionally: "--log_level", "DEBUG"/"INFO"/"WARNING"/"ERROR"/"CRITICAL"
// Optionally: "--exclude_tools", "{tool_name}", ["{other_tool_name}"]
]
}
}"mcpServers": {
"snowflake_production": {
"command": "uvx",
"args": [
"--python=3.12",
"mcp_snowflake_server",
"--connections-file", "/path/to/snowflake_connections.toml",
"--connection-name", "production"
// Optionally: "--allow_write"
// Optionally: "--log_dir", "/absolute/path/to/logs"
// Optionally: "--log_level", "DEBUG"/"INFO"/"WARNING"/"ERROR"/"CRITICAL"
// Optionally: "--exclude_tools", "{tool_name}", ["{other_tool_name}"]
]
},
"snowflake_staging": {
"command": "uvx",
"args": [
"--python=3.12",
"mcp_snowflake_server",
"--connections-file", "/path/to/snowflake_connections.toml",
"--connection-name", "staging"
]
}
}Install Claude AI Desktop App
Install uv:
curl -LsSf https://astral.sh/uv/install.sh | shCreate a .env file with your Snowflake credentials:
SNOWFLAKE_USER="xxx@your_email.com"
SNOWFLAKE_ACCOUNT="xxx"
SNOWFLAKE_ROLE="xxx"
SNOWFLAKE_DATABASE="xxx"
SNOWFLAKE_SCHEMA="xxx"
SNOWFLAKE_WAREHOUSE="xxx"
SNOWFLAKE_PASSWORD="xxx"
SNOWFLAKE_PASSWORD="xxx"
SNOWFLAKE_PRIVATE_KEY_PATH=/absolute/path/key.p8
# Alternatively, use external browser authentication:
# SNOWFLAKE_AUTHENTICATOR="externalbrowser"[Optional] Modify runtime_config.json to set exclusion patterns for databases, schemas, or tables.
Test locally:
uv --directory /absolute/path/to/mcp_snowflake_server run mcp_snowflake_serverAdd the server to your claude_desktop_config.json:
"mcpServers": {
"snowflake_local": {
"command": "/absolute/path/to/uv",
"args": [
"--python=3.12", // Optional
"--directory", "/absolute/path/to/mcp_snowflake_server",
"run", "mcp_snowflake_server"
// Optionally: "--allow_write"
// Optionally: "--log_dir", "/absolute/path/to/logs"
// Optionally: "--log_level", "DEBUG"/"INFO"/"WARNING"/"ERROR"/"CRITICAL"
// Optionally: "--exclude_tools", "{tool_name}", ["{other_tool_name}"]
]
}
}"mcpServers": {
"snowflake_local": {
"command": "/absolute/path/to/uv",
"args": [
"--python=3.12",
"--directory", "/absolute/path/to/mcp_snowflake_server",
"run", "mcp_snowflake_server",
"--connections-file", "/absolute/path/to/snowflake_connections.toml",
"--connection-name", "development"
// Optionally: "--allow_write"
// Optionally: "--log_dir", "/absolute/path/to/logs"
// Optionally: "--log_level", "DEBUG"/"INFO"/"WARNING"/"ERROR"/"CRITICAL"
// Optionally: "--exclude_tools", "{tool_name}", ["{other_tool_name}"]
]
}
}By default, write operations are disabled. Enable them explicitly with --allow-write.
The server supports filtering out specific databases, schemas, or tables via exclusion patterns.
The server exposes additional per-table context resources if prefetching is enabled.
The append_insight tool updates the memo://insights resource dynamically.
MIT
Add a data insight to the memo
| Name | Required | Description | Default |
|---|---|---|---|
| insight | Yes | Data insight discovered from analysis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the memo must exist, if the operation is idempotent, or what side effects occur. The description only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and to the point, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the need to understand what 'the memo' refers to, the description is incomplete. It does not explain return values or any additional context needed for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter that has a clear description. The tool description adds minimal extra meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' and resource 'data insight' with target 'memo', clearly indicating the tool's action. It is distinct from sibling tools which deal with database schemas and queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. No context about prerequisites or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the schema information for a specific table
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | Fully qualified table name in the format 'database.schema.table' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without describing return format, side effects (likely read-only), or any performance considerations. For a simple tool, more context could be given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence with no redundancy, though it could be slightly more informative. It is front-loaded and minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description is adequate but lacks information about the return format or additional context. It could be improved by mentioning what fields are included in the schema information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a clear description. The tool description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'schema information for a specific table', which precisely defines the tool's function. It distinguishes itself from sibling tools like 'list_tables' and 'list_schemas' by focusing on a single table's schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when schema details for a table are needed, but provides no explicit guidance on when to use this tool versus alternatives like 'list_tables' or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available databases in Snowflake
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as permissions, limits, or side effects. For a read-only listing, at least mentioning that it returns database names without details would add transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys exactly what the tool does with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description is fairly complete for a simple listing. However, it could briefly mention the output format (e.g., list of database names) to be fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (schema coverage 100%). With zero parameters, baseline is 4, and the description adds no parameter-specific information, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available databases in Snowflake, which is a specific verb+resource. It contrasts with sibling tools (list_schemas, list_tables) by targeting a different scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not specify context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all schemas in a database
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | Database name to list schemas from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'list all schemas' but does not disclose any behavioral traits such as ordering, pagination, error handling, or required privileges. With no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words) and front-loaded. It conveys the core purpose efficiently, though more detail could be included without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description provides the basic purpose but lacks information about output format or potential limitations. With no output schema, the agent is left guessing about return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a description for the 'database' parameter, and the description adds minimal extra meaning. Since schema description coverage is high (100%), baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'List' and resource 'schemas' with scope 'in a database' clearly states the tool's function. It is easily distinguishable from sibling tools like list_databases and list_tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_databases or list_tables. The description does not mention context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables in a specific database and schema
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | Database name | |
| schema | Yes | Schema name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the basic function but does not mention permissions, limits, or the format of the output. For a simple read operation, this is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fully conveys the purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and no output schema, the description is minimally adequate. It does not explain what the output looks like (e.g., an array of table names), but the name and sibling tools provide some context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions ('Database name', 'Schema name'). The tool description adds no additional meaning beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all tables in a specific database and schema'. It distinguishes from sibling tools like list_databases and list_schemas by specifying the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool requires a database and schema as input, but does not explicitly state when to use this tool versus alternatives (e.g., 'If you need to find tables for a query, use this first'). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a SELECT query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | SELECT SQL query to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states 'Execute a SELECT query' without disclosing behavioral traits such as read-only nature, limits, or response structure. The read-only implication is present but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence. It is front-loaded with the action, but could benefit from slightly more structure or detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no output schema), the description is adequate but does not explain the output or any constraints. It is minimally complete for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the parameter. The description adds no additional meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute a SELECT query' clearly states the verb and resource, distinguishing it from siblings like list_tables or describe_table. However, it does not specify the return format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_tables or describe_table. The description lacks context for when SELECT queries are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: metadata listing, schema description, query execution, and memo insight. No overlap.
All tool names follow a consistent verb_noun pattern with lowercase and underscores, e.g., list_databases, read_query.
6 tools is well-scoped for a Snowflake server covering metadata exploration and querying without being excessive.
Covers metadata listing and SELECT queries thoroughly, but lacks DML/DDL operations like INSERT or CREATE, which may be needed depending on use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search, access, and get insights on your Amplitude data
Query BigQuery, Snowflake, Redshift & Azure Synapse with natural language
List reverse-ETL sources, destinations, models, syncs and runs; trigger syncs into SaaS tools.
CX ops: read conversations, calls and QA evaluations from Zendesk, Freshdesk, Five9 and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/isaacwasserman/mcp-snowflake-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
