The short version: a Claude Code artifact — the live web page Claude publishes from a session to a private URL on claude.ai — used to be a snapshot, frozen with whatever data the session had when it built the page. As of Claude Code v2.1.209, a published artifact can call MCP connectors every time someone opens it, and each call runs through the viewer's own connections. That single change turns "here's a dashboard I made" into "here's a live internal tool that shows you your data" — with no backend and no deploy.
What it is · who it's for · how to start · what it costs#
- What: Published artifacts that fetch fresh data through MCP connectors on every view, not just at build time.
- Who: Anyone on Pro, Max, Team, or Enterprise running Claude Code v2.1.209+. Best fit: solo founders and small teams who want an internal status board without standing up a web app.
- Start: One prompt (below). No config file, no hosting.
- Cost: Included in your plan. Generating an artifact spends output tokens like any response, and a styled, interactive page costs more than the same content as terminal text — so keep pages lean.
The one prompt that builds it#
Name the connector and the data you want, and say you want it fetched on load:
Build a dashboard artifact of our open pull requests that
pulls the live list through my GitHub connector when the
page loads. Refresh it every 5 minutes, and show a fallback
line naming the connector for anyone who hasn't connected it.
When Claude publishes, it declares which connectors the page may call — and the page is boxed in: it can't call anything outside that declaration. The page fetches on load and can refresh on an interval or via a refresh control you ask for. Responses are cached in the viewer's browser, so reopening renders instantly from cache, then updates with fresh results.
The part that makes it actually useful: per-viewer data#
This is the design decision worth understanding before you build. When a published page calls a connector, the call uses the account of the person viewing the page — not yours.
- Each viewer uses their own connectors. Two teammates opening the same dashboard see different data, scoped to what each account can access. The page never sees anyone's credentials; claude.ai makes the calls for it.
- Viewers approve first. claude.ai asks each viewer for permission before the page's first connector call. Decline, or lack the connection, and you still get the page — minus its live sections.
- Actions run as the viewer too. A page can expose controls that do things — post to a channel, update an issue — and each action goes through the clicker's account. So a shared board lets everyone act as themselves.
That's why the feature is more than a convenience: a single artifact becomes a genuinely multi-tenant internal tool, and you never centralize anyone's access.
Constraints to design around#
Read these before you promise a teammate a link:
- No public link. A connector-backed artifact can't be shared publicly on any plan. Team/Enterprise can share it inside the org; on Pro/Max it stays private to you. Live, access-scoped data doesn't go to anonymous viewers — by design.
- Local servers don't carry over. MCP servers in your
.mcp.jsoncan feed the page while Claude builds it, but the published page can only call connectors from your claude.ai account. Wire up the connector on claude.ai, not just locally, if you want it live. - Enterprise has a separate switch. There's an "Enable artifact connectors" admin toggle distinct from the artifacts toggle. If your live sections are empty for a colleague, the three usual culprits are: they haven't connected that connector, they declined the permission prompt, or an Owner turned the org-wide connector toggle off.
- Always add a fallback. Ask Claude to include a fallback line in each live section naming the connector it needs, so a viewer missing the connection sees what to connect instead of a blank panel.
Why this matters for a small team#
The gap this closes is the one between a throwaway dashboard and an internal tool. Building the second used to mean a backend, auth, hosting, and a deploy pipeline — real work for a status board nobody looks at after a week. Now the same page that Claude would have published as a static snapshot can pull live data, scope it per viewer, and let people act on it, with zero infrastructure on your side. For a solo founder, that's the difference between "I'll build that admin panel someday" and "I built it in one prompt this afternoon." If you already lean on Claude Code, connect the MCP servers you care about and point an artifact at them — the throwaway just became load-bearing.



