Build a ClickHouse event-analytics 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 ClickHouse MCP server gives Claude read access to your ClickHouse cluster — it can list databases and tables and run SELECT queries over your event data. It runs in read-only mode by default, so Claude can analyze but never mutate.
2. Claude writes the SQL, pulls the aggregates, and builds 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 ClickHouse MCP server

ClickHouse ships an official MCP server, mcp-clickhouse, run through uv. It connects to your cluster with the credentials you pass as environment variables and runs read-only by default (CLICKHOUSE_ALLOW_WRITE_ACCESS is off unless you set it). You'll need uv installed first.

In Claude Code:

Then run /mcp inside Claude Code to confirm the clickhouse server is listed and connected.

In Claude Desktop: open Settings → Developer → Edit config, and add an mcpServers entry with "command": "uv", "args": ["run", "--with", "mcp-clickhouse", "--python", "3.10", "mcp-clickhouse"], and the same CLICKHOUSE_HOST / CLICKHOUSE_PORT / CLICKHOUSE_USER / CLICKHOUSE_PASSWORD / CLICKHOUSE_SECURE environment variables.

Step 2 — Pull the numbers

Ask Claude in plain language. It uses the MCP server's read tools (list_databases, list_tables, run_query) to explore your schema and run the aggregations:

Claude lists your tables, writes the SELECT queries, returns the figures, and you sanity-check them against your own ClickHouse queries or your existing dashboards before going further. This is the moment to catch a wrong assumption — the wrong events table, a timezone offset on the day bucketing, a uniqExact vs. uniq choice that shifts the active-user count — while it's cheap.

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 events-per-day the biggest number and put active users right under it."
• "Add a 14-day events trend as a bar chart."
• "Show p95 and p99 latency in milliseconds, side by side."

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 active-user count looks low, are we deduping by user or by session?" The comment is anchored to that element, not floating in a Slack thread. Claude reads the comments through the CLI, reruns the relevant ClickHouse 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 — dedupe active users by user_id, not session." 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 ClickHouse 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. Use a read-only ClickHouse user and leave the server's write and drop flags off.
• Check the figures before you share. The MCP runs exactly the SQL Claude writes — if the active-user query counts sessions instead of users, or the day bucket lands in the wrong timezone, the dashboard will confidently show the wrong number. Reconcile against your own ClickHouse queries once.
• 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.