Claude Artifacts Can Read Live MCP Data or Get a Public Link — Never Both, on Any Plan

If my artifact starts out with no connector and a public link, then later gets a connector added, what happens to the original public link?

Based on how this restriction works, once the artifact is changed to call a connector, it no longer qualifies for a public link — meaning you can't keep the same artifact's original public link while also adding live-data capability to it. What actually happens is usually that the system forces you to choose between "keep the public link, don't call a connector" and "call a connector, give up the public link," rather than letting both take effect at once while one silently breaks in the background.

The safer approach is to think clearly about who this artifact will eventually be shared with before you add connector functionality. If you've already sent the link to an unspecified external audience and only later want to add live-data capability, that usually means you need to build a separate new version, rather than adding the feature directly onto the version that's already been publicly shared.

On Team or Enterprise plans, do colleagues within the organization actually see different data when opening the same connector-calling artifact? Why is it designed this way?

Yes, genuinely different. Because the data a connector call reads comes through each individual viewer's own connected service — for example, if the artifact is a dashboard querying a database, you'll see the tables and permission scope your own account can access when you open it, while a colleague sees whatever their own account can access. If their permissions differ from yours, the numbers you each see can easily be inconsistent, and if a given query touches a table your colleague doesn't have permission for, that query simply fails for them.

The reason for this design is that the mechanism deliberately avoids letting the publisher's connector permissions get "borrowed" for other viewers to use. If the artifact instead used the publisher's own connector to fetch data on behalf of every viewer, that would mean one person's access rights get effectively forwarded, an unlimited number of times, to anyone who opens the artifact — an obvious security risk. Requiring everyone to use their own connector makes the experience vary person to person, but it ensures what each person sees is exactly what they already had permission to see in the first place, with no permission transferred across accounts.

If I'm on Pro or Max and genuinely need to share a live-data dashboard with an external client, is there any workaround right now?

There's no official direct workaround for this restriction currently — on Pro and Max, an artifact that calls a connector simply can't generate a public link; this isn't a setting you can toggle, it's a limitation baked into the architecture itself. There are two more practical directions to consider. First, if the audience is small, you could periodically export the live query results into a static snapshot (regenerated at a fixed time each day, say), and share that as a regular static artifact with a public link — trading away real-time freshness for shareability. Second, if real-time data is a hard requirement, you may need to consider upgrading to Team or Enterprise, but that means your audience has to join your organization first — it can't be opened up to completely external people with no account.

In practice, third-party tools have also tried to fill this gap (using an additional MCP Server to publish artifact content as an independent public link, for instance), but these tools aren't a mechanism Anthropic officially provides — evaluate their data security and reliability yourself before using them, rather than assuming they carry the same guarantees as the official native feature.

Does this "connector vs public link" mutual exclusion mean the connector feature in Artifacts just isn't mature yet, and this restriction might get lifted later?

Going by the logic behind this restriction (a public link requires no login, a connector requires each viewer to read data under their own identity), this doesn't really look like a temporary limitation waiting for a feature to catch up — it looks more like a deliberate design choice made because these two features are fundamentally at odds with each other. Unless some new mechanism emerges that can reconcile the conflicting requirements of "a visitor doesn't need to log in" and "data needs to be read according to each visitor's own identity" — say, requiring a visitor who opens the link to temporarily log into their own account to complete connector authorization — this restriction isn't likely to simply disappear just because the feature matures over time.

The more practical mindset is to treat this restriction as a settled rule under the current architecture when planning your workflow, rather than expecting it to be lifted anytime soon. If a new mechanism does eventually resolve this contradiction, it would likely take the form of a new, separate sharing mode — something like "viewable only after the visitor logs in" as a middle ground — rather than making "fully public, no login" and "live connector data" directly equivalent to each other.