MCP-Registrierung mit AI Hub

clye mcp ist die Bridge zwischen CLYE AI und einem MCP-Server. Ohne diesen Wrapper startet ein Connector nur lokal (stdio) – der Assistent im Hub sieht ihn nicht, und AI_HUB_URL / AI_HUB_API_KEY greifen nicht.

Verwandt: Konfiguration · Docker · Filesystem-Connector · Sandbox

Merksatz

clye mcp  +  clye <connector> …   →   Hub ↔ Bridge ↔ stdio-MCP-Server
clye <connector> …                →   nur lokaler stdio-Server (kein Hub)

Befehl	Wirkung
clye mcp clye postgres-connector …	Connector starten und an CLYE AI anbinden
clye postgres-connector …	Nur stdio – nützlich für Tests mit einem lokalen MCP-Client
clye mcp https://…	Entfernten HTTP-MCP an den Hub bridgen
clye sandbox / Default-Docker	Eingebetteter Server mit Hub – kein mcp nötig
clye share-folder …	Eigene Hub-Verbindung per WebSocket – kein mcp nötig

Transport-Erkennung: Beginnt das erste nicht-Flag-Argument mit http:// oder https://, nutzt die CLI streamable HTTP; sonst startet sie das angegebene Kommando als lokalen stdio-MCP-Server.

Lokalen MCP-Server registrieren

Alles nach mcp gehört zum Child-Prozess. Connector-Flags wie --host, --dbname oder --path bleiben erhalten und werden nicht von der Bridge verschluckt.

clye mcp clye python-executor
clye mcp clye postgres-connector --host localhost --dbname app
clye mcp clye filesystem-connector --path /data
clye mcp npx -y @modelcontextprotocol/server-filesystem /data

Wenn MCP_RESTART_TIMEOUT gesetzt ist, überwacht die Bridge lokale stdio-Server. Antwortet der Child-Prozess länger als dieses Intervall nicht und schlägt auch ein Ping fehl, wird er neu gestartet.

MCP_RESTART_TIMEOUT=30s clye mcp clye filesystem-connector --path /data

Im Docker-Image denselben Befehl mit Entrypoint-Override starten:

docker run --rm \
  -e AI_HUB_URL="https://clye.ai" \
  -e AI_HUB_API_KEY="dein-api-key" \
  --entrypoint ai-hub-container-entrypoint \
  simonclye/clye-ai-hub-gateway:latest \
  clye mcp clye filesystem-connector --path /data

Entfernten HTTP-MCP verwenden

Statt eines lokalen Prozesses kannst du eine http://- oder https://-URL übergeben. Die CLI nutzt dann den streamable-HTTP-Transport von MCP und unterstützt optionale Authentifizierungs-Header.

clye mcp https://remote-mcp-server.example.com/mcp

clye mcp \
  --mcp-header "Authorization: Bearer dein-token" \
  --mcp-header "X-API-Key: dein-api-key" \
  https://remote-mcp-server.example.com/mcp

Was bei Registrierung und Wiederverbindung wichtig ist

Wenn du einen MCP-Server mit clye mcp an AI Hub anbindest, wird die eigentliche MCP-Initialisierung nur beim ersten echten MCP-Connect der laufenden Sitzung ausgeführt. Reine Konfigurationsabfragen ohne aktiven MCP-Kanal zählen dafür nicht als vollständige Registrierung.

Für dich im Alltag heißt das:

• neu registrierte Server erscheinen nach erfolgreicher Verbindung wieder zuverlässig unter Einstellungen → MCP-Server
• die automatische Installation im Gateway greift wieder korrekt, wenn der Server wirklich mit MCP verbunden ist
• nach einem Deploy können bereits verbundene Sitzungen sich beim nächsten Reconnect in der Regel selbst erholen
• ein manueller Neustart von ai-hub-cli ist dafür in diesem Fall normalerweise nicht mehr nötig

Wenn eine alte Gateway-Sitzung nach einem Deploy zwar noch POST-Requests sendet, aber kein aktiver SSE-Stream mehr verbunden ist, behandelt CLYE diese Sitzung nicht mehr als „online“. Statt still hängen zu bleiben, erzwingt CLYE dann eine saubere Neuverbindung derselben Gateway-Identität.

Fehlt bei einer bestehenden Gateway-Verbindung ein aktuelles Lebenszeichen, bricht CLYE Tool-Aufrufe jetzt sofort mit einer klaren Aufforderung zur Neuverbindung ab. Dadurch wartest du nicht mehr minutenlang auf einen festhängenden Aufruf, wenn noch eine veraltete Gateway-Sitzung ohne aktiven Heartbeat existiert.

Wichtig dabei: CLYE unterscheidet jetzt klarer zwischen einer eigenen Sandbox-Verbindung und einem externen Gateway-Connector. Wenn ein getrennter Connector nicht mehr verbunden ist, fordert dich die Meldung zur Neuverbindung dieses Connectors auf – nicht zum Neustart der Sandbox.

Wenn ein Server nach dem Speichern noch nicht sichtbar ist, warte kurz auf die erfolgreiche Verbindung oder verbinde den Server erneut. Wenn Tool-Aufrufe nach einem Deploy oder einer unterbrochenen Verbindung sofort mit einem Hinweis zur Neuverbindung abbrechen, stelle die Gateway-Verbindung einfach erneut her; ein kompletter CLI-Neustart ist dafür normalerweise nicht nötig.

MCP-spezifische Flags und Umgebungsvariablen

Die Flags --mcp-header, --mcp-server-key und --idle-timeout werden manuell gelesen, weil mcp das normale Cobra-Flag-Parsing deaktiviert. So kann die Bridge unbekannte Flags an lokale Child-Server weiterreichen.

Authentifizierung und Basis-URL: Konfiguration (AI_HUB_URL, AI_HUB_API_KEY, --url, --api-key).

Name	Gilt für	Beschreibung
--mcp-header "Name: Wert"	Remote-HTTP-MCP	Fügt einen Header zum entfernten MCP-Server hinzu; mehrfach nutzbar.
--mcp-server-key <key>	Hub-Registrierung	Übergibt beim Registrieren einen Server-Key an AI Hub.
--idle-timeout 30s	Bridge-Laufzeit	Beendet die Bridge nach Inaktivität; alternativ AI_HUB_IDLE_TIMEOUT.
MCP_RESTART_TIMEOUT=30s	Lokale stdio-Server	Startet nicht antwortende Child-Server neu.
AI_HUB_MCP_STDIO_SERVERS	Bridge-Konfiguration	JSON-Liste zusätzlicher stdio-Server, die beim Hub registriert werden.

Hinweise: HTTP(S) wird automatisch erkannt. Server-Benachrichtigungen werden kontinuierlich empfangen. Wiederhole --mcp-header für jeden Header. Nutze in Produktion HTTPS und vermeide Secrets in der Shell-History.