How to use Claude with Snowflake
Connect Claude or ChatGPT to your Snowflake warehouse: the exact role, user, warehouse and grants to create, key-pair auth, and what to do so the answers are actually right.
Connecting Claude to Snowflake is a twenty-minute job. Getting it to return numbers your team will actually trust is the part worth planning.
This walks through both: the exact Snowflake objects to create and grants to run, then what to do afterwards so the answers hold up.

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;
The FUTURE grants are the two people forget. Without them, a table created next month is invisible, and the symptom is "Claude says that table doesn't exist" long after anyone remembers running this script.
They are also a decision, not a formality: FUTURE means anything landing in this schema is automatically readable. If the schema is a curated analytics layer, that is what you want. If it is a landing zone where raw exports arrive, grant explicitly instead.
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.
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 genuinely 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.
What this looks like in practice
Evana, a trade compliance company, connected their Snowflake warehouse and clawed back around 20 hours a week previously spent on data wrangling. Their team went from pasting CSVs into Claude, and hitting its upload limits, to asking live questions against the warehouse.
Tilt runs around 6,000 queries a month across most of the company on the same setup, with a one-person data team.