Zum Hauptinhalt springen

MCP-Clients verbinden

Der empfohlene Aufbau gibt einem unterstützten AI-Client genau einen LightNow-MCP-Eintrag. Der Client startet LightNow Proxy in derselben Ausführungsumgebung. Der Proxy löst das ausgewählte Runtime Profile auf und leitet jede MCP-Anfrage an den passenden Upstream-Server weiter.

Vom bestehenden Setup zur verwalteten RuntimeBestehende MCP-Server importieren. Einen verwalteten LightNow-Eintrag synchronisieren.
AI-Client
Bestehende MCP-Server
mcp.json
filesystemgithubjenkins-localcustom-mcp
Ein LightNow-Eintraglightnow-proxy
LightNow
Runtime Profile

Prüfe Zuordnungen und Servereinstellungen vor dem Sync.

Filesystem MCPzugeordnet
GitHub MCPzugeordnet
Internal toolsals Custom Server erkannt
Custom MCPZuordnung erforderlich

Dem sicheren Ablauf folgen​

1
Installieren und anmelden

Installiere beide lokalen Werkzeuge und authentifiziere die CLI anschließend mit deinem LightNow-Account.

2
Nützliche bestehende Config schützen

Enthält der Client bereits MCP-Server, prüfe zuerst einen Import. Übernimm die Einträge, die erhalten bleiben sollen, vor dem Sync in ein Runtime Profile.

3
Einen Pilot-Client synchronisieren

Beginne mit dem Standardprofil, sofern du nicht bewusst ein anderes persönliches oder Organisationsprofil auswählst.

4
Neu starten und prüfen

Starte den AI-Client neu, prüfe seine Config-Posture und führe bei Bedarf einen aktiven Proxy-Health-Check für die Upstreams aus.

Codex installieren und verbinden
brew tap lightnow-ai/tap
brew install lightnow-cli lightnow-proxy

lightnow login
lightnow import-config --client codex --dry-run
lightnow import-config --client codex
lightnow sync --client codex --local-proxy
lightnow config-status --client codex
lightnow-proxy --config ~/.lightnow/lightnow-proxy/codex.yaml --health --json

Überspringe beide Import-Commands, wenn der Client keine nützlichen MCP-Einträge enthält. Ein Import ohne --replace führt unterstützte Einträge mit dem Zielprofil zusammen. Nutze --replace nur, wenn die vollständige Serverliste des Profils bewusst ersetzt werden soll.

Den Request-Pfad verstehen​

AI-ClientCodexein LightNow MCP-Eintrag
Local Proxystdioroutet Tools und Ressourcen
Runtime ProfileplatformServer, Config, Secret-Metadaten
Upstreamsstdio + HTTPTools, Ressourcen, Prompts

Die Client-Datei verweist auf LightNow Proxy und nicht auf jeden einzelnen Upstream-Server. Die CLI schreibt zusätzlich unter ~/.lightnow/lightnow-proxy/ eine Proxy-Config pro Client. Darin stehen das ausgewählte Profil, der Client, der Organisationskontext und die Runtime-Policy. Der Proxy löst beim Start die aktuelle Serverkonfiguration auf.

Der Proxy kann lokale stdio-Server starten und erreichbare Streamable-HTTP-MCP-Server aufrufen. Server-Commands, Header und Secret-Werte müssen nicht in die normale AI-Client-Datei kopiert werden.

Verbindungsmodus auswählen​

Nutze den Local-Proxy-Modus für die normale verwaltete Nutzung:

lightnow sync --client codex --profile default --local-proxy

Nutze den Policy-Sync, wenn Organisationseinstellungen das Profil wählen und über verbleibende nicht verwaltete Client-Einträge entscheiden sollen:

lightnow sync --client codex --from-settings

Direct Sync und Runner-Modus sind Kompatibilitätswege. Direct Sync schreibt einzelne Server in die Client-Config. Der Runner-Modus schreibt einen Wrapper pro Server und löst Runtime-Material beim Start dieses Wrappers auf. Kombiniere --runner, --local-proxy und --from-settings nicht in einem Command.

EntscheidungshilfeClient-Workflow auswählen

Vergleiche Managed Local Proxy, Policy-Sync, Direct Sync und Bridge-Exporte.

KonzeptLightNow Proxy verstehen

Verfolge Profilauflösung, Upstream-Routing und reine Metadaten-Events.

Aktuellen Client-Support prüfen​

CodexTOMLstdio + HTTP
Claude DesktopJSONstdio
Claude CodeJSONstdio
CursorJSONstdio
VS CodeJSONstdio
AntigravityJSONstdio
Gemini CLIJSONstdio

Local Proxy über stdio unterstützt aktuell:

  • Codex
  • Antigravity
  • Claude Code
  • Claude Desktop
  • Cursor
  • Gemini CLI
  • VS Code

Codex unterstützt zusätzlich einen clientseitigen lokalen HTTP-Eintrag. Der Config-Import unterstützt aktuell Antigravity, Claude Code, Claude Desktop, Codex, Cursor und VS Code. Gemini CLI und reine Bridge-Clients können nicht als Importquelle verwendet werden.

Unter MCP-Client-Support findest du die exakten CLI-Targets, Standarddateien und Kompatibilitätsexporte.

Organisations-Policy ausrollen​

Erprobe das Profil mit einem Client, bevor du Organisationseinstellungen anwendest. Wähle danach den Organisationskontext und überlasse LightNow Config die Auswahl des verwalteten Modus:

lightnow context --tenant acme
lightnow sync --client codex --from-settings
lightnow config-status --client codex --json

Blockiert die Policy nicht verwaltete MCP-Server, entfernt der Sync andere MCP-Einträge aus der Datei eines verwalteten Clients. Erlaubt die Policy diese Einträge, bleiben sie bestehen und config-status meldet eine gemischte Posture.

Prüfen und Fehler beheben​

config-status prüft die Client-Datei und die erwartete LightNow-Proxy-Config. Der Command startet nicht alle Upstreams. Nutze den Proxy-Health-Command für eine aktive Profil- und Upstream-Prüfung:

lightnow config-status --client codex --json
lightnow-proxy --config ~/.lightnow/lightnow-proxy/codex.yaml --health --json

Der Health-Command endet mit Code 0 für healthy, 2 für degraded und 1, wenn das ausgewählte Profil nicht aufgelöst werden kann. Degraded bedeutet, dass der Proxy grundsätzlich laufen kann, aber mindestens ein Upstream fehlgeschlagen ist oder das aktive Profil keine Upstreams enthält.

FehlerbehebungLightNow Proxy debuggen

Prüfe Config-Pfade, Authentifizierung, Profilauflösung und Upstream-Fehler.

ObservabilityRuntime Events untersuchen

Nutze reine Metadaten-Events, um Abläufe zu verstehen, ohne Tool-Payloads zu speichern.