drafty
Front logo

Build a Front shared-inbox dashboard with Claude

Connect the Front MCP server to Claude, ask for a shared-inbox dashboard from your live conversations — open volume, response time, resolution rate, load by inbox and teammate — 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 shared-inbox dashboard — open conversations, first-response and resolution times, conversations handled per teammate, volume by inbox and channel, top tags — generated by Claude from your real Front data, then published to a drafty.im/canvas/… link. Your team clicks the exact tile 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

  1. The Front MCP server gives Claude read access to your Front workspace — conversations, contacts, accounts, inboxes, tags, teammates — through a controlled set of tools. You approve what it can touch.
  2. Claude pulls the numbers and writes 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 your support lead without losing their feedback to a screenshot circled in Preview.

Step 1 — Connect the Front MCP server

Front runs an official remote MCP server at https://mcp.frontapp.com/mcp. It authenticates over OAuth 2.1 + PKCE, so no API key is pasted into a config file — and every tool call is attributed to a specific teammate.

First, in Front, create a developer app and add an OAuth feature to it (Settings → Developers → create app), noting the Client ID and Client secret. Use https://claude.ai/api/mcp/auth_callback as the redirect URL.

In Claude Code:

claude
claude mcp add --transport http front https://mcp.frontapp.com/mcp

Then run /mcp inside Claude Code and follow the OAuth prompt to authorize your Front workspace. When you authorize, grant the read scope only — this dashboard never needs to write to Front.

In Claude Desktop: open Settings → Connectors → Add custom connector, paste https://mcp.frontapp.com/mcp, open Advanced settings to provide your OAuth Client ID and Secret, and complete the OAuth flow the same way.

Safety first
Use OAuth with the read-only read scope. A reporting dashboard reads conversations, inboxes, and tags and nothing more — it has no reason to send a message, change an assignment, or move a conversation. Never commit your OAuth client secret to a repo or paste it into shared config.

Step 2 — Pull the numbers

Ask Claude in plain language. It uses the MCP server's read tools (search_conversations, list_inboxes, list_tags, list_teammates) to fetch real data:

claude
Using the Front MCP server, pull everything we need for a shared-inbox dashboard: count of open conversations and how many are unassigned, median first-response time and median resolution time over the last 30 days, conversations resolved in the last 30 days, conversations handled per teammate, volume broken down by inbox and by channel (email, chat, SMS), and the top 8 tags by conversation count. Summarize the figures before you build anything.

Claude calls Front, returns the figures, and you sanity-check them against Front's own Analytics before going further. This is the moment to catch a wrong assumption — a personal inbox counted as shared, an SLA window measured in calendar hours instead of business hours, an archived conversation still counted as open — 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. Open conversations as the hero number with how many are unassigned, then tiles for median first-response time, median resolution time, and resolved-this-month. A bar chart of volume by inbox, a small table of conversations handled per teammate, and a tag breakdown. 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:

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 resolution time looks low, are we counting auto-replies as resolutions?" The comment is anchored to that element, not floating in a Slack thread. Claude reads the comments through the CLI, reruns the relevant Front 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 the auto-reply inbox from resolution time." 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 Front when someone opens the link. For a weekly support 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 Front dashboard into a live canvas: every morning, re-pull the latest shared-inbox numbers from Front 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

Front dashboard with Claude — FAQ

Do I need to paste a Front API token anywhere?
No. The remote Front MCP server at mcp.frontapp.com authenticates over OAuth 2.1 with PKCE, so you authorize the workspace through a consent screen instead of pasting a token. You do create a Front developer OAuth app once to get a client ID and secret — keep the secret out of any committed repo, and grant the read scope only.
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 Front 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 Front 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 Front needs access to the workspace.
Is it safe to give Claude access to my Front workspace?
Connect with the read-only read scope, and a shared-inbox dashboard never needs more than that. Every tool call is mediated by the MCP server, attributed to a specific teammate, and in Claude you approve actions. Don't grant write scopes — send, assign, tag — for a read-only reporting task.
How is this different from Front Analytics?
Front Analytics is the right tool for governed, standing reporting on SLAs and team performance against metrics Front maintains. This approach is for a fast, shareable snapshot you can spin up in minutes, shape exactly how you want by talking to Claude, and collect feedback on inline. Different jobs: one is a standing system, the other is a quick reviewable deliverable.