Snowflake
Tools to query and explore Snowflake with per-user, per-role access
1.0.4Snowflake Toolkit
Arcade's Snowflake toolkit lets agents query and explore Snowflake data warehouses with per-user, per-role access — every operation runs under the authenticated user's own Snowflake identity, so role grants and row-access/masking policies are enforced automatically.
Capabilities
- Schema discovery: Browse databases, schemas, tables, views, and materialized views the user's role can access; server-side name-pattern filtering avoids paging large catalogs.
- Column inspection: Retrieve a table or view's column definitions before querying, enabling precise column selection instead of
SELECT *. - Read-only query execution: Run
SELECTstatements with parameterizedlimit/offset; writes, DDL, role changes, and data movement are blocked before the query reaches Snowflake. - Warehouse discovery: List warehouses the role may use (sorted by size as a cost signal); suspended warehouses are still usable since Snowflake auto-resumes them.
- Identity introspection: Report the active Snowflake role and default warehouse, explaining why two users can get different results from identical SQL.
OAuth
This toolkit authenticates via OAuth 2.0 with Snowflake as the provider. Each tool call runs under the individual user's Snowflake identity — role assignments, row-access policies, and column-masking policies all apply as they would in any direct Snowflake session.
Secrets
SNOWFLAKE_ACCOUNT_SUBDOMAIN— The account identifier subdomain for your Snowflake organization. Snowflake account URLs follow the pattern<account_subdomain>.snowflakecomputing.com; the value you supply here is the<account_subdomain>portion. You can find this in the Snowflake web UI under Admin → Accounts (hover over your account name to see the full locator), or it is displayed in the URL when you log in. For accounts in the default AWS US-East region it is typically the legacy account locator (e.g.xy12345); for accounts in other regions or on other clouds it includes the region and cloud segments (e.g.xy12345.us-east-2.aws). See Snowflake's account identifier documentation for the full format rules.
Configure secrets in the Arcade dashboard or via the API: https://docs.arcade.dev/en/guides/create-tools/tool-basics/create-tool-secrets (secrets can also be managed at https://api.arcade.dev/dashboard/auth/secrets).
Available tools(7)
| 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 |