AI dashboards for Snowflake, built by agents you control

AI dashboards for Snowflake, in dvt, means an agent queries your tables over MCP, writes SQL against your warehouse, and authors a versioned JSON spec: not a chat answer, not a static export, a live dashboard that re-runs its queries every time someone opens it. The spec is the same object whether a human builds it in the editor or an agent builds it from a prompt.

How dvt builds AI dashboards for Snowflake

Connect dvt to Snowflake as a data source, then connect an MCP-capable agent (Claude Code, for instance) to the dvt MCP server. Describe the dashboard you want: “build a revenue dashboard from the orders table, monthly trend, top customers, average order value by region.” The agent reads the table schema, writes the SQL for each panel, constructs the spec, validates it against dvt’s schema, previews the rendered result, and applies it. See the quickstart for the exact prompts, from listing your workspace to shipping a live dashboard against a real warehouse.

{ "id": "revenue-by-month", "title": "Revenue by month", "type": "chart:bar",
  "data": { "rows": [{ "month": "Jan", "revenue": 120 }, { "month": "Feb", "revenue": 150 },
                     { "month": "Mar", "revenue": 178 }, { "month": "Apr", "revenue": 168 }] },
  "spec": { "series": [{ "type": "bar", "barMaxWidth": 48 }] } }

That’s one panel of the resulting spec: a plain, versioned JSON document, not a screenshot of a query result.

SQL pushdown: your warehouse, your compute

When the dashboard renders, dvt pushes the SQL to Snowflake and only the result rows come back. dvt doesn’t copy your rows into a second database, and it doesn’t re-bill your Snowflake compute through a hidden layer: the query runs on your warehouse, under your credentials, and shows up in your own query history. An agent building a dashboard inherits exactly the access the connection’s credentials already have. It can query what those credentials can query, and nothing else. dvt also connects to Postgres, BigQuery, and Google Sheets, so a Snowflake dashboard can sit in the same workspace as one built from a different source.

Better inputs, better dashboards

An agent writing SQL against Snowflake doesn’t know that your order_status column has a value meaning “returned” that should be excluded, or that “churn” means logo churn rather than revenue churn at your company. It writes what the schema tells it. dvt’s skills layer lets you write those conventions down once, as an org-scoped document (metric definitions, warehouse semantics, house rules), and the agent reads it before it builds, so every future dashboard follows the same rules instead of guessing from column names alone.

Review before it ships

Because the spec is a document, not GUI state, a Snowflake dashboard an agent builds goes through the same review loop as any other dvt dashboard. Every write is validated and can be previewed before it’s applied. Every version is attributed to the human, agent, or system that made it. A reviewer can comment on a specific panel, and an agent can read that thread over MCP, fix the panel, and resolve it.

Run it entirely inside your account

For teams that want the whole application inside Snowflake, dvt also ships as a Snowflake Native App: it runs on Snowpark Container Services in your own account, on your own compute, and has no route back to us. In that deployment, agents reach dvt’s MCP server as Snowflake identities, including Cortex Agents from inside the account, so there’s no dvt credential to issue or rotate. Because its containers and every query it issues run on your own compute, there’s no separate dvt-hosted tier absorbing that cost in this deployment. The full architecture, including exactly what the app can and can’t reach, is on the Snowflake page.

Try the spec format yourself in the free Builder. No signup required. Ready to point an agent at your own Snowflake account? Get early access.