Claude Code Artifacts with Live Data: How MCP-Connected Dashboards Work (2026)

Claude Code’s artifacts feature — publishing a session’s output as a live page on claude.ai — shipped in beta on Team and Enterprise plans in the week of June 15–19, 2026. For the first month, an artifact was a snapshot: whatever data Claude had gathered by the time it published the page was the data the page would ever show, until someone asked Claude to revise and republish it.

That changed in the week of July 13–17, 2026 (Claude Code v2.1.207–v2.1.212). A published artifact can now call MCP connectors each time someone views it, so a dashboard built as an artifact shows current data on every open instead of whatever was true when Claude built it. The same update added public sharing links, editor roles for shared editing on Team and Enterprise plans, and artifact publishing from Claude Tag sessions — but the connector call is the change that turns artifacts from “annotated output” into something closer to a lightweight, zero-deploy dashboard.

Live data connector calls require Claude Code v2.1.209 or later. General artifact publishing requires v2.1.183 or later. Check your version with claude --version.

This piece covers the mechanism precisely: what actually happens when a viewer opens a connector-backed artifact, how to set one up, where the permission and credential boundaries sit, and where this capability realistically fits next to dashboard tools like Retool and Streamlit.

What an Artifact Still Is

Before getting into the live-data mechanism, it’s worth being precise about what an artifact is not, because the live-data feature doesn’t change this: an artifact is one self-contained HTML (or Markdown) page that Claude Code publishes to a private URL on claude.ai. It has no backend. It can’t store form submissions, authenticate viewers on its own, or serve multiple routes. The page is wrapped in an HTML document shell and served under a strict Content Security Policy that blocks scripts, stylesheets, fonts, images, fetch, XHR, and WebSocket calls to any host other than the one serving the page. Claude inlines CSS and JavaScript and embeds images as data URIs specifically to satisfy that CSP.

MCP connector calls from a published artifact are an explicit, narrow exception carved into that CSP — not a general loosening of it. Everything else about the “no external requests” constraint still holds.

The Mechanism: What Happens on Each Page View

Here’s the sequence, as documented, for a connector-backed artifact:

1. At publish time, Claude declares which connectors the page may call. This declaration is fixed when the page is published — the page cannot call connectors outside what was declared. Only connectors present on the publisher’s claude.ai account qualify for that declaration.
2. When a viewer opens the page, the page requests permission before its first connector call. claude.ai asks the viewer to approve access. A viewer who declines, or who simply hasn’t connected the connector the page is asking for, still sees the rest of the page — just without the live sections that depend on it.
3. The call runs through the viewing account’s own connection, not the publisher’s. This is the detail that matters most for anyone building a shared dashboard: two people who open the identical page can see different data, because each connector call is authenticated as whoever is currently looking at the page. The page itself never sees anyone’s credentials — claude.ai executes the connector call on the page’s behalf and returns the result to the rendered page.
4. Actions work the same way as reads. If the page includes a control that invokes a connector tool with a side effect — filing an issue, posting a message, updating a record — that action is attributed to whichever viewer clicked it, using their account’s permissions.
5. Responses are cached in the viewer’s browser. A reopened page renders from cached responses immediately, then fetches again and updates in place. The page can also refresh on an interval or via an on-page refresh control if Claude built one in.

The practical consequence of step 3 is that a connector-backed artifact behaves less like “Claude published a report” and more like “Claude published a query, and your account answers it.” A GitHub-connector dashboard shared with three engineers who each have different repo access will render three different lists of open pull requests from the same URL.

Setting Up a Live-Data Artifact

There’s no separate “enable live data” toggle to flip — it’s driven entirely by what you ask for in the prompt, subject to a version and plan gate.

Prerequisites:

• Claude Code CLI v2.1.209+ (or the equivalent Claude desktop app build)
• A session signed in via /login — sessions authenticated with an API key, an LLM gateway token, or a cloud-provider credential (Bedrock, Vertex, Foundry) cannot publish artifacts at all, connector-backed or otherwise
• A Pro, Max, Team, or Enterprise plan
• Anthropic API as the model provider (not available on Amazon Bedrock, Google Cloud’s Agent Platform, or Microsoft Foundry)
• The organization must not have Customer-Managed Encryption Keys, HIPAA, or Zero Data Retention enabled
• On Team/Enterprise, an Owner must have artifacts enabled org-wide, and separately have the Enable artifact connectors toggle turned on under Settings → Capabilities — this is a distinct switch from the general Artifacts toggle
• The connector you want the page to call needs to already exist on the publisher’s claude.ai account (Settings → Connectors) at build time, and on each intended viewer’s account by the time they open the page

The prompt is the setup. Name the connector and the data directly:

Build a dashboard artifact of open pull requests that pulls the
live list through my GitHub connector when the page loads.

Claude writes the HTML file, declares GitHub as the connector the page may call, and asks for publish approval the way it does for any artifact. Republishing an already-approved artifact doesn’t re-prompt. From there:

• Ask for a fallback message per live section (“if the viewer isn’t connected to GitHub, show what to connect”) so the page degrades gracefully for someone missing the connector, rather than showing a blank panel.
• Ask for a refresh control or interval explicitly if you want the page to re-poll instead of only updating on load — this isn’t automatic.
• To update the page later, give Claude the artifact’s URL in a fresh prompt. Without the URL, a new session always creates a new artifact rather than editing the existing one.

If Claude responds that it can’t publish, or writes a local HTML file with no link, the most common causes are version (below v2.1.183 for artifacts generally, or v2.1.183–v2.1.208 for artifacts without live-data support), an unsupported model provider, or an org policy blocking the capability.

Static Artifacts vs. Live-Data Artifacts

The public-sharing row is worth flagging on its own: a connector-backed artifact cannot be shared to a public link under any circumstances, regardless of your organization’s sharing policy. On Pro and Max plans — where a public link is normally the only sharing mechanism available — a connector-backed artifact simply stays private to the publisher. On Team and Enterprise, it can be shared within the org but never externally. This is a hard constraint, not a default that can be overridden by an admin toggle.

Where This Fits Next to Retool and Streamlit

Live-data artifacts are not a replacement for either tool — they solve a narrower problem with a different cost structure.

Retool builds full internal applications: multi-page, backed by a database or API layer you control, with its own auth model, write-back to your systems, and a deployment you host and maintain. It’s the right tool when the dashboard needs to persist state, support many users editing the same records, or live indefinitely as production infrastructure.

Streamlit is a Python framework for turning a script into a data app — you write the logic, and Streamlit handles the UI layer. It requires you to run and deploy the app yourself (Streamlit Community Cloud, a container, a VM), and like Retool, the app’s data access is whatever you wire into the backend code.

A live-data artifact skips deployment entirely. It’s born from a coding session, published to a URL in one prompt, has no backend to host, and reuses each viewer’s existing MCP connector authentication instead of you building an auth layer. That’s the trade: no infrastructure to stand up, but also no persistence, no multi-page structure, a 16 MiB rendered-size ceiling, and per-viewer data that depends entirely on what connectors that specific person already has connected. It’s suited to a dashboard someone needs right now, built from data Claude was already working with — not to a tool that needs to outlive the session that created it or serve people without their own connector access.

Concrete Use Cases

Open PR triage board. The dashboard prompt from the official example: pull the live list of open pull requests through a GitHub connector on each view. A team lead opens the link during standup and sees the current queue — not what was open when the page was built an hour earlier — filtered to whatever repos their own GitHub connection can see.

Ticket queue with an action control. A support lead asks Claude for a triage board pulling open tickets through a helpdesk connector, with a button per ticket that reassigns it. Because the write goes through the clicking viewer’s own account, the reassignment is attributed to whoever actually clicked — not to whoever originally published the board.

Deploy status board during an incident. A page built mid-incident that keeps polling a monitoring connector on a set interval, so anyone with the link watches the same service health data update without needing terminal access to the session doing the investigation. This pairs with the “keep an artifact current while a long task runs” pattern artifacts already support for static content — the connector call is what keeps it current after the session ends, too.

Cross-tool metrics snapshot. A page combining a spreadsheet connector for a numbers table with a chart rendered from that data, refreshed each time a stakeholder opens the link before a meeting — useful specifically because it avoids re-exporting and re-pasting numbers into a slide deck each time the underlying sheet changes.

In each case, the pattern is the same: the value isn’t the chart or the layout, it’s that the page keeps answering the query instead of freezing the answer at publish time.

Troubleshooting: A Live Section Stays Empty for a Viewer

Three documented causes, in order of frequency:

1. The viewer hasn’t connected that connector on their own account. Connectors are per-account. They need one under Settings → Connectors on claude.ai, then a page reload.
2. The viewer declined the permission prompt. The denial only lasts for that page load — reloading brings the approval prompt back.
3. The organization has connector calls from artifacts turned off entirely. This is a separate admin toggle from the general Artifacts on/off switch, controlled under Settings → Capabilities.

Availability Summary

Related Resources

• Share session output as artifacts — official docs, including the full “Pull live data with MCP connectors” section
• Week 29 what’s new digest — the release notes covering this update
• Connect MCP servers — setting up the connectors an artifact can call