Skip to content

Connect Snowflake

Connecting Snowflake lets the agents work against your real account: catalog and lineage answers from your actual schemas, quality scoring on your tables, cost analysis from ACCOUNT_USAGE, NL-to-SQL insights, and — if you later enable write-scoped credentials — governed schema and access changes. Until then it stays in 🟡 Evaluation on sample data.

  • Data Workers installed and registered with your coding agent (install guide)
  • Permission to create a role and user in your Snowflake account (or someone who can)
  • Your Snowflake account identifier and a warehouse the agents may use

Step 1 — Create a least-privilege credential

Section titled “Step 1 — Create a least-privilege credential”

Create a dedicated read-only role and service user. Read agents can never mutate your systems, so read-only is enough to start — never widen this credential to add write later; write uses a separate credential (least-privilege guidance).

CREATE ROLE DATA_WORKERS_RO;
GRANT USAGE ON WAREHOUSE <warehouse> TO ROLE DATA_WORKERS_RO;
GRANT USAGE ON DATABASE <database> TO ROLE DATA_WORKERS_RO;
GRANT USAGE ON ALL SCHEMAS IN DATABASE <database> TO ROLE DATA_WORKERS_RO;
GRANT SELECT ON ALL TABLES IN DATABASE <database> TO ROLE DATA_WORKERS_RO;
-- Optional, for cost and query-history analysis:
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE DATA_WORKERS_RO;

Start with one database, verify, then widen scope.

Checkpoint: a service user exists with DATA_WORKERS_RO as its role and nothing more.

Set these in the shell your coding agent launches from, then restart the coding agent so the MCP server picks them up. Credentials stay on your machine; they are never sent to Data Workers.

Terminal window
export SNOWFLAKE_ACCOUNT="<account-identifier>"
export SNOWFLAKE_USERNAME="<service-username>"
export SNOWFLAKE_PASSWORD="<password>"
export SNOWFLAKE_WAREHOUSE="<warehouse>"
export SNOWFLAKE_DATABASE="<database>"

Checkpoint: the variables are visible in the environment your coding agent starts from.

Setting a credential is not the same as a working connection. Ask:

Test the connection to my Snowflake catalog.

The agent makes a real call to your account. Snowflake shows 🟢 Connected only after that live test passes; a failure reports 🔴 with the reason. Full model: Verify your setup.

Checkpoint: Snowflake reports 🟢 Connected.

OperationStatus
Discovery (schemas, tables, assets)Supported
Catalog writes (create/update/drop objects)Supported — write-scoped credential required
RBAC (role-based access enforcement)Supported
Policy attachment and enforcementSupported
Credential vending (scoped, time-bound tokens)Not supported — use Snowflake storage integrations instead

Unsupported operations return a clear error naming the connectors that do support them — never a pretend success.

SymptomLikely causeFix
Still answering from sample dataVariables set in a different shell, or agent not restartedSet them in the shell your coding agent launches from, restart it
🔴 with an auth errorWrong password, or the user lacks the read roleRe-check the credential and the Step 1 grants
🔴 with a network/timeout errorHost can’t reach Snowflake (VPN, allowlist, private link)Run the agents from a host with network access, or allowlist it
Cost questions come back emptyNo access to SNOWFLAKE.ACCOUNT_USAGEAdd the optional IMPORTED PRIVILEGES grant from Step 1