Comparison · Who owns the UI

Claude Live Artifacts vs. MCP Apps

Both put an interactive dashboard over live tools. One is generated by the host for a single person; the other is shipped by the service to every host. The whole comparison is that inversion.

2026-07-15By João Janini5 min readAgent-assisted

Last verified 2026-07-16. Claude's Artifact, connector, and sharing behavior moves fast, so details here may be stale. Check the primary sources before you build.

A Live Artifact and an MCP App can produce the same screenshot: an interactive dashboard, live data underneath, fresh numbers on open. The resemblance ends at authorship. One interface was generated by Claude for a single person; the other was designed by a developer and shipped to everyone.

A dashboard that never leaves your desk

A Live Artifact is a persistent, interactive HTML page in Claude Cowork: a tracker, a comparison tool, a morning brief. Unlike a one-off generated chart, it is reopened from the Artifacts view, re-queries connected apps or local files when opened, can be refreshed by hand, and keeps version history.

The boundary is narrower than the demos suggest. Live Artifacts exist only in Claude Desktop on paid plans, with no web or mobile version, and each one is local to the computer that owns it. Team and Enterprise users can share inside the organization; Pro and Max users cannot publish or share at all. A shared Artifact runs on the viewer's connector access, never on the creator's data.

The detail worth staring at: once connectors are approved during creation or update, the Artifact uses them on every refresh without asking again. That is the entire convenience, a dashboard with no morning approval ceremony, and it is also the security boundary. A write-capable connector should never be attached casually.

Regular Artifacts quietly changed too

If your mental model of an ordinary Claude Artifact is isolated static HTML, it is stale. Paid users can now connect Artifacts to official or custom MCP servers, with an approval prompt on the first tool interaction and each user authenticating independently. Published Artifacts also get persistent text storage: personal and shared modes, 20 MB per Artifact, publish before storage works. The family now has three members with different availability, sharing, and lifecycle rules.

chat Artifact
  reusable generated object
  optional MCP calls and published storage

Cowork Live Artifact
  persistent local dashboard
  refreshes from approved connectors and files

Claude Code Artifact
  private organizational page generated from a coding session
  updates at a stable internal link as the session progresses

An MCP App starts on the other side

An MCP App begins at the server. A tool descriptor points at a ui:// resource; when the host calls the tool, it fetches that HTML, seats it in a sandboxed frame, and wires it to the host over a standard JSON-RPC bridge. The UI can read tool inputs and results, call server tools, send follow-up messages, and update model-visible context.

That architecture buys properties no Live Artifact currently documents. The developer versions the UI together with the tool contract. The same resource renders in ChatGPT, Claude, Cursor, VS Code, or any other supporting host. Users connect a capability instead of generating a private view. Authentication, validation, writes, and business rules stay behind the server, and every user gets the designed workflow deterministically instead of a separately generated dashboard.

One Linear connector, two directions

Imagine a Linear MCP server. The same backend can sit on either side of the inversion.

Live Artifact path

You already have the Linear connector in Claude.
You ask Cowork for a project dashboard.
Claude generates the HTML and decides how Linear results map into it.
The view refreshes on your approved connector.

MCP App path

The Linear server publishes a dashboard ui:// resource.
A tool declares that resource in its metadata.
Any compatible host renders the same designed interface.
The UI calls server tools through the bridge.

Same data, reversed authority. The Live Artifact lets the user invent the frontend. The MCP App lets the service ship it.

Pick by who should own the interface

Live Artifact wins when

The composition is personal: one person's view across several connectors.
Claude should generate and revise the UI, sparing you a frontend repository.
Desktop or in-org reach is enough, and freshness on open beats portability.

The morning brief is the clean case. It joins Slack, Calendar, GitHub, and Linear; no single service should own that interface, so the user's agent composes it.

MCP App wins when

One service must deliver a consistent workflow to many users on any compatible host.
The flow has policy-sensitive states: approval, checkout, deployment, review.
The server must control validation and exact write semantics, and the developer wants to version, test, and support the UI as a product.

The spreadsheet diff review is the clean case here. The server defines the patch, validation, approval token, and write receipt; that interface should never be regenerated differently per user.

The costs mirror each other

Live Artifact limits are mostly reach: desktop-only, local to one machine, no public sharing path, no documented export that turns the generated view into an MCP App or an ordinary deployment, and a generated tool-to-UI mapping that still deserves human review. MCP App costs are ownership: you build and operate a server, you design schemas, authentication, CSP, error states, and host compatibility deliberately, and you still test on real hosts, because support arrives in different subsets on different timelines. Distribution and review remain separate product work.

Where this might converge

What follows is inference, not a published roadmap. Live Artifacts prove a host can compose a UI over several independent MCP servers; MCP Apps prove a server can ship one deterministic UI into several independent hosts. A plausible future workflow prototypes the interface as an Artifact, extracts a stable tool-and-UI contract, and publishes a portable MCP App. Current documentation promises none of it. Today the decision is ownership:

user owns the composition → Live Artifact
service owns the workflow → MCP App
team owns a coding session view → Claude Code Artifact

The remaining gaps are documentation-shaped: no Live Artifact package or export format, a connector-to-Artifact bridge that is a product surface rather than a published cross-host standard, sharing docs that describe boundaries without a public publishing roadmap. And nothing here removes the audit work: write-capable connector permissions and generated UI assumptions both still need a human to read them.

My morning brief is nobody's product, so the host composes it. A diff review is nobody's personal dashboard, so the server ships it. The tools may converge; the ownership question is permanent.