Snowflake MCP connects your Snowflake data warehouse directly to AI assistants like Claude, Cursor, and ChatGPT – letting AI agents query, analyze, and act on your data through the open Model Context Protocol standard. This guide covers both Snowflake’s managed MCP server and the open-source alternative, walks through setup for every major AI client, and explains where each approach fits (and where it breaks down).

What is Snowflake MCP?

Snowflake MCP is Snowflake’s implementation of the Model Context Protocol – the open standard created by Anthropic that gives AI agents a universal way to discover and interact with external tools and data sources. Instead of building custom API integrations for every AI application, MCP provides a single protocol that any AI client can use to connect to any MCP-compatible server.

Snowflake offers two distinct MCP implementations, and understanding the difference matters for choosing the right approach.

Both approaches give AI agents access to your Snowflake data, but they differ in deployment model, authentication, and what’s supported. The managed server is simpler to set up and inherits Snowflake’s governance model automatically. The open-source server offers more flexibility and runs anywhere Python does.

Why Snowflake is betting on MCP

Snowflake’s MCP investment is part of a broader strategic shift toward what the company calls the “agentic enterprise.” In April 2026, Snowflake announced major updates to Snowflake Intelligence and Cortex Code, positioning Snowflake as the control plane for AI agents that don’t just analyze data but take action on it.

The numbers back this up. Over 9,100 Snowflake accounts now use Cortex AI weekly, driving 200%+ growth in AI-related workloads. More than 50% of customers actively use Cortex Code since its November 2025 launch. Snowflake’s product revenue hit $4.72 billion in fiscal 2026, up 30% year-over-year, with remaining performance obligations at $9.77 billion.

MCP is central to this strategy because it makes Snowflake data accessible to any AI agent without custom integration work. Cortex Agents now support MCP connectors for tools like Jira, Salesforce, Google Workspace, and Slack – turning Snowflake from a data warehouse into an orchestration layer for AI agent workflows.

What Snowflake MCP can actually do

The Snowflake MCP server exposes several Cortex AI capabilities as MCP tools. Here’s what each one does in practice.

Cortex Analyst – natural language to SQL

Cortex Analyst translates plain English questions into SQL queries against your structured data. You define a semantic view that maps your tables and relationships, and the AI agent can then ask questions like “what was Q1 revenue by region” without writing SQL. The managed MCP server only supports semantic views – not the older semantic YAML models.

Cortex Search – unstructured data retrieval

Cortex Search enables RAG (retrieval augmented generation) over unstructured data stored in Snowflake. Think product documentation, support tickets, policy documents, or contracts. The AI agent sends a query, and Cortex Search returns relevant passages that the agent can use to generate answers grounded in your actual data.

Cortex Agents – multi-step orchestration

Cortex Agents combine structured and unstructured data retrieval into a single orchestration layer. An agent can query a semantic view for revenue numbers, search a document corpus for context, and chain the results into a coherent answer – all in one interaction.

SQL execution and custom tools

Beyond Cortex services, the MCP server can execute arbitrary SQL (governed by configurable statement permissions) and invoke UDFs or stored procedures as tools. This means you can expose any custom logic – a pricing calculator, a data quality check, a transformation pipeline – as an MCP tool that AI agents can discover and call.

How to set up the Snowflake managed MCP server

The managed server runs entirely inside Snowflake. No local installation, no containers, no Python environment to manage.

Step 1 – create the MCP server object

In a Snowflake SQL worksheet, define your server and the tools it exposes:

CREATE MCP SERVER my_mcp_server
  FROM SPECIFICATION $$
    tools:
      - name: "revenue-analyst"
        type: "CORTEX_ANALYST_MESSAGE"
        identifier: "my_db.my_schema.revenue_semantic_view"
        description: "Query revenue and financial data"
        title: "Revenue Analyst"
      - name: "doc-search"
        type: "CORTEX_SEARCH_SERVICE_QUERY"
        identifier: "my_db.my_schema.doc_search_service"
        description: "Search product documentation"
        title: "Doc Search"
      - name: "sql-exec"
        type: "SYSTEM_EXECUTE_SQL"
        description: "Execute SQL queries"
        title: "SQL Execution"
        config:
          read_only: true
          query_timeout: 600
  $$;

Step 2 – configure OAuth authentication

The managed server requires OAuth 2.0. Create a security integration:

CREATE SECURITY INTEGRATION my_mcp_oauth
  TYPE = OAUTH
  OAUTH_CLIENT = CUSTOM
  ENABLED = TRUE
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'http://localhost:8080/callback';

-- Retrieve your client credentials
SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('MY_MCP_OAUTH');

Step 3 – grant access

Grant the appropriate permissions so your AI client’s role can discover and use the tools:

GRANT USAGE ON MCP SERVER my_mcp_server TO ROLE analyst_role;
-- Also grant access to underlying objects
GRANT SELECT ON SEMANTIC VIEW my_db.my_schema.revenue_semantic_view TO ROLE analyst_role;
GRANT USAGE ON CORTEX SEARCH SERVICE my_db.my_schema.doc_search_service TO ROLE analyst_role;

Step 4 – connect your AI client

The server URL follows this pattern:

https://<account_url>/api/v2/databases/{database}/schemas/{schema}/mcp-servers/{name}

Add this URL to your AI client’s MCP configuration – Claude Desktop, Cursor, or any MCP-compatible application.

How to set up the open-source Snowflake MCP server

The Snowflake-Labs/mcp open-source server runs locally or in Docker. It’s more flexible than the managed option and doesn’t require OAuth setup.

Installation

The fastest way to run it is via uvx (no installation needed):

uvx snowflake-labs-mcp --service-config-file config.yaml --connection-name default

Configuration file

Create a YAML configuration that defines which Cortex services to expose and what SQL permissions to allow:

analyst_services:
  - service_name: revenue_analyst
    semantic_model: MY_DB.MY_SCHEMA.REVENUE_SEMANTIC_VIEW
    description: "Query revenue and financial data"

search_services:
  - service_name: doc_search
    description: "Search documentation"
    database_name: MY_DB
    schema_name: MY_SCHEMA

other_services:
  object_manager: True
  query_manager: True
  semantic_manager: True

sql_statement_permissions:
  - Select: True
  - Describe: True
  - Use: True
  - Create: False
  - Drop: False
  - Delete: False

Claude Desktop configuration

Add the server to your claude_desktop_config.json:

{
  "mcpServers": {
    "snowflake": {
      "command": "uvx",
      "args": [
        "snowflake-labs-mcp",
        "--service-config-file",
        "/path/to/config.yaml",
        "--connection-name",
        "default"
      ]
    }
  }
}

Cursor configuration

In Cursor, navigate to Settings – Cursor Settings – MCP and add the same configuration. Alternatively, create a .cursor/mcp.json file in your project root for project-scoped access.

Docker deployment for teams

For shared access, deploy the server as a Docker container:

docker build -f docker/server/Dockerfile -t mcp-server-snowflake .

docker run -d \
  --name mcp-server-snowflake \
  -p 9000:9000 \
  -e SNOWFLAKE_ACCOUNT=${SNOWFLAKE_ACCOUNT} \
  -e SNOWFLAKE_USER=${SNOWFLAKE_USER} \
  -e SNOWFLAKE_PASSWORD=${SNOWFLAKE_PASSWORD} \
  -v ${HOME}/.mcp/config.yaml:/app/services/tools_config.yaml:ro \
  mcp-server-snowflake

Team members then connect their AI clients to http://your-server:9000/snowflake-mcp instead of running a local server.

Managed vs. open-source – which Snowflake MCP server to use

MCP adoption and the Snowflake ecosystem

Snowflake’s MCP push isn’t happening in isolation. The broader MCP ecosystem has exploded since Anthropic open-sourced the protocol in late 2024. As of early 2026, the MCP registry lists over 17,400 servers, and SDKs are being downloaded at a rate of 97 million per month. Enterprise adoption is accelerating – a recent survey found 78% of enterprise AI teams have at least one MCP integration in production.

For Snowflake specifically, MCP solves a distribution problem. Before MCP, accessing Snowflake data from AI tools required either custom API integrations or copy-pasting query results into chat windows. Now, any MCP-compatible client – Claude, Cursor, VS Code with Copilot, fast-agent, or custom applications – can discover and query Snowflake data through a standardized interface.

Snowflake commands roughly 20% of the cloud data warehousing market and serves over 11,500 customers including 745 Forbes Global 2000 companies. With 580 customers generating over $1 million in annual product revenue and a 126% net revenue retention rate, there’s a massive installed base that can immediately benefit from MCP connectivity. This is why Snowflake moved the managed MCP server to general availability rather than keeping it in extended preview.

Practical use cases for Snowflake MCP

Once connected, what can you actually ask an AI agent to do with your Snowflake data? Here are concrete examples organized by role.

Data analysts

Instead of writing SQL manually, analysts can ask questions in plain English through Claude or Cursor. “What’s the month-over-month change in customer churn by segment?” triggers Cortex Analyst, which generates the SQL, runs it against your semantic view, and returns the results. This works especially well for ad-hoc exploration where building a dashboard would be overkill.

Data engineers

With object management enabled (open-source server), engineers can ask AI agents to create staging tables, describe schemas, or audit data lineage across their warehouse. Combined with SQL execution, agents can run data quality checks or diagnose pipeline failures by querying task history and copy history tables.

Business users

Product managers, finance teams, and operations leads can query Snowflake data without SQL knowledge. “Show me the top 10 customers by lifetime value who haven’t purchased in 90 days” gets translated to SQL automatically. Combined with Cortex Search, they can also search unstructured data like support tickets or contracts.

Application developers

Developers building AI-powered applications can use Snowflake MCP as the data backend. A customer-facing chatbot backed by Cortex Agents can answer questions about order status, account details, or product availability – all governed by Snowflake’s RBAC so the agent only sees data the user is authorized to access.

Data platform teams

Platform teams can use MCP to expose governed data products to the rest of the organization. Instead of granting direct Snowflake access to every team, create an MCP server with curated semantic views that represent clean, documented data products. Teams consume the data through AI agents without needing to know SQL or understand the underlying schema. This is essentially a semantic layer served through MCP.

Known limitations

Before committing to Snowflake MCP in production, understand what it can’t do yet.

The open-source server has fewer restrictions (supports YAML models, all auth methods, object management) but requires you to manage infrastructure and doesn’t inherit Snowflake’s governance model automatically.

Troubleshooting Snowflake MCP

These are the most common issues teams run into when setting up Snowflake MCP, based on GitHub issues and community reports.

Server not appearing in AI client

If your MCP server doesn’t show up in Claude Desktop or Cursor, check these first: verify the configuration file path is absolute (not relative), confirm uvx is installed and on your PATH, and restart the AI client completely. For Claude Desktop, check logs at ~/Library/Logs/Claude/ on macOS.

OAuth authentication failures

The managed server requires a security integration with OAUTH_CLIENT_TYPE = ‘CONFIDENTIAL’. Common errors include mismatched redirect URIs, expired tokens, and incorrect client credentials. Run SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('INTEGRATION_NAME') to verify your credentials – note the integration name must be uppercase.

Permission denied on tool calls

Access to the MCP server doesn’t automatically grant access to its tools. You need to grant USAGE on the MCP server AND on each underlying object (semantic views, search services, agents). Check that your role has SELECT on semantic views and USAGE on Cortex services.

SSL errors with account identifiers

If your Snowflake account identifier contains underscores, replace them with hyphens in the connection URL. This is a known issue documented by Snowflake.

Using MCP Inspector for debugging

The MCP Inspector is the fastest way to debug server issues. Run it with:

npx @modelcontextprotocol/inspector uvx snowflake-labs-mcp \
  --service-config-file config.yaml \
  --connection-name default

This opens a web interface where you can see all registered tools, test them individually, and inspect error messages.

The multi-source problem with Snowflake MCP

Here’s the fundamental limitation that Snowflake’s documentation doesn’t address: Snowflake MCP only gives your AI agent access to data that’s already in Snowflake.

Most enterprises don’t have all their data in Snowflake. CRM data lives in HubSpot or Salesforce. Marketing data sits in Google Ads and LinkedIn. E-commerce data is in Shopify. Accounting data is in Xero or QuickBooks. Support tickets are in Zendesk. Even if you run ELT pipelines to load some of this into Snowflake, there’s always a subset that isn’t synced – or isn’t synced frequently enough for real-time agent queries.

This creates a fragmented experience. Your AI agent can answer “what was Q1 revenue?” from Snowflake but can’t cross-reference it with “which marketing campaigns drove those deals?” from HubSpot or “what’s the support ticket volume for those customers?” from Zendesk. You’d need to build and maintain separate MCP server connections to each system – each with its own auth, schema mapping, and maintenance overhead.

For organizations that use Snowflake as their primary warehouse and have most data already loaded there, Snowflake MCP works well. But for the majority of mid-market companies with data spread across 10-50+ SaaS tools, a single-warehouse MCP approach leaves significant gaps.

The data warehouse approach: connect Snowflake to AI through Peliqan

Rather than connecting AI agents directly to Snowflake (or managing separate MCP servers for every tool), the more scalable approach is to route everything through a data platform that sits between your sources and your AI clients.

The architecture works like this: you connect Snowflake as a data source into Peliqan, alongside your other business applications (CRM, ERP, marketing tools, etc.). Peliqan syncs all that data into its built-in Postgres + Trino warehouse, where it’s governed, transformed, and quality-checked. Then Peliqan’s MCP server exposes the warehouse to Claude, ChatGPT, Cursor, or any MCP-compatible AI client.

The AI agent never connects to Snowflake directly. It connects to Peliqan’s MCP server, which has your Snowflake data (plus everything else) already synced and ready to query.

The key advantage over Snowflake-native MCP is scope. Snowflake MCP gives your AI agent access to Snowflake only. With Peliqan, your AI agent gets access to Snowflake data plus every other connected source through a single MCP endpoint. And because everything is synced into one warehouse first, cross-source queries just work – no separate integrations needed.

Snowflake MCP vs. unified data platform – comparison

Decision framework – choosing the right Snowflake MCP approach

Data quality matters more when AI agents query directly

When humans run SQL queries, they apply judgment to the results. They notice when numbers look wrong, cross-check against expectations, and sanity-check before acting. AI agents don’t have that context unless you give it to them.

This makes data quality monitoring critical for MCP deployments. If your Snowflake tables have stale data, duplicate records, or broken pipelines, AI agents will confidently serve wrong answers. Before exposing data through MCP, implement automated checks: row count monitoring, freshness alerts, schema drift detection, and null rate tracking. Snowflake’s INFORMATION_SCHEMA and ACCOUNT_USAGE views provide the metadata you need, but you still need tooling to automate the monitoring and alerting.

Semantic views help here because they add a curation layer between raw tables and what the AI agent sees. But they don’t replace pipeline monitoring. A semantic view over a table that hasn’t been refreshed in three days still serves three-day-old data.

Snowflake MCP security best practices

Snowflake’s documentation includes specific security recommendations for MCP deployments. Here are the key ones to follow.

Use OAuth authentication over programmatic access tokens wherever possible. PATs can leak, and when they do, the attacker inherits whatever role the token was created with. If you must use PATs, create them with the least-privileged role that still allows the required operations. This principle of least privilege applies equally to any AI agent deployment, not just Snowflake.

Verify third-party MCP servers before connecting them. Tool poisoning (a malicious server registering dangerous tools) and tool shadowing (overriding legitimate tools with malicious ones) are real risks when you connect multiple MCP servers without auditing their tool registrations.

Configure SQL statement permissions explicitly. The open-source server’s YAML config lets you allow or deny specific SQL statement types. Start with read-only (Select, Describe, Use) and only enable write operations (Insert, Update, Delete, Create) when your use case genuinely requires them.

Grant MCP server access and tool access separately. Having USAGE on the MCP server only lets clients discover tools. Each underlying object (semantic view, search service, agent, UDF) needs its own permission grant. This granular access control prevents over-provisioning.

Getting started with Snowflake MCP

The fastest path to a working Snowflake MCP setup depends on your starting point.

If you already have Snowflake with Cortex services configured, the managed MCP server takes under 30 minutes: create the MCP SERVER object, set up OAuth, and point your AI client at the endpoint. Snowflake’s quickstart guide walks through every step.

If you want to experiment first, the open-source server is faster to get running locally – install with uvx, create a YAML config pointing at your Snowflake account, and add it to Claude Desktop or Cursor. No OAuth setup needed.

If you need your AI agents to access Snowflake alongside other data sources, connect Snowflake into Peliqan as a source, add your other business apps, and let Peliqan sync everything into its built-in warehouse. Then install Peliqan’s MCP server with pip install mcp-server-peliqan and your AI agents can query across all sources through one endpoint.

Configure your data connections through the Peliqan UI – Snowflake alongside CRM, ERP, marketing, and any other source your team uses. The AI queries the Peliqan warehouse, not Snowflake directly, so cross-source analysis works out of the box.

Whichever path you choose, MCP is rapidly becoming the default protocol for AI-to-data connectivity. Snowflake’s investment – from the managed server going GA to MCP connectors in Cortex Agents – signals that this isn’t experimental anymore. The question isn’t whether to connect your data to AI agents, but how broadly you want that connection to reach.