Snowflake MCP server: setup, tools, RBAC and cost

Most questions people want to ask Claude about the business end in Snowflake: revenue by segment, churn last quarter, which customers stopped ordering. The Snowflake MCP server lets an AI client ask those questions directly, through Cortex and SQL, with Snowflake's own access control deciding what each person can see. This guide covers how the server works, how to create and lock it down, how to connect Claude and Cursor, and what it costs. If MCP is new to you, start with what an MCP server is.

Facts are from Snowflake's documentation as of October 2026.

What the Snowflake MCP server is

The Snowflake-managed MCP server is generally available and maintained by Snowflake. Three things set it apart from most MCP servers:

• It runs inside your Snowflake account. It is not a separate service you host. You create it as an object in a schema, the same way you create a view or a stage.
• You define the tools. The server exposes exactly the tools listed in its specification, nothing more.
• Every call runs under the user's role. Snowflake RBAC applies to each tool call, so the agent cannot read a table the person could not query themselves.

An older open-source server lived in the Snowflake-Labs/mcp repository and ran locally with uvx. Its README now says it is deprecated and no longer maintained and points to the managed server. If you find a tutorial using snowflake-labs-mcp, it is out of date.

The tools you can expose

Each tool in the specification has a type:

For most business users, Cortex Analyst over a well-defined semantic view is the tool that matters. It answers "what was revenue in the Nordics last quarter?" against definitions your data team controls, instead of letting the model guess which column means revenue. Raw SQL is the power-user tool; keep it read-only.

Creating the server

The server is created from a YAML specification:

CREATE MCP SERVER analytics.mcp.sales_mcp
  FROM SPECIFICATION $$
tools:
  - title: "Sales analyst"
    name: "sales_analyst"
    type: "CORTEX_ANALYST_MESSAGE"
    identifier: "analytics.semantic.sales_view"
    description: "Answers questions about orders, revenue and customers."
  - title: "Read-only SQL"
    name: "run_sql"
    type: "SYSTEM_EXECUTE_SQL"
    description: "Runs SELECT queries against approved schemas."
    config:
      read_only: true
      warehouse: "MCP_WH"
$$;

The descriptions are what the model reads when deciding which tool to call, so write them for the model: what the tool answers, and what it does not.

The endpoint for this server is then:

https://<account_url>/api/v2/databases/analytics/schemas/mcp/mcp-servers/sales_mcp

Use hyphens, not underscores, in the account hostname. Snowflake's docs call out underscores as a cause of failed connections.

Grants

Creating the server needs the CREATE MCP SERVER privilege. Connecting needs USAGE on the server object, plus the privileges each tool needs underneath it (for example SELECT on the semantic view, or USAGE on the search service or agent). Snowflake's documented grants for a role that uses the server:

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_AGENT_USER TO ROLE mcp_role;
GRANT USAGE ON WAREHOUSE mcp_wh TO ROLE mcp_role;
GRANT USAGE ON DATABASE analytics TO ROLE mcp_role;
GRANT USAGE ON SCHEMA analytics.mcp TO ROLE mcp_role;
GRANT USAGE ON MCP SERVER analytics.mcp.sales_mcp TO ROLE mcp_role;

Create a dedicated, least-privileged role for MCP use rather than letting people connect with a broad analyst or admin role. A separate warehouse (MCP_WH above) also makes the compute cost of agent queries visible on its own line.

Connecting Claude

Snowflake OAuth is the default authentication. For Claude (claude.ai and Claude Desktop), create a security integration with Claude's callback URL and restrict it to the MCP role:

CREATE SECURITY INTEGRATION claude_mcp
  TYPE = OAUTH
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'PUBLIC'
  OAUTH_REDIRECT_URI = 'https://claude.ai/api/mcp/auth_callback'
  OAUTH_USE_SECONDARY_ROLES = NONE
  ALLOWED_ROLES_LIST = ('MCP_ROLE')
  ENABLED = TRUE;

Then in Claude, open Settings → Connectors, add a custom connector with the server URL, and enter the OAuth client ID and secret from the integration. ALLOWED_ROLES_LIST and OAUTH_USE_SECONDARY_ROLES = NONE together make sure a session through Claude only ever has the MCP role, never a user's other roles.

External OAuth (Okta, Microsoft Entra ID) is also supported, and so is a programmatic access token (PAT) for non-interactive use. A PAT is a long-lived secret, so scope it to the MCP role and give it an expiry.

Connecting Cursor and Claude Code

Cursor reads remote servers from ~/.cursor/mcp.json; add the server URL there and complete the OAuth login. Snowflake documents this setup alongside Claude and ChatGPT.

Claude Code connects to remote MCP servers by URL, so the same endpoint works:

claude mcp add --transport http snowflake \
  https://<account_url>/api/v2/databases/analytics/schemas/mcp/mcp-servers/sales_mcp

Snowflake does not publish a Claude Code-specific walkthrough, so treat the OAuth flow there as something to test with your security integration. Our Claude Code MCP guide covers adding remote servers and headers in general.

Limits

• At most 50 tools per MCP server.
• Responses from GENERIC and SQL tools are truncated at 250 KB.
• Maximum recursion depth of 10 invocations.
• MCP server objects are not replicated in failover groups, so recreate them in a secondary account as part of your failover plan.

What it costs

Snowflake does not document a separate fee for the MCP server object. The cost is in what the tools use:

• Cortex Agents: AI credits per million tokens.
• Cortex Analyst: billed per 1,000 messages when called directly, or as tokens when called through an agent, plus warehouse compute for the SQL it runs.
• Cortex Search: credits per GB per month for serving, plus per-token embedding.
• SQL: normal warehouse compute.

If you need inference kept in a region, Snowflake's cross-region inference settings let you choose regional routing (for example within Azure EU), priced slightly above global routing. Check Snowflake's Cortex pricing page for current rates, and watch the MCP warehouse: an agent asking twenty exploratory questions runs twenty queries.

Safe use in a company

The Snowflake side of this is well designed: tools you define, read-only SQL by default, RBAC on every call, and data that stays in your account. The parts Snowflake cannot control are on the client side:

• Where the answers go. Query results become part of the model's context, and the AI client sends them to its model provider. For personal or sensitive data, that is the transfer your DPO needs to know about.
• What else is in the session. A session with Snowflake results and an email or Slack tool can send data out of the company. Keep those apart or require approval, as described in MCP security best practices.
• Semantic views first. The more questions go through Cortex Analyst over curated definitions, the fewer go through free-form SQL, and the more consistent the answers.

Running Snowflake next to the CRM, ticketing and the other approved servers, with one policy and one log, is the job of an MCP gateway. Walma AI Hub does that inside the customer's own Azure tenant in an EU region, with every model available. The data-team version of that setup is in our MCP directory.