Let an agent publish the next edition.

What a publishing key can do

Every active bkn_live_… key currently has the same publisher authority for its owning Beckon account. Per-key scopes are not available yet.

• Claim an unused publication ID for the account.
• Upload and validate immutable revisions as private drafts.
• Set contributor credits and edition metadata in the manifest.
• Create and revoke expiring previews.
• Publish public or unlisted releases, restore older validated revisions, and withdraw releases.
• Read the account's release history.

An agent can credit authors, editors, translators, illustrators, narrators, and publishers. It can also set description, subjects, audience, identifiers, publisher, publication date, rights, reading order, resources, and declared capabilities. Those values are snapshotted with the immutable release.

Read the machine-readable capability contract →

What it cannot do

• Create or edit account-level authors and pen-name profiles.
• Change a user's login, shared identity, or product memberships.
• Prove that an externally credited contributor owns a Beckon account.
• Modify a finalized revision in place.
• Publish into another account's publication or read its private drafts.

A key is a revocable publishing capability—not an author identity. An exact contributor-name match may link a release credit to an existing creator profile; otherwise it remains an external textual credit.

1. Create a key

Sign in to your creator account, create a publishing key, and give it to the agent through a secret manager.

Connect an agent with MCP

Point any Streamable HTTP MCP client at https://readbeckon.com/mcp and authenticate with your bkn_live_… publishing key as a Bearer token. No npm package or local Beckon checkout is required.

The server is stateless and never polls. Unsupported SSE attempts receive a cached non-streaming response, while discovery responses are also CDN-cached to prevent reconnect-driven Vercel costs. Package bytes upload directly to a short-lived signed R2 URL instead of passing through MCP or a Vercel function.

Open the MCP setup guide →

Publisher-controlled presentation

Agents may preserve semantic italics, bold, and inline code with validated text ranges; emit accessible tables with captions and row headers; use trusted capabilities such as message threads; and build custom visual panels with Beckon Utilities.

Custom compositions declare beckon:composition@1.0 and pin beckon:utilities@1.0. The publisher controls semantic colors, grids, stacks, spacing, type, borders, radii, and responsive variants through the approved utility vocabulary. Beckon does not silently reinterpret version 1.0 later.

This is not uploaded React or CSS. Validation rejects unknown or arbitrary classes, executable code, imports, hooks, handlers, raw HTML, forms, remote content, browser APIs, positioning, z-index, selectors, and excessive trees. Every custom composition requires readable fallback prose. Read the complete component contract →

Trusted motion

Custom compositions may use animate-blink, animate-pulse, and animate-glow for cursors, indicator lights, and upgraded values. Beckon fixes the animation behavior and disables it automatically for readers who prefer reduced motion; publisher-defined keyframes and timing remain prohibited.

2. Create a preview workspace

Ask the remote MCP to create a workspace, then upload candidates through its signed R2 URLs. Keep the returned workspaceId and stable secret preview URL. Every replacement includes the current expectedGeneration.

You can also open the workspace from your creator account. Its editor displays the production reader beside the selected stable block. Valid browser changes immediately update the preview and appear as structured before/after events for the agent.

3. Reconcile, promote, then publish

Before uploading again, the agent calls beckon_get_workspace once and incorporates pending browser edits into the source project. A stale upload cannot overwrite a newer browser generation.

When the preview is approved, beckon_promote_workspace creates one immutable private revision. Publishing remains a separate consequential action requiring explicit approval and the expected-latest guard.

Workspaces, revisions, and releases

Workspaces are mutable, temporary, private authoring state. Revisions are immutable validated packages suitable for audit and review. A release is an explicitly published revision. Beckon may still return the legacy state name draft for an unpublished immutable revision; conceptually it is a release candidate, not an editable draft.

1. A valid workspace candidate replaces the same stable preview and advances its generation.
2. Invalid candidates leave the previous valid preview intact.
3. Promotion creates exactly one private immutable revision.
4. Explicit publishing makes that revision published and moves the latest pointer atomically.
5. The previous live revision becomes superseded but remains in history.

Before publishing, an agent reads release history once and sends expectedLatestRevision. If another agent published first, Beckon rejects the stale request instead of overwriting it.

Safe republishing

Each publicationId + revision pair can exist only once. Publishing uses an expected-latest guard, so competing agents cannot silently replace one another. Revision history is retained; a validated older revision can be restored with rollback, and a live revision can be withdrawn.

Preview URLs are unguessable, expire after at most 30 days, and can be revoked immediately. Read the package rules at Format and the current JSON authority contract at /api/v1/capabilities.