Espresso AI

Read. Snowflake Scheduler Agent settings: whether it is on, per-warehouse scheduling (enabled, routing pool, max extra warehouses), routing pools, and the never-route-to list. Example: {customer: "acme"}.

get_snowflake_scheduler_settings

Read. Snowflake Warehouse Agent settings: whether the agent is on, whether new warehouses are opted in automatically, and each warehouse's enabled flag, cluster bounds and scaling policy. Example: {customer: "acme"}.

get_snowflake_warehouse_agent_settings

Read. What to create in Snowflake so Espresso can connect: `spec` lists the user, role, warehouse, grants and user parameters, with Espresso's public key and a `comment` that must be set on the user exactly as given; `sql` is that spec as a ready-to-run script; `preflightSql` checks what already exists and which role is current; `networkPolicyIps` must be allowed if the account has a network policy. Build Terraform or other infrastructure-as-code from `spec`, not by translating `sql`. Changes nothing. Example: {}.

get_snowflake_setup

Read. Recent settings changes, newest first: what changed, the old and new values, notes, and when. `since` is a date (2026-10-01) or a relative window (-7d); default -28d. `warehouse` narrows to one warehouse. Example: {customer: "acme", warehouse: "ANALYTICS_WH", since: "-7d"}.

get_settings_history

Read. List the accounts you can manage, with each account's product (snowflake or databricks). Every other tool takes one of these slugs as `customer`. Example: {}.

list_accounts

Mutating (idempotent): on an existing account it converts a prospect and replaces the stored credentials. After the setup from get_snowflake_setup exists in Snowflake, connect to the account as Espresso and register it. `account` is the account URL or identifier, e.g. https://myorg-myaccount.snowflakecomputing.com or myorg-myaccount. Nothing is registered until every entry in `checks` passes; a failing check carries a `code` and a `fix`. Safe to call again after fixing, or later once an infrastructure-as-code change is applied. On success it returns the new `customer` slug, and Espresso follows up with a savings estimate. Example: {account: "myorg-myaccount"}.

register_snowflake_account

Mutating (idempotent). Turn the Snowflake Scheduler Agent on or off. It can only be on while the Warehouse Agent is on. Previews by default: dry_run=true returns the diff and the current `versions` without changing anything. To apply, call again with dry_run=false and those `versions` as expected_versions. `notes` is recorded in the settings history. Example: {customer: "acme", enabled: true, notes: "Start scheduling"}.

set_snowflake_scheduler

Mutating (idempotent). Turn the Snowflake Warehouse Agent on or off, or set whether new warehouses are opted in automatically. Turning the agent off also puts the Scheduler Agent in dry run. Previews by default: dry_run=true returns the diff and the current `versions` without changing anything. To apply, call again with dry_run=false and those `versions` as expected_versions. `notes` is recorded in the settings history. Example: {customer: "acme", enabled: false, notes: "Pausing during migration"}.

set_snowflake_warehouse_agent

Mutating (idempotent). Change Snowflake warehouses' Scheduler Agent settings: packer_on, routing_pool, max_extra_warehouses. Only the fields you pass change. Previews by default: dry_run=true returns the diff and the current `versions` without changing anything. To apply, call again with dry_run=false and those `versions` as expected_versions. `notes` is recorded in the settings history. Example: {customer: "acme", changes: {"BI_WH": {packer_on: true, routing_pool: "BI"}}, notes: "Route BI queries"}.

update_snowflake_scheduler_warehouses

Mutating (idempotent). Set Snowflake routing: `pools` replaces the whole list of routing pools (a pool you leave out is deleted, and one still assigned to a warehouse can't be), and `never_route_to` replaces the list of warehouses the Scheduler never routes queries to. Pass either or both. Previews by default: dry_run=true returns the diff and the current `versions` without changing anything. To apply, call again with dry_run=false and those `versions` as expected_versions. `notes` is recorded in the settings history. Example: {customer: "acme", pools: [{name: "BI"}, {name: "ETL"}], notes: "Add ETL pool"}.

update_snowflake_routing