Einen MCP-Server veröffentlichen
Publishing erzeugt aus server.json einen versionierten Registry-Eintrag.
Behandle das Manifest als Release-Artefakt: lokal validieren, Ownership im
vorgesehenen Personal- oder Organisationskontext nachweisen, einmal
veröffentlichen und die gespeicherte Version vor dem Einsatz in Runtime
Profiles prüfen.
Release vorbereiten
| Artefakt | Zweck | Erforderlich |
|---|---|---|
server.json | Name, Version, Pakete, Transports, Repository und Sichtbarkeit | Ja |
docs.md | Vom Publisher verfasster Setup- und Nutzungskontext | Nein; nur CLI |
| OpenAPI-Dokument | Zusätzliche API-Beschreibung für kompatible Server | Nein; nur CLI |
Publish-Artefakte dürfen keine Secrets, internen Incident-Notizen oder lokalen
Zugangsdaten enthalten. name und version identifizieren das Release.
Veröffentliche bei Manifeständerungen eine neue Version, statt eine bestehende
Version ersetzen zu wollen.
Owner und Ownership bestätigen
Publishing benötigt eine angemeldete Session mit registry:write. Persönliche
Releases verwenden deinen User-Kontext. Für Organisationen verwendest du den
aktiven Organisationskontext in der UI oder --tenant in der CLI.
Domainbasierte Namespaces müssen zu einer für denselben Owner verifizierten
Domain gehören. Gilt strikte Repository-Ownership und enthält das Manifest
repository.url, muss auch dieses Repository im selben Personal- oder
Organisationskontext verifiziert sein.
Lokal validieren
lightnow validate --server ./server.json --docs ./docs.md --spec ./openapi.yaml
Der Publish-Befehl bietet dieselbe lokale Vorprüfung ohne Netzwerkrequest:
lightnow publish --server ./server.json --docs ./docs.md --spec ./openapi.yaml --validate-only
Eine erfolgreiche lokale Validierung belegt nur die korrekte Dateiform. Die API prüft beim Publishing weiterhin Authentifizierung, Owner-Kontext, Namespace-Ownership und Repository-Ownership.
Über die CLI veröffentlichen
lightnow login lightnow publish --server ./server.json --docs ./docs.md --spec ./openapi.yaml
Ergänze --tenant, wenn eine Organisation das Release besitzen soll:
lightnow publish --tenant acme --server ./server.json --docs ./docs.md --spec ./openapi.yaml
Die CLI zeigt Server-ID, Version und Registry-URL aus der API-Antwort. Fehlt
visibility, hält der Publish-Endpunkt den Server standardmäßig privat.
Über die UI veröffentlichen
Öffne Publish in der LightNow App für einen geführten server.json-Ablauf.
Füge das Manifest ein oder lege es ab, wähle die Schemaversion, prüfe Identität
und Ownership-Signale und sende es im aktiven Kontext. Nach Erfolg leitet die
UI zur veröffentlichten Version weiter.
Der UI-Wizard veröffentlicht das Manifest selbst. Verwende die CLI, wenn
docs.md oder ein OpenAPI-Dokument zum Release-Bundle gehören.
Ergebnis prüfen
- Öffne die nach dem Publishing zurückgegebene, exakte Serverversion.
- Prüfe Owner, Name, Version, Repository, Pakete, Transports und beabsichtigte Sichtbarkeit.
- Lade den gespeicherten
server.json-Snapshot herunter oder untersuche ihn. - Prüfe Ownership- und Trust-Signale, sobald sie verfügbar sind.
- Füge den Server erst einem Runtime Profile hinzu, wenn das Release deinen Erwartungen entspricht.
| Fehler | Korrektur |
|---|---|
| Validierung scheitert | Korrigiere das genannte Artefakt und umgehe die lokale Validierung nicht. |
| Domain ist nicht verifiziert | Verifiziere die Namespace-Domain im Publishing-Kontext. |
| Repository ist nicht verifiziert | Verifiziere das Manifest-Repository für denselben Owner oder korrigiere die URL. |
| Version existiert bereits | Erhöhe die Serverversion und veröffentliche ein neues, unveränderliches Release. |
| Server erscheint beim falschen Owner | Stoppe vor dem Rollout und veröffentliche die vorgesehene Version aus dem richtigen Kontext. |
Lies Ownership und Verifizierung für die Nachweisgrenzen und Runtime Profiles, bevor du den veröffentlichten Server mit Clients verbindest.