Snowflake MCP Server: Managed Setup, Tools, Access

Snowflake's MCP server is not a package you install. It is an object you create inside your Snowflake account with CREATE MCP SERVER, and it serves Cortex Analyst, Cortex Search, Cortex Agents, SQL and your own functions to MCP clients over OAuth. The community server in Snowflake-Labs/mcp is deprecated. We checked Snowflake's docs on 31 October 2026.

Quick facts

Which server is which

Search results show two Snowflake servers, which causes confusion.

The old README opens with a caution: "This project is deprecated and no longer maintained. Please migrate to the official Snowflake MCP Server." It had Cortex Search, Cortex Analyst, Cortex Agent, object management, SQL execution and semantic view querying. It is kept for reference, so do not start new work on it.

What it does

Snowflake says the managed server "lets AI agents securely retrieve data from Snowflake accounts without needing to deploy separate infrastructure." You define a server as a list of tools. A client connects, authenticates, discovers the tools and calls them.

Snowflake lists three benefits: a standard interface for tool discovery and invocation, comprehensive authentication with Snowflake OAuth by default, and governance through role-based access control for the server and each tool.

Tool types

Snowflake's advice for business data apps is to expose a Cortex Agent as the client-facing tool. You configure the agent with the Analyst, Search and custom tools it needs, then let the MCP client talk to the agent. The client sees one governed interface and the agent chooses resources. Expose Analyst or Search directly only when you want the client to choose those resources itself. A directly exposed Analyst tool only returns SQL. It does not run it.

Create a server

CREATE OR REPLACE MCP SERVER my_db.my_schema.business_mcp
  FROM SPECIFICATION $$
  tools:
    - title: "Governed business data agent"
      name: "business_data_agent"
      type: "CORTEX_AGENT_RUN"
      identifier: "my_db.my_schema.my_agent"
      description: "Use this agent for governed business data questions."
  $$;

That is Snowflake's own example, with names changed. The description matters. The client picks a tool from its name and description, so use precise, domain-specific wording when you expose several.

For GENERIC and CORTEX_AGENT_RUN tools you can set annotations: readOnlyHint, destructiveHint, idempotentHint and openWorldHint. The defaults are cautious: not read-only, destructive, not idempotent, open world. Snowflake adds a warning worth repeating: "Tool annotations are client-facing hints, not security controls." Use RBAC for control.

Access control

Two privileges at the server level, and then privileges on each underlying object.

Snowflake says: "Access to the MCP Server does not give access to the tools. Permission needs to be granted for each tool." That is good design and easy to miss. Build a dedicated role for agents, give it USAGE on the server, and add only the object privileges the tools need.

Authentication

Clients authenticate with OAuth 2.0, aligned with the MCP authorization recommendation. The steps from the docs:

1. Create a security integration with CREATE SECURITY INTEGRATION, TYPE = OAUTH, OAUTH_CLIENT = CUSTOM.
2. Choose OAUTH_CLIENT_TYPE = 'CONFIDENTIAL' for clients that can hold a secret, such as VS Code or Cursor. Choose 'PUBLIC' with PKCE for clients that cannot, such as Claude Desktop.
3. Set OAUTH_REDIRECT_URI to the URI your client shows.
4. Give your client the client ID and secret, and the server URL.

One integration can serve every user in the account. Each user still signs in with their own credentials. By default the session uses the user's DEFAULT_ROLE. Secondary roles are controlled by the integration, and Snowflake's recommended MCP setup leaves them off with OAUTH_USE_SECONDARY_ROLES = NONE. For stricter identity control you can bind to External OAuth with Okta or Microsoft Entra ID.

If your account uses PrivateLink and you connect from a SaaS client such as Claude.ai or ChatGPT, use the public MCP URL and set USE_PRIVATELINK_FOR_AUTHORIZATION_ENDPOINT = TRUE on the integration. Use hyphens, not underscores, in hostnames, since underscores break connections.

What it costs

We found no charge for the MCP server object on the page we read. Costs come from what the tools do: warehouse compute for SQL, and Cortex services for Analyst, Search and Agents. We did not read the credit rates, so check Snowflake's pricing page for them. Snowflake does warn about one cost trap. A Cortex Agent tool that calls another MCP server that calls back into a Cortex Agent can loop, and Snowflake enforces a maximum recursion depth of 10 invocations.

Install it in each agent

Snowflake's page documents Claude (claude.ai and Desktop), ChatGPT and Cursor, plus any client with remote HTTP support. For the agents on our list, these are our adaptation. See MCP clients for how agents name fields.

Cursor

From Snowflake's page, in ~/.cursor/mcp.json or .cursor/mcp.json:

{
  "mcpServers": {
    "snowflake": {
      "url": "https://<account_url>/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<name>",
      "auth": {
        "CLIENT_ID": "${env:MCP_CLIENT_ID}",
        "CLIENT_SECRET": "${env:MCP_CLIENT_SECRET}"
      }
    }
  }
}

Then open Cursor Settings, MCP, and choose Sign in.

Claude Code

Our adaptation:

claude mcp add --transport http \
  --client-id YOUR_CLIENT_ID --client-secret \
  --callback-port 8080 \
  snowflake "https://<account_url>/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<name>"

The --client-id, --client-secret and --callback-port options are the ones Claude Code's MCP docs give for pre-registered OAuth: --client-id passes the client ID, --client-secret prompts for the secret, and --callback-port must match a redirect URI of the form http://localhost:PORT/callback. Set the integration's redirect URI to http://localhost:8080/callback. Snowflake's page says its managed server does not support dynamic client registration, so these flags are the way in.

Codex

Our adaptation, in ~/.codex/config.toml:

[mcp_servers.snowflake]
url = "https://<account_url>/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<name>"
bearer_token_env_var = "SNOWFLAKE_PAT"

bearer_token_env_var is the field Codex's docs give for a bearer token. Snowflake's page mentions Programmatic Access Tokens only in its security notes, advising a least-privileged role, and does not say the managed server accepts one as a bearer token. Treat this entry as untested, and prefer the OAuth route Snowflake documents.

Antigravity

Our adaptation. In ~/.gemini/config/mcp_config.json, under mcpServers, put the URL in serverUrl. For servers without dynamic client registration, Antigravity's docs accept clientId and an optional clientSecret in an oauth object, with https://antigravity.google/oauth-callback registered as the redirect URI. We did not test that against Snowflake. Gemini CLI is now Code Assist enterprise only.

OpenCode

Our adaptation, in opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "snowflake": {
      "type": "remote",
      "url": "https://<account_url>/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<name>",
      "oauth": {
        "clientId": "{env:MCP_CLIENT_ID}",
        "clientSecret": "{env:MCP_CLIENT_SECRET}"
      }
    }
  }
}

The oauth fields clientId and clientSecret match OpenCode's docs, and opencode mcp auth snowflake starts the browser sign-in.

Choosing tools for a first server

A short, sensible starting set follows from Snowflake's own advice.

Start with one tool, test it as the agent role, and add more later. Keeping the tool count low also helps the client choose well, which Snowflake says can drop when counts rise.

Network policies

If your account uses network policies, you must allow inbound connections from your MCP client's outbound IPs. Remote clients such as Claude, ChatGPT and Cursor connect from their vendors' infrastructure, so you need those addresses on the allow list. For a local agent, your own IP matters. This is a common cause of connection failures, along with underscores in hostnames.

Security notes

Snowflake's own recommendations are the best list:

• Use OAuth, not hardcoded tokens, which can leak.
• Least privilege for PATs. A PAT should use the least-privileged role that can work with MCP.
• Per-tool permissions. Server access is not tool access.
• Third-party servers. Verify tools and descriptions on any MCP server from another user or account. Snowflake names tool poisoning and tool shadowing as risks when you use several servers.
• Loops. Avoid circular invocation between agents and servers.
• Annotations are hints. They do not enforce anything.
• SQL tool. SYSTEM_EXECUTE_SQL runs queries without agent orchestration. Whatever role the session has is what it can do. Give it a read-only role for analysis.
• Data leaves the account. Results go to the client and model provider. Use masking policies and row access policies so that the session role sees only what it should.
• Sharing. Snowflake's page refers to sharing managed servers with other accounts as a limited-access feature, and says MCP server objects are not replicated in failover groups.

Limits and known issues

• Maximum of 50 tools per server. Snowflake notes more tools can degrade tool-selection accuracy.
• Responses from generic and SQL tools are truncated at 250 KB.
• Resources, prompts, roots, notifications, version negotiation, lifecycle phases and sampling are not supported.
• Protocol revision is 2025-11-25. Newer clients that expect later revisions may behave differently. We did not check later protocol revisions.
• Not available in the People's Republic of China. Government regions are covered with exceptions, and FedRAMP assessment is not complete, so ask your account team.
• Replication does not copy MCP server objects. Recreate them on the secondary account. OAuth integrations replicate.
• We did not read Snowflake's release notes for further feature gaps.

Alternatives

Grafana's SQL tools list Snowflake as one of the aliases for its SQL category, so a Grafana datasource can reach Snowflake. That is a different route with different controls.

Our take

Snowflake's design stands out in one way. The server is part of the account's access model. You create it with SQL, grant it like any object and audit it like any object. There is nothing to host and no password to paste into a config file. For a data team that already runs governance in Snowflake, that is the right shape.

The cost is that setup is an administrator's job. You need CREATE rights, a security integration and the client's redirect URI. A solo developer without those rights may find it slow. Also, Snowflake's quick advice is to put a Cortex Agent in front of everything, which ties you to Cortex. If you want plain SQL, use SYSTEM_EXECUTE_SQL with a read-only role.

This is our reading of the documentation, not a hands-on test.

A short setup checklist

1. Check your region and network policy.
2. Pick a database and schema for the server object.
3. Create the MCP SERVER with the smallest useful tool set.
4. Create a dedicated role and grant USAGE on the server and each tool's object.
5. Create the OAuth security integration with the right client type and redirect URI.
6. Add the URL to your agent and sign in.
7. Test a read query as the agent role.
8. Check the query history afterwards.

See also the MCP server list and best MCP servers.

Frequently asked questions

What is the Snowflake MCP server?

A managed server you create in your account with CREATE MCP SERVER, serving Cortex tools, SQL and custom tools.

Is the Snowflake-Labs/mcp server still maintained?

No. It is deprecated.

How do clients authenticate?

With OAuth 2.0. Snowflake OAuth by default, External OAuth optional.

Does access to the server give access to its tools?

No. Each tool's underlying object needs its own grant.

How many tools can one server have?

Up to 50.