Do I need to paste my Supabase service-role key anywhere?

No. The remote Supabase MCP server at mcp.supabase.com authenticates over OAuth, so you authorize the project through a consent screen instead of pasting a key. Keep read_only=true in the URL so it connects as a read-only Postgres user, and scope project_ref to one project. Never commit a personal access token to a repo.

Is the dashboard live or a snapshot?

A snapshot. It contains the numbers Claude pulled when it built the file; it does not re-query Supabase when someone opens the link. To refresh it, ask Claude to repull and re-push to the same URL — or put that on a daily schedule so the stable link always shows current numbers.

Can my team comment without a Supabase or Claude account?

Yes. The dashboard is published to a Drafty canvas link that renders in any browser. Reviewers click the exact element they want changed and leave a pinned comment with no login required. Only the person connecting Supabase needs access to the project.

Is it safe to give Claude access to my Supabase project?

Connect with read_only=true scoped to a single project, and an app dashboard never needs more than that — every query runs as a read-only Postgres user, so it cannot write to your database. Every tool call is mediated by the MCP server, and in Claude you approve actions. Don't drop the read-only flag for a read-only reporting task.

How is this different from a Supabase report or a BI dashboard?

Supabase's own reports and BI tools query live data against a model you maintain — the right choice for governed reporting at scale. This approach is for a fast, shareable snapshot you can spin up in minutes and iterate by talking to Claude, then collect feedback on inline. Different jobs: one is a standing system, the other is a quick reviewable deliverable.

drafty

Build a Supabase app dashboard with Claude

Connect the Supabase MCP server to Claude, ask for a database and auth dashboard from your live project, and publish it to a link your team comments on directly — no BI tool, no screenshots pasted into Slack.

What you'll build

A self-contained app dashboard — total users, new signups this week, daily active users, table row counts, auth provider mix, and recent signups — generated by Claude from your real Supabase project, then published to a drafty.im/canvas/… link. Your team clicks the exact chart or number they want changed and leaves a note. Claude reads the comments and ships a revised version to the same URL.

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:

Live canvas — comment on any elementOpen ↗

The three moving parts

The Supabase MCP server gives Claude read access to your Supabase project — Postgres tables, row counts, auth users, and schema — through a controlled set of tools. You approve what it can touch, and you can lock it to read-only.
Claude pulls the numbers and writes a single self-contained HTML dashboard. You iterate on it in the artifact panel until it's right.
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 Supabase MCP server

Supabase runs an official remote MCP server at https://mcp.supabase.com/mcp. You connect once; it authenticates over OAuth, so no token is pasted into a config file. Scope it to read-only and to a single project with query parameters.

In Claude Code:

claude

❯

claude mcp add --transport http supabase 'https://mcp.supabase.com/mcp?read_only=true&project_ref=YOUR_PROJECT_REF'▌

Replace YOUR_PROJECT_REF with your project ref (the subdomain in your project URL, e.g. abcdefgh from abcdefgh.supabase.co). Then run /mcp inside Claude Code and follow the OAuth prompt to authorize the project.

In Claude Desktop: open Settings → Connectors, choose Supabase from the official connector list (or Add custom connector with https://mcp.supabase.com/mcp), and authorize over OAuth the same way.

Safety first

Keep read_only=true in the URL — it executes every query as a read-only Postgres user, so the server cannot write to your database. Scope project_ref to one project so account-level tools are disabled. A reporting dashboard never needs write access; don't grant it. Never commit a personal access token to a repo.

Step 2 — Pull the numbers

Ask Claude in plain language. It uses the MCP server's read tools to run SQL and list tables against your project:

claude

❯

Using the Supabase MCP server, pull everything we need for an app dashboard: total users in auth.users, new signups in the last 7 days, daily active users over the last 30 days, row counts for our main public tables, the breakdown of users by auth provider (email, Google, GitHub), and the 10 most recent signups. Run read-only SQL and summarize the figures before you build anything.▌

Claude queries Supabase, returns the figures, and you sanity-check them against the Supabase dashboard before going further. This is the moment to catch a wrong assumption — counting deleted users, a stale materialized view, an auth provider you forgot you enabled — while it's cheap.

Step 3 — Build the dashboard

Once the numbers look right, ask for the artifact:

claude

❯

Build a single self-contained HTML dashboard from those figures. Total users as the hero number with week-over-week change, then tiles for new signups this week, daily active users, and total rows across tables. A signups-over-time chart, an auth-provider breakdown, and a recent-signups table at the bottom. Clean, no external dependencies — inline the CSS and any chart code.▌

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

"Make total users the biggest number and put 7-day signups right under it."
"Add a 30-day daily-active-users trend line."
"Show the auth provider split as a horizontal bar, with percentages."

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

❯

Publish this dashboard to Drafty as a canvas and give me the shareable link.▌

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 figure looks high, are we counting service-role logins?" The comment is anchored to that element, not floating in a Slack thread. Claude reads the comments through the CLI, reruns the relevant Supabase 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 service accounts from daily active users." 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 Supabase 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:

claude

❯

Turn this Supabase dashboard into a live canvas: every morning, re-pull the latest numbers from Supabase via the MCP server, rebuild the dashboard, and push a new version to the same canvas URL so the link always shows today's figures. Schedule it to run daily 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 app dashboard needs read access and nothing more. Keep read_only=true in the MCP URL and scope project_ref to one project.
Check the figures before you share. The MCP returns exactly what you ask for — if your "active users" query counts service-role sessions or your row counts include soft-deleted rows, the dashboard will confidently show the wrong number. Reconcile against the Supabase dashboard 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.

Supabase dashboard with Claude — FAQ

Do I need to paste my Supabase service-role key anywhere?: No. The remote Supabase MCP server at mcp.supabase.com authenticates over OAuth, so you authorize the project through a consent screen instead of pasting a key. Keep read_only=true in the URL so it connects as a read-only Postgres user, and scope project_ref to one project. Never commit a personal access token to a repo.
Is the dashboard live or a snapshot?: A snapshot. It contains the numbers Claude pulled when it built the file; it does not re-query Supabase when someone opens the link. To refresh it, ask Claude to repull and re-push to the same URL — or put that on a daily schedule so the stable link always shows current numbers.
Can my team comment without a Supabase or Claude account?: Yes. The dashboard is published to a Drafty canvas link that renders in any browser. Reviewers click the exact element they want changed and leave a pinned comment with no login required. Only the person connecting Supabase needs access to the project.
Is it safe to give Claude access to my Supabase project?: Connect with read_only=true scoped to a single project, and an app dashboard never needs more than that — every query runs as a read-only Postgres user, so it cannot write to your database. Every tool call is mediated by the MCP server, and in Claude you approve actions. Don't drop the read-only flag for a read-only reporting task.
How is this different from a Supabase report or a BI dashboard?: Supabase's own reports and BI tools query live data against a model you maintain — the right choice for governed reporting at scale. This approach is for a fast, shareable snapshot you can spin up in minutes and iterate by talking to Claude, then collect feedback on inline. Different jobs: one is a standing system, the other is a quick reviewable deliverable.