Snowflake MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct operation: describing a table, executing queries, saving query results, searching tables, refreshing cache, and browsing catalog. No overlap in purpose.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., describe_table, execute_query, find_tables). No mixing of styles.
Tool Count5/5
6 tools cover the essential read-only Snowflake operations without bloat. The count is well-scoped for the server's purpose.
Completeness5/5
The toolset provides complete CRUD-like coverage for read-only schema exploration and querying: browse, search, describe, query, and save results. Cache management is also included.
Average 4.5/5 across 6 of 6 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on June 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description thoroughly discloses behavior: read-only restriction, compact TEXT payload format with headers, handling of different row counts, and spilling to file for large results. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections (overview, prerequisite, parameters, return format, example). Though lengthy, each sentence adds useful information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description fully compensates by detailing return format, edge cases (single row, multiple rows, large results), and caching behavior. Complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description provides meaningful explanations for all three parameters (sql, database, schema), indicating sql is the query, and database/schema are optional contexts. Adds value beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it executes read-only SQL queries (SELECT, SHOW, DESCRIBE, WITH), providing a specific verb and resource. However, it does not explicitly distinguish from sibling tools like execute_query_to_file or describe_table, lacking sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs. alternatives. It mentions a prerequisite (populated schema cache) but does not exclude cases or compare with siblings like execute_query_to_file for file output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions scanning all databases and a 5-day cache TTL, and explains the 'force' and 'resume' parameters. However, it does not describe potential side effects (e.g., performance impact) or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with a brief intro, a bulleted usage section, and parameter details. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description gives some idea of the output ('build a comprehensive index...'). It covers the tool's core behavior and parameters well. Missing details on what the catalog index looks like post-refresh or whether other tools immediately benefit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no property descriptions), but the tool's description includes a bulleted list explaining both parameters, their meanings, and defaults. This compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Refresh the schema catalog by scanning all accessible Snowflake databases', which is a specific verb+resource combination. It distinguishes from siblings like describe_table, execute_query, and find_tables by focusing on catalog maintenance rather than data access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists three use cases: first connection, after schema changes, and when cache expires. Also mentions the 5-day TTL. However, it does not state when not to use or provide alternatives, which would strengthen the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains caching behavior (first call live, subsequent cached), error condition (table not in cache), and return details. It does not explicitly state that the operation is read-only or non-destructive, but the context suggests it is. Could mention idempotency or stability, but it's already clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (USE THIS WHEN, RETURNS, HOW IT WORKS, Parameters, Examples). It is front-loaded with the core purpose, and every sentence adds value. No fluff. Appropriate length for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (3 parameters, no output schema), the description is complete. It explains the return format (list of columns with attributes), caching behavior, and error handling. It also directs users to other tools for related tasks. All necessary context is provided for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It lists the three parameters (database, schema, table) and provides example calls. However, it does not explain naming conventions, case sensitivity, or any constraints. The examples are helpful but limited. Baseline 3 is appropriate as some extra context is provided but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed column information for a table, using the verb 'get' and specifying the resource. It distinguishes itself from siblings like execute_query (for data) and find_tables/show_tables (for discovery) by focusing on schema metadata. The SQL analogy reinforces its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'USE THIS WHEN: You need column names, types, and constraints to write a query.' It also directs to use execute_query for sample data and implies that find_tables or show_tables should be used first if the table isn't in cache. This clearly differentiates when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses: read-only SQL, file overwrite prevention, format rules based on extension, timeout range, and requirement for schema cache. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with intro, usage, parameter list, constraints, example. Every sentence adds value. Slightly verbose but clear and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, description covers all essential aspects: inputs, output format, constraints, timeout, and prerequisite. Agent can use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains each parameter: sql allowed statements, file_path path and extension, database/schema optional context, timeout_seconds default and max. Provides an example. Fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes read-only query results to a file, specifying the verb 'writes' and the resource 'results to a file'. It also distinguishes from sibling execute_query by noting the output goes to a file path, and format depends on extension.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when the result needs to land at a specific path -- to share or persist.' It also provides constraints like no overwrite and requires schema cache. However, it does not explicitly contrast with execute_query for when results are needed interactively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It thoroughly explains caching behavior (auto-refreshes with auth, uses cached data if available), case-insensitive search, and the two return modes (flat list vs compact summary). It also justifies why comment and column count are omitted. However, it does not explicitly state that the tool is read-only, though this is implied by the search operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (USE THIS WHEN, RETURNS, HOW IT WORKS, Parameters, Examples). It is thorough without being verbose; every sentence adds value—explaining return modes, caching, search behavior, and example usage. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two distinct return modes, caching behavior, and auth requirements. Despite lack of output schema, the description fully covers both response formats, explains when each is triggered, provides narrowing guidance, and describes caching mechanics. It is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter, so the description must compensate. It adds that search_term is a keyword, case-insensitive, and provides three examples. This gives sufficient meaning beyond the schema's title and type, meeting the baseline of 4 for a single parameter with no schema docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool searches for tables by keyword across ALL databases, distinguishing it from siblings like show_tables (which filters by database/schema patterns) and describe_table (which provides details). The description specifies verb 'search', resource 'tables', and scope 'all databases'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE THIS WHEN' section advises using this tool when you don't know the table's location but know part of its name or purpose. It also provides narrowing guidance via the 'spilled' hint and recommends using show_tables with more specific patterns, thus clearly indicating when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Transparently explains small vs. large result behavior, cache auto-refresh, case-insensitive substring matching, and provides detailed instructions for reading spilled files. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (USE THIS WHEN, RETURNS, HOW IT WORKS, Parameters, Examples). Somewhat lengthy but necessary given complexity; maintains reasonable conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete coverage: no output schema, no annotations, but description explains caching, result sizes, file handling with command examples, and pattern behavior. Addresses edge cases and provides actionable guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds detailed meaning for each parameter with examples (e.g., 'SALES' matches 'SALES_DB'). Explains pattern matching behavior and defaults effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Browse databases, schemas, and tables using pattern-based filtering.' Compares to SQL SHOW TABLES, distinguishing from sibling tools like describe_table or execute_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'USE THIS WHEN: You want to explore what databases/schemas exist, or need to filter by exact patterns.' Provides examples and suggests retightening filters for spilled results. Could mention when to use alternatives like find_tables, but overall clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![snowflake_mcp_server MCP server](https://glama.ai/mcp/servers/ncejda-g2/snowflake_mcp_server/badges/card.svg)](https://glama.ai/mcp/servers/ncejda-g2/snowflake_mcp_server)

Score Badge

Copy to your README.md:

[![snowflake_mcp_server MCP server](https://glama.ai/mcp/servers/ncejda-g2/snowflake_mcp_server/badges/score.svg)](https://glama.ai/mcp/servers/ncejda-g2/snowflake_mcp_server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ncejda-g2/snowflake_mcp_server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server