How to connect Claude to Snowflake and get started in minutes? No Snowflake engineering needed

You can have Claude answering questions against your Snowflake warehouse in minutes. There is no pipeline to build, no modeling project, and no data engineering team involved. A Snowflake admin runs about ten lines of SQL, you add the connection, and your team asks in the Claude they already use.

Getting it connected is the quick part. Getting numbers your team will trust takes one more pass, and this guide covers both.

The quick path

In order, with rough times:

1. Create a role, user and warehouse (an admin, about five minutes). Copy-paste SQL below.
2. Grant read access to the schemas you want Claude to see (two minutes).
3. Add a key pair to the new user instead of a password (five minutes).
4. Add Snowflake as a data source in Contextflo and pick your tables (a few minutes).
5. Add Contextflo to Claude as a custom connector in settings, then ask a first question.

That gets you live. The step that takes longer, and is worth it, comes after: reading the generated table descriptions once and correcting what the schema couldn't tell the model. Budget a couple of hours of someone who knows the business, not a sprint.

Who is already doing this

Two teams on Snowflake, neither with a data engineering team behind the rollout:

• Tilt, a live-auction marketplace for limited-edition goods, had one full-stack data scientist, and every data question landed on that person. A year after connecting Claude to Snowflake through Contextflo, the team runs about 6,000 queries a month, with 30+ people asking every week, and answers come back in minutes instead of days. The longer version is in how Tilt rolled it out.
• Evana, which helps e-commerce merchants recover overpaid import duties, used to pull CSVs out of Snowflake and paste them into Claude. In their words, "Contextflo connected Claude to Evana's Snowflake in minutes. The setup: point Contextflo at the warehouse, sync the tables, connect Claude." Operations and client-facing teams now query the data directly, around 20 hours a week of data wrangling came back, and they made 0 data hires to get there.

What you are building

Claude cannot talk to Snowflake on its own. Something has to sit in between that holds the credentials, exposes the schema, runs the SQL and returns results. That is what an MCP server does.

Contextflo is that layer, plus the part a bare connector does not give you: the context that tells the model what your tables mean, and per-user controls over what each person can reach.

The shape:

Claude or ChatGPT → Contextflo (context + ACL + audit) → Snowflake

Step 1: Create a dedicated role, user and warehouse

Do not reuse a human's Snowflake login. A dedicated role makes the blast radius explicit and means you can revoke access in one statement.

Run this as an account admin, changing the database and schema at the top:

SET CF_DATABASE = 'YOUR_DATABASE';
SET CF_SCHEMA = 'YOUR_DATABASE.YOUR_SCHEMA';

-- 1. Role
USE ROLE SECURITYADMIN;
CREATE ROLE IF NOT EXISTS CONTEXTFLO_ROLE;
GRANT ROLE CONTEXTFLO_ROLE TO ROLE SYSADMIN;

-- 2. User
CREATE USER IF NOT EXISTS CONTEXTFLO_USER
  DEFAULT_ROLE = CONTEXTFLO_ROLE
  DEFAULT_WAREHOUSE = CONTEXTFLO_WAREHOUSE;

GRANT ROLE CONTEXTFLO_ROLE TO USER CONTEXTFLO_USER;

-- 3. Warehouse
USE ROLE SYSADMIN;
CREATE WAREHOUSE IF NOT EXISTS CONTEXTFLO_WAREHOUSE
  WAREHOUSE_SIZE = 'XSMALL'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE;

GRANT USAGE ON WAREHOUSE CONTEXTFLO_WAREHOUSE TO ROLE CONTEXTFLO_ROLE;

A separate XSMALL warehouse with a 60-second auto-suspend is deliberate. It keeps AI query spend on its own line item instead of buried in whatever warehouse your dbt runs use, so if usage climbs you can see it immediately rather than at the end of the month.

Step 2: Grant read access, including on future objects

GRANT USAGE ON DATABASE IDENTIFIER($CF_DATABASE) TO ROLE CONTEXTFLO_ROLE;
GRANT USAGE ON SCHEMA IDENTIFIER($CF_SCHEMA) TO ROLE CONTEXTFLO_ROLE;

GRANT SELECT ON ALL TABLES IN SCHEMA IDENTIFIER($CF_SCHEMA) TO ROLE CONTEXTFLO_ROLE;
GRANT SELECT ON ALL VIEWS IN SCHEMA IDENTIFIER($CF_SCHEMA) TO ROLE CONTEXTFLO_ROLE;
GRANT SELECT ON FUTURE TABLES IN SCHEMA IDENTIFIER($CF_SCHEMA) TO ROLE CONTEXTFLO_ROLE;
GRANT SELECT ON FUTURE VIEWS IN SCHEMA IDENTIFIER($CF_SCHEMA) TO ROLE CONTEXTFLO_ROLE;

Verify with SHOW GRANTS TO ROLE CONTEXTFLO_ROLE; before moving on.

Scope this to the schemas you actually want exposed. One schema is a fine place to start, and adding a second later is two statements.

Step 3: Use key-pair auth

Snowflake supports RSA key-pair authentication, and it is a straight upgrade over a password: nothing reusable is stored, and rotation does not require coordinating a password change.

Generate a key pair, then:

ALTER USER CONTEXTFLO_USER SET RSA_PUBLIC_KEY='MIIBIj...';

Verify with DESC USER CONTEXTFLO_USER; and look for RSA_PUBLIC_KEY_FP.

Snowflake accepts a password and a key on the same user simultaneously, so you can add the key, confirm the connection works, and only then run ALTER USER CONTEXTFLO_USER UNSET PASSWORD;. No downtime, no window where the connection is broken.

Step 4: Connect and pick your tables

In Contextflo, add a Snowflake data source with the account identifier, warehouse, role, user and key. The connection is tested before anything is saved, so a bad credential fails immediately rather than half-configuring.

Then choose which databases, schemas and tables to include. Start with the ten or fifteen tables that answer most questions rather than everything the role can see. A smaller, well-described set beats a complete but ambiguous one, every time.

Last, add Contextflo to Claude as a custom connector in Claude's settings (or to ChatGPT, if that is what your team uses). From there, anyone you have given access can ask questions in the chat window they already have open.

Step 5: Generate context, then correct it

This is the step that determines whether the whole thing works.

Contextflo reads the schema, plus source code and docs you point it at, and generates table descriptions, column meanings, relationships and metric definitions. It re-syncs the schema daily, so new and changed tables show up without a manual re-import. That draft is usually right about structure and regularly wrong about meaning, because nothing in a schema records that status = 'C' means cancelled rather than complete, or that orders before the 2024 migration use a different vocabulary.

Someone who knows the business should read it once. Two hours here is the difference between a tool people trust and one they quietly stop using after the first wrong number.

Then define the handful of metrics that get argued about: active user, revenue, churn. Defined once, they resolve the same way for everyone.

Step 6: Ask something you already know the answer to

The first question should be one where you know the right answer. Revenue for last month, or signups last week. Check it against a number you trust.

If it is wrong, the execution logs show the SQL that ran, and the fix is almost always a missing definition rather than a model problem. Fix that, and the same class of question is right from then on.

What about Cortex Analyst?

If you are on Snowflake, Cortex Analyst is the obvious alternative and worth taking seriously. It runs entirely inside Snowflake, uses your existing roles, and CoWork gives it a good chat app.

The tradeoffs are that you author and maintain semantic models by hand, it only ever covers Snowflake data, and your team asks questions in Snowflake's interface rather than the AI tool they already have open. If your company is all-in on Snowflake and has an analytics engineer, that is a reasonable trade.

We wrote the full comparison in Snowflake Cortex and CoWork vs Contextflo rather than repeating it here. If you are weighing more than those two, Snowflake Cortex Analyst alternatives compares twelve options on data sources, pricing and who writes the context.

Here is a more in-depth look at Contextflo and how it works.