Snowflake MCP: connect Claude to Snowflake, and keep it read-only

Most MCP servers are a URL somebody else runs. Snowflake's is an object in your own account, sitting in a schema next to your tables, and it exposes nothing until you write it a specification.

That is the official route: the Snowflake-managed MCP server, generally available since 4 November 2025 (Snowflake release notes). You create it with SQL (CREATE MCP SERVER … FROM SPECIFICATION), list the tools it offers in YAML, and Claude reaches it at an endpoint inside your account:

https://<account_url>/api/v2/databases/<db>/schemas/<schema>/mcp-servers/<name>

You also name the tools yourself. Each one has a type (Snowflake docs, checked 22 October 2026):

A server holds at most 50 tools. Authentication is Snowflake OAuth by default, or External OAuth through Okta or Microsoft Entra ID. One detail catches people out: the server doesn't support dynamic client registration, so you create an OAuth security integration first and give Claude its client ID.

Snowflake's own recommendation is to put a single Cortex Agent in front of business users, rather than raw SQL. We agree, for reasons the rest of this page will make obvious.

You need a Snowflake admin for steps 1 to 4 and about half an hour. Everything below follows Snowflake's MCP server docs and Anthropic's custom connector help article.

1. Create a role just for MCP, and grant it only what Claude should see. Adapted from Snowflake's example (names illustrative):

CREATE ROLE mcp_analyst;
-- plus the Cortex database role your tool type needs, per Snowflake's docs
GRANT USAGE ON WAREHOUSE analytics_wh TO ROLE mcp_analyst;
GRANT USAGE ON DATABASE analytics TO ROLE mcp_analyst;
GRANT USAGE ON SCHEMA analytics.marts TO ROLE mcp_analyst;
GRANT SELECT ON SEMANTIC VIEW analytics.marts.revenue_sv TO ROLE mcp_analyst;
GRANT ROLE mcp_analyst TO USER jane_doe;

1. Create the server with the tools you want. Here, one tool over a semantic view (names illustrative):

CREATE MCP SERVER analytics.marts.claude_mcp
  FROM SPECIFICATION $$
tools:
  - name: "revenue-semantic-view"
    type: "CORTEX_ANALYST_MESSAGE"
    identifier: "analytics.marts.revenue_sv"
    description: "Revenue, churn and retention by plan and month"
    title: "Revenue questions"
$$;
GRANT USAGE ON MCP SERVER analytics.marts.claude_mcp TO ROLE mcp_analyst;

1. Create an OAuth security integration. For claude.ai, Snowflake recommends a public client with PKCE:

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

1. Copy the client ID with SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('CLAUDE_MCP_OAUTH');, and set each user's default role and default warehouse. Claude requests session:role:all, so the session runs as the user's DEFAULT_ROLE, and it fails without a warehouse.
2. Add the connector in Claude. On Pro or Max: Customize > Connectors > Add custom connector, then the name and the server URL, choose "Use your own OAuth client" and paste the client ID. On Team or Enterprise, an Owner adds it under Organization settings > Connectors and members connect individually. Free accounts get one custom connector.
3. Sign in, approve the consent screen, and test with a question whose answer you already know.

If your account uses network policies, Claude connects from Anthropic's cloud, not your laptop, so its outbound IP ranges need to be allowed.

A sentence in Snowflake's docs does a lot of work: "Access to the MCP Server does not give access to the tools. Permission needs to be granted for each tool." Use it. The checklist we'd run before anyone outside the data team connects:

• A dedicated role per server, never granted to PUBLIC, holding SELECT on the semantic views or marts Claude needs and nothing in raw or staging schemas.
• ALLOWED_ROLES_LIST restricted to that role and OAUTH_USE_SECONDARY_ROLES = NONE. Otherwise a user's other roles can come along for the ride.
• Check every connecting user's DEFAULT_ROLE. Because Claude asks for session:role:all, a user whose default role is SYSADMIN connects as SYSADMIN. This is the step people skip.
• Leave read_only: true on any SYSTEM_EXECUTE_SQL tool, and set query_timeout and a small warehouse so a runaway query has a ceiling.
• Keep direct SQL off the agent's server. Snowflake advises a separate server, with its own role, if analysts need raw SQL.
• Treat tool annotations as hints. Snowflake says plainly that they are "client-facing hints, not security controls". The role is the control.

In Claude, approve tools one at a time rather than clicking "Allow always" on anything that runs SQL. And note Anthropic's warning that in Research mode Claude "can invoke tools from your connectors automatically without further approval", so a read-only role matters most exactly when nobody is watching.

The best prompts against a warehouse ask for the query and the definition as well as the answer. These work with either a semantic-view tool or the SQL tool (examples illustrative; swap in your own names).

Start with what's there:

Using the Snowflake connector, list the tools you have and what each one can query.
Then describe the tables or semantic views behind the revenue tool: grain, date
columns, and any filters already applied. Don't answer a business question yet.

Ask a question with the definition pinned:

What was logo churn by plan for Q3 2026? Use the revenue semantic view. Before
answering, state the churn definition you're using (logo or revenue, gross or net),
the date column, and whether trials are excluded. Show the SQL that ran and the
row count it returned.

Make it explain a change without inventing a cause:

Net revenue retention fell between July and September. Break the change down by
plan and region using only query results. For each driver, show the query. If the
data can't explain part of the change, say so instead of suggesting a reason.

Ask for a reconciliation:

Calculate monthly recurring revenue for September two ways: from the semantic view
and from SELECT on the subscriptions mart. If the totals differ, find which rows or
filters explain the difference.

The last one is the most useful habit on this page. Two routes to the same number that disagree tell you more than either number alone.

Read-only stops Claude changing your data. It doesn't stop data leaving. The documented MCP incidents are almost all of the second kind.

• 1 April 2025: tool poisoning. Invariant Labs showed hidden instructions in a tool's description getting a model to read SSH keys and config files and pass them on, plus "rug pulls" (a description that changes after you approve it) and "shadowing" (one server's tool quietly altering how another's is used).
• 26 May 2025: GitHub MCP. A malicious public issue led an agent in Claude Desktop, with "Always Allow" on, to copy private-repository data into a public pull request (Invariant Labs). The server worked as designed; the agent had too much reach.
• 8 July 2025: Supabase MCP. A support ticket carrying hidden instructions led a coding agent, connected with a key that bypassed row-level security, to read a table of integration tokens and post it back into the ticket (General Analysis). Their first mitigation: run SQL as a read-only role. Their second, which matters more for a warehouse: keep secrets out of tables the assistant can read at all.

The pattern is the same each time. Untrusted text, a connection that can read something valuable, and a way to send it somewhere. Snowflake's server is first-party, so the tool-poisoning risk is mostly about the other connectors in the same Claude session. Don't run your warehouse connector alongside one that reads inbound tickets, public issues or web pages and can also post somewhere.

A connected warehouse fixes the freshness problem. It doesn't fix the meaning problem, and that's where most wrong answers from a warehouse come from.

Ask for churn and Claude has to choose. Logo or revenue churn can give 33% and 50% on the same three customers (ChartMogul's worked example), and gross revenue churn can't go negative while net can. Ask for monthly active users and it has to pick a calendar month or a rolling 30 days (Google Analytics uses rolling). Both choices produce valid SQL and a confident number.

Benchmarks show how hard real schemas are. In the original Spider 2.0 paper, the best agent solved 21.3% of enterprise text-to-SQL tasks against 91.2% on the academic Spider 1.0 (Lei et al., November 2024). Tuned agents now post far higher scores on the Snowflake-based set, but an audit found annotation errors in 62.8% of Spider 2.0-Snow items (Jin et al., January 2026). Even the answer key picks one reading of an ambiguous question. More on that in text-to-SQL.

This is why we'd point Claude at a semantic view through CORTEX_ANALYST_MESSAGE before we'd give it SYSTEM_EXECUTE_SQL. The definition lives in the view, written once by someone who knows the business, not re-guessed in every chat. The counter-argument is fair: semantic views take work, and they only cover what you've modelled. For questions outside them, direct SQL is the honest fallback, provided you read the query. See semantic layers for AI.

Claude shows each tool call it makes. Most people never expand them. Two minutes with them catches most of what goes wrong.

1. Open the tool call. Which tool ran: the semantic view, the agent or raw SQL? If raw SQL, read the FROM, the joins and the WHERE.
2. Find the grain. One row per customer, per subscription or per invoice? A join from customers to invoices that then counts rows is counting invoices.
3. Check the date logic. Which column, which time zone, inclusive or exclusive end date, calendar or rolling window.
4. Compare the row count with what you expect. A count of zero, or a suspiciously round one, means a filter or limit is doing more than you think.
5. Ask Claude to separate its sources: "Which figures came from a query result, and which did you infer or assume?" Then check the second list.

For anything heading to a board pack, Count does this more thoroughly. Connect Count's MCP server to Claude alongside Snowflake and ask it to audit the answer. It replies with a link to a canvas where each claim is labelled (Citation, Assumption, Model knowledge or Hallucination) and sits on a reasoning chain showing the prompt, each query and calculation, and the result it rests on. A churn figure built on an unstated definition shows up as an Assumption. And because the canvas connects to Snowflake itself, you can open the query, change the definition and re-run it in the same place.

Does Snowflake have an official MCP server?

How do I connect Claude to Snowflake?

Can Claude write to Snowflake through MCP?

What tools does the Snowflake MCP server expose?

Should Claude use Cortex Analyst or raw SQL?