Public Bundle Pages
What anonymous visitors can see and do on a public bundle page, and how sharing/forking works.
Overview
A bundle marked public gets a real page at /bundle/[id], readable
without an account. /bundle lists every public bundle.
What anonymous visitors see
Name, description, tags, and a read-only list of the MCPs in the bundle. Anything that mutates the bundle - renaming, tag edits, the public/private toggle, deploy-link settings, adding MCPs - is hidden unless you're the owner. Instead of the owner's deploy panel, anonymous visitors see a sign-in prompt.
Sharing, following, and forking
Once signed in, a visitor can:
- Follow a bundle - creates a new bundle in your account linked back to the original.
- Copy a bundle - creates an independent copy, tracked via
forked_from_id, with a visible fork count on the original. - Copy individual MCPs into an existing bundle of your own, without copying the whole thing.
All three require sign-in; anonymous visitors are routed to the sign-in dialog first.
Visibility and 404s
Visibility is a simple public/private flag, owner-controlled. Visiting a
private or nonexistent bundle id at /bundle/[id] returns a genuine HTTP
404 (enforced before the page renders, not a client-side error state) -
so private bundle ids don't leak existence through a soft error page.
Structured data
Public bundle pages carry CollectionPage JSON-LD with a nested
ItemList of the bundle's MCPs, so search engines and AI crawlers can
index bundle contents directly.
Route changes
The authenticated workspace moved from bare paths to /app: /bundles ->
/app/bundles, plus /app/catalog, /app/deployments, /app/agents,
/app/vault, /app/observability, /app/account. Old bare paths
redirect automatically. /bundle, /mcp, /discover, /docs, and
/blog stay at their bare paths and remain crawlable - /app is excluded
from robots.txt.