drafty
Jira logo

Build a Jira sprint dashboard with Claude

Connect the Atlassian MCP server to Claude, ask for a sprint and issue dashboard from your live Jira data, 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 sprint dashboard — sprint progress, burndown, issues by status, throughput, blockers, work by assignee — generated by Claude from your real Jira data, 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

  1. The Atlassian MCP server gives Claude read access to your Jira site — issues, sprints, boards, statuses, assignees — through a controlled set of tools. It respects your existing permissions: Claude only sees what your authenticated account can see.
  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 people without losing their feedback to a screenshot circled in Preview.

Step 1 — Connect the Atlassian MCP server

Atlassian runs an official remote MCP server at https://mcp.atlassian.com/v1/mcp. You connect once; it authenticates over OAuth, so no token is pasted into a config file.

In Claude Code:

claude
claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp

Then run /mcp inside Claude Code and follow the OAuth prompt to authorize your Atlassian site. Sign in as an account whose access is read-only for reporting — the server mirrors that account's permissions, so a read-scoped login is what keeps this dashboard from ever being able to write.

In Claude Desktop: open Settings → Connectors → Add custom connector, paste https://mcp.atlassian.com/v1/mcp, and authorize with OAuth the same way.

Safety first
The Atlassian MCP server acts as the user who authorized it — it can see and do exactly what that account can. Connect with an account whose Jira role is read-only (or one scoped to just the project you're reporting on), so the dashboard can never modify an issue. Never paste a long-lived API token into a config file or commit it. The dashboard only reads; it has no reason to hold write permissions.

Step 2 — Pull the numbers

Ask Claude in plain language. It uses the MCP server's read tools to run JQL and fetch real issue data:

claude
Using the Atlassian MCP server, pull everything we need for a sprint dashboard for our current active sprint: total story points committed vs. completed, day-by-day remaining points for a burndown, issue counts by status (To Do / In Progress / In Review / Done), count of blocked issues, issues completed in the last 7 days for throughput, and a breakdown of in-progress work by assignee. Summarize the figures before you build anything.

Claude calls Jira, returns the figures, and you sanity-check them against your Jira board before going further. This is the moment to catch a wrong assumption — the wrong sprint, a status you renamed, story points missing on some issues — 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. Sprint progress as the hero (points completed vs. committed with percent done and days remaining), a burndown line chart of ideal vs. actual, tiles for issues by status and blocked count, a throughput number, and a table of in-progress work by assignee. 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 burndown looks flat, are sub-tasks being counted?" The comment is anchored to that element, not floating in a Slack thread. Claude reads the comments through the CLI, reruns the relevant Jira 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 sub-tasks from the point total." 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 Jira when someone opens the link. For a sprint review or a standup-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 Jira dashboard into a live canvas: every morning, re-pull the latest sprint numbers from Jira via the Atlassian 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

Jira dashboard with Claude — FAQ

Do I need to paste a Jira API token anywhere?
No. The remote Atlassian MCP server at mcp.atlassian.com authenticates over OAuth, so you authorize your site through a consent screen instead of pasting a token. The server then acts with your account's permissions — connect as a read-only account for a reporting dashboard, and never commit a long-lived 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 Jira 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 the current sprint.
Can my team comment without a Jira 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 Jira needs access to the Atlassian site.
Is it safe to give Claude access to my Jira site?
The Atlassian MCP server mirrors the permissions of the account that authorized it — Claude only sees what that account can see. Connect with a read-only role (or one scoped to a single project) for a reporting dashboard, and don't grant an account write access for a read-only task.
How is this different from a Jira dashboard or a BI tool?
Native Jira dashboards and BI tools query live data against gadgets and models you maintain — the right choice for governed, always-on reporting. 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.