Snowflake
Arcade Optimized
Query Snowflake as the person who signed in, using their own role
7tools
7require secrets
The Arcade Snowflake toolkit connects agents to a Snowflake account for schema discovery and read-only querying. Each person signs in to Snowflake themselves, and every query runs as them, under their own role.
Capabilities
- Discovery with no IDs to pass in — the agent works its own way down: identity, then warehouses and databases, then schemas, then tables, then columns. Every listing shows only what that person's role is allowed to see, so the agent's map of the warehouse is already filtered.
- Read-only querying, enforced here — the query tool takes the parts of a query as separate fields instead of one block of SQL, puts them together, and runs it only if the whole thing is a
SELECT. Writes, DDL, role changes, and data movement are turned away before they reach Snowflake. - A role per person, not a shared login — there is no service account and no role set in configuration. Two people asking the same question can get different answers, and your existing Snowflake grants decide who sees what.
- Identity you can check — one tool reports the user, role, account, and warehouse a session is actually running as, so you can confirm the connection matches what you configured.
Setup
Most of the work is a one-time Snowflake and Arcade setup, done by whoever administers your Snowflake account.
- Create the auth provider. Create an OAuth security integration in Snowflake and register it in Arcade as a custom OAuth provider with the ID
snowflake. The Snowflake auth provider page has the SQL, the endpoints, and the exact dashboard steps. Creating the integration takesACCOUNTADMIN, or a role grantedCREATE INTEGRATION ON ACCOUNT, so involve that person early. - Set the account subdomain secret, described below.
- Give each person a role. Each user's
DEFAULT_ROLEis the role their sessions start in.DEFAULT_WAREHOUSEis optional: set it to save a step, or let the agent find a warehouse itself.
Each person then signs in to Snowflake once, through a link the agent hands them the first time they ask for data.
Secrets
Unlike the other database toolkits, there is no connection string and no stored password here. Every user's credentials come from their own Snowflake sign-in. The only secret this toolkit reads is an address.
SNOWFLAKE_ACCOUNT_SUBDOMAIN— the part of your Snowflake account URL before.snowflakecomputing.com, for examplemyorg-myaccountor the older stylexy12345.us-east-1. Pasting the whole account URL works too. Use the same form here as in the auth provider's endpoint URLs: a token only works against the host name it came from, so mixing them gets tokens rejected.
See the Arcade secrets guide for how to register secrets, and manage them at https://api.arcade.dev/dashboard/auth/secrets.
Available tools(7)
7 of 7 tools
Operations
Behavior
| Tool name | Description | Secrets | |
|---|---|---|---|
List the databases your role can access, newest-created first.
Snowflake returns only databases your current role is granted, so this is
already a per-user answer. Take a `name` and use it to list that database's
schemas. Use `name_pattern` to filter server-side rather than paging the
whole list. | 1 | ||
List the schemas in a database that your role can access.
List the databases first to get a valid `database`. Then take a schema
`name` and list that schema's tables. | 1 | ||
List the tables and views in a schema that your role can query.
List the schemas first to get a valid `database` and `schema_name`, then
load a table's columns before querying it.
Each row's `kind` is TABLE, VIEW, MATERIALIZED VIEW, or SEMANTIC VIEW. A
SEMANTIC VIEW cannot be read with an ordinary SELECT: it needs Snowflake's
SEMANTIC_VIEW(...) syntax, which this toolkit does not support, so skip
those when choosing something to query. | 1 | ||
List the warehouses your role can run queries on.
An account usually has several, and Snowflake returns only the ones your
current role is granted, so this is already a per-user answer.
You only need this when a query has no warehouse to run on, either because
you have no default or because you want a different one. `size` is the cost
signal: prefer the smallest warehouse that fits the query. A SUSPENDED
warehouse is still usable, since Snowflake resumes it on use by default. | 1 | ||
Run a read-only SELECT query and return the rows.
Only SELECT is allowed. Writes, DDL, role changes, and data movement are
rejected before the query reaches Snowflake, so this tool cannot modify
anything even if your Snowflake role would permit it.
The query runs under your own Snowflake identity, so your role and
Snowflake's row-access and masking policies decide what you can read. Two
users running identical SQL can legitimately get different results.
Load the table's columns before calling this, and name the columns you want
rather than selecting everything. `rows` is positional and
aligned to `columns`. `truncated` is true when more rows were available than
were returned.
Do not put LIMIT, OFFSET, or SQL comments in any clause; use the `limit` and
`offset` parameters, which are applied for you. | 1 | ||
Get a table or view's columns, so you can select exact fields.
Load this before running a query, and select named columns rather than
everything. Works on views as well as tables. A not-found error usually
means the object is not granted to your role; re-check the table listing. | 1 | ||
Return the Snowflake identity every other tool uses, and the warehouse.
The role is the important field. It is what decides which objects the other
tools can see and which rows and cells come back, so two people calling the
same tool with the same arguments can legitimately get different data.
Pass `current_warehouse` straight through as the warehouse argument when
running a query. If it comes back empty this user has no default warehouse,
and a query must name one. The warehouse discovery tool lists the ones this
role may use, cheapest first by `size`.
This is the only place identity is reported. It runs no caller-supplied SQL,
so what it returns is always the identity the other tools will run under. | 1 |
Last updated on