Publish an MCP server

Publishing creates a versioned Registry entry from server.json. Treat that manifest as a release artifact: validate it locally, prove ownership in the intended Personal or organization context, publish once, and inspect the stored version before using it in Runtime Profiles.

Prepare the release

Artifact	Purpose	Required
server.json	Name, version, packages, transports, repository, and visibility	Yes
docs.md	Publisher-authored setup and usage context	No; CLI only
OpenAPI document	Additional API description for compatible servers	No; CLI only

Do not place secrets, internal incident notes, or local credentials in any publish artifact. The name and version identify the release; publish a new version when the manifest changes instead of trying to replace an existing one.

Confirm owner and ownership

Publishing requires a signed-in session with registry:write. Personal publishing uses your user context. Organization publishing uses the selected organization in the UI or --tenant in the CLI.

Domain-based namespaces must belong to a domain verified for that same owner. When strict repository ownership applies and repository.url is present, the repository must also be verified for the same Personal or organization context.

Owner context is part of the release

Verify ownership and publish in the context that should own the server. User and organization proofs are separate.

Validate locally

Validate the complete CLI artifact set

lightnow validate --server ./server.json --docs ./docs.md --spec ./openapi.yaml

The publish command offers the same local preflight without sending a request:

Run publish validation only

lightnow publish --server ./server.json --docs ./docs.md --spec ./openapi.yaml --validate-only

A successful local validation proves that the files are well-formed. The API still enforces authentication, owner context, namespace ownership, and repository ownership when publishing.

Publish from the CLI

Publish in the Personal context

lightnow login
lightnow publish --server ./server.json --docs ./docs.md --spec ./openapi.yaml

Add --tenant when the organization should own the release:

Publish for an organization

lightnow publish --tenant acme --server ./server.json --docs ./docs.md --spec ./openapi.yaml

The CLI reports the server ID, version, and Registry URL returned by the API. If visibility is omitted, the publish endpoint keeps the server private by default.

Publish from the UI

Open Publish in the LightNow app when you want a guided server.json workflow. Paste or drop the manifest, choose its schema version, review the parsed identity and ownership signals, then submit it in the active context. The UI redirects to the published version after success.

The UI wizard publishes the manifest itself. Use the CLI path when docs.md or an OpenAPI document is part of the release bundle.

Verify the result

1. Open the exact server version returned after publish.
2. Confirm owner, name, version, repository, packages, transports, and intended visibility.
3. Download or inspect the stored server.json snapshot.
4. Review ownership and trust signals as they become available.
5. Add the server to a Runtime Profile only after the release is the one you intended to publish.

Failure	Corrective action
Validation fails	Fix the named artifact; do not bypass local validation.
Domain is not verified	Verify the namespace domain in the publishing context.
Repository is not verified	Verify the manifest repository for the same owner, or correct the URL.
Version already exists	Increment the server version and publish a new immutable release.
Server appears under the wrong owner	Stop before rollout and publish the intended version from the correct context.

Read Ownership and verification for the proof boundaries and Runtime Profiles before connecting the published server to clients.