Claude Code Artifacts Now Call MCP Connectors with Viewer-Scoped Auth: What Operators Must Know

Claude Code Artifacts can now pull live data through each viewer's own MCP connectors — not the creator's. That inversion changes how teams build shared internal dashboards, who owns the credential chain, and what your AI gateway must account for.

Published via Claude Code Docs

Archive item produced with AI assistance from the cited source and published without individual review. Editor of record: Joe Werner.

A shared artifact dashboard page receiving live data through viewer-scoped MCP connectors, illustrated with a routing diagram

When Claude Code's Artifacts feature shipped in Week 25 (June), the publish model was straightforward: Claude builds a page from the session's context and publishes it to a private URL. Useful, but static once shared.

Week 29 (July 13–17, v2.1.207) changes that with a single architectural inversion: a published artifact can now call your MCP connectors when a viewer opens it — using the viewer's own connections, not the creator's.

That shift is not just a feature increment. It moves the credential ownership model in a direction that every team running an AI gateway or deploying Claude Code at scale must reason about explicitly.

What happened

The Week 29 release adds MCP connector support to Claude Code Artifacts. When a creator builds an artifact that references a connector — for example, "Build a dashboard that pulls open pull requests through my GitHub connector" — the resulting page calls the MCP server each time a viewer opens it. The viewer's own credentials are used, not the creator's. Viewers see an access approval prompt before the first connector call.

The same release also adds public sharing links (previously only organization-scoped), editor roles on Team and Enterprise for collaborative editing of live artifacts, and artifact creation from Claude Tag sessions.

Why it matters for AI engineering teams

Credential scope changed. Previously, any live data in an artifact required the creator to embed a snapshot. Now, the artifact's data freshness depends on the viewer's connector authorization state, not the creator's. This is a meaningful governance difference: a team member who loses access to a GitHub org will see an empty dashboard; a team member with broader access will see more data than the creator intended to expose.

MCP connector hygiene becomes an artifact concern. When Artifacts were static snapshots, your MCP connector configuration was a per-developer concern scoped to their Claude Code sessions. Once Artifacts go live with viewer-scoped connector calls, the question becomes: which connectors are available to which viewers, on what scope, under what authentication policy? Teams with SSO-enforced MCP connector provisioning need to audit whether their connector authorization model handles this new surface.

Shared internal tooling shifts from "link to doc" to "link to live tool". A Claude Code session that builds a pull request dashboard, an incident timeline, or a deployment status board can now publish it as a URL that stays fresh for anyone who opens it — without any backend infrastructure. For teams running Claude Code through an AI gateway, this means agent output is no longer just a transcript: it can become a persistent, action-capable internal tool page.

The "viewer approves access" gate is per-connector, per-viewer. The approval prompt fires on the viewer's first load. If your org has a zero-trust network policy or strict connector scoping, verify that the approval flow integrates cleanly with your IdP and that connector tokens obtained via approval are auditable.

The router/operator angle

For teams routing Claude Code through an AI gateway or custom base URL, the artifact MCP connector feature surfaces two new operational questions:

1. Which connection topology does your gateway need to support? Artifacts call connectors from the viewer's browser context, not from the Claude Code CLI session. If your AI gateway sits between Claude Code and model providers, it is not in the path of the artifact-to-MCP-server call. MCP connector calls initiated from Artifacts go directly from the viewer's browser to the connector server (or through claude.ai's connector proxy, depending on how the connector is configured). Confirm whether your existing MCP server infrastructure is designed to accept connector calls from Artifacts in addition to CLI sessions.

2. Audit your connector scopes before sharing Artifacts externally. Public sharing links (new in Week 29) mean an artifact with a connector-backed board can be opened by anyone with the link — not just org members. If the connector backing a public-link artifact has broad read or write scopes, the viewer-approval prompt is the only gate between the public web and your connected data source. Review connector scopes and consider restricting public-link Artifacts to read-only or no-connector use cases.

What to do this week:

  • Audit your existing MCP connector configurations for scope: which scopes are enabled, who can be granted access via the viewer-approval flow, and whether those scopes are appropriate for artifact sharing.
  • Confirm whether your connector servers (GitHub, Linear, Notion, etc.) are configured to accept OAuth token grants issued via the claude.ai connector proxy.
  • If you use Claude Code in a regulated environment, check whether viewer-scoped connector calls are logged in your audit trail. MCP connector calls from Artifacts may appear under different session metadata than CLI-originated calls.
  • For teams with AI gateways: note that the gateway is not in the artifact-to-MCP path. Your gateway usage logs will not capture artifact connector activity — you need connector-server-side logging for that visibility.

What TheRouter users should watch or try

Claude Code Artifacts are available on Pro, Max, Team, and Enterprise plans. The MCP connector feature requires a session authenticated via /login. If your team routes Claude Code through TheRouter's gateway, your session configuration (base URL, API key scopes) continues to govern the session's model calls — the artifact MCP connector calls are separate and viewer-scoped.

The practical setup to try: build an artifact that references a connector your team already has configured (GitHub, Linear, or a custom MCP server), publish it at org scope, and verify that a teammate can open it, approve connector access, and see live data. If approval fails or connector auth errors appear, the issue is in the connector's OAuth configuration, not in the Claude Code session or your AI gateway.

For ongoing monitoring: check Claude Code release notes for connector scope controls and audit log integration, both of which are natural follow-ons to this feature.

Help & contact