Build a BigQuery dashboard with Claude

This is an end-to-end example: connect a data source over MCP, generate a dashboard from live numbers, and close the review loop on one link. Total time, start to shared link, is under fifteen minutes. The same shape works for any of the other examples — only the connection step changes.

Here's the finished dashboard, published to a canvas — click any tile or number to leave a comment, exactly as your team would:

The three moving parts

1. The BigQuery MCP server gives Claude read access to your warehouse — datasets, table schemas, and SQL it runs against your data — through a controlled set of tools. You approve what it can touch.
2. Claude writes the SQL, runs it, and turns the result set into a single self-contained HTML dashboard. You iterate on it in the artifact panel until it's right.
3. Drafty turns that HTML into a stable link your team reviews. Comments pin to the exact element; Claude ships the fix to the same URL.

The generation step is fast now. The part this example is really about is the third one — getting the dashboard in front of people without losing their feedback to a screenshot circled in Preview.

Step 1 — Connect the BigQuery MCP server

Google's official path is the MCP Toolbox for Databases — an open-source MCP server you run locally with a prebuilt BigQuery toolset. It authenticates over Application Default Credentials (ADC), so no API key or service-account JSON is pasted into a config file — your existing Google Cloud IAM decides what Claude can read.

First, authorize read-only ADC and download the toolbox binary:

In Claude Code, register the toolbox (swap in your project; --prebuilt bigquery loads the read-focused BigQuery tools):

Then run /mcp inside Claude Code to confirm it connected. Sign in as a principal whose IAM grants are read-only — the BigQuery Data Viewer role (roles/bigquery.dataViewer) plus BigQuery Job User to run queries is enough for a reporting dashboard.

In Claude Desktop: open Settings → Developer → Edit Config and add a bigquery entry to mcpServers with command ./toolbox, args ["--prebuilt","bigquery","--stdio"], and BIGQUERY_PROJECT in the env object — then restart Claude Desktop.

Step 2 — Pull the numbers

Ask Claude in plain language. It calls the MCP server's read tools to inspect your schema, then runs read-only SQL to fetch the data:

Claude prints the SQL it ran, returns the figures, and you sanity-check them against the BigQuery console before going further. This is the moment to catch a wrong assumption — the wrong dataset, a timezone mismatch in the date filter, a JOIN that fans out rows — while it's cheap. Read the SQL, not just the totals.

Step 3 — Build the dashboard

Once the numbers look right, ask for the artifact:

Claude renders it live in the artifact panel. Iterate in place — you're not regenerating from scratch:

• "Make daily active users the biggest number and put the trend right under it."
• "Add a stacked bar for events by type over the last 7 days."
• "Format bytes scanned as GB and add the estimated query cost."

Step 4 — Publish to Drafty for review

A Claude artifact link is a preview, not a stable URL — iterate the artifact and the link you already sent now shows the old version. Ask Claude to publish it to a Drafty canvas instead, so the link you share always stays current:

Claude pushes the dashboard and hands back a drafty.im/canvas/… link that renders on any device. Send it — your team opens it in a browser, no login and no Claude account needed.

Step 5 — The review loop

This is the part that's not obvious until you've done it once.

A reviewer clicks the specific tile, chart, or number they want changed and leaves a pinned comment — "this DAU count looks high, are we filtering out internal test accounts?" The comment is anchored to that element, not floating in a Slack thread. Claude reads the comments through the CLI, reruns the relevant BigQuery query if needed, and pushes a revised dashboard to the same URL. The reviewer refreshes and sees the change; the thread stays attached to the element.

The mechanic matters because of what it removes. A Slack message about a chart produces "the number on the left looks wrong." A pinned comment on the actual tile produces "this — exclude internal test accounts from the DAU count." One of those produces a correct revision; the other produces a guess.

Keeping it fresh

An MCP-generated dashboard is a snapshot — it holds the numbers Claude pulled when it built it; it doesn't re-query BigQuery when someone opens the link. For a weekly review or a board-ready snapshot, that's fine.

To make it a live canvas that always shows today's figures, copy this prompt — Claude sets up the refresh for you and schedules it to run on its own:

The link stays stable while the content updates underneath it — see keeping a canvas updated automatically.

What to watch for

• Read-only, always. An analytics dashboard needs read access and nothing more. Scope the IAM grant to Data Viewer, and add a deny policy on execute_sql if you want a hard guarantee.
• Check the SQL before you share. The MCP runs exactly the query you ask for — if your "daily active users" query forgets to dedupe or includes internal accounts, the dashboard will confidently show the wrong number. Reconcile against the BigQuery console once, and read the SQL Claude ran.
• Mind the bytes scanned. BigQuery bills on data scanned. A reporting query over a huge unpartitioned table can be expensive — have Claude add a date filter or query a partitioned/clustered table, and watch the bytes-scanned estimate.
• The link is the deliverable, not the artifact. Share the Drafty URL, not the Claude artifact preview — that's the one you can update in place.