TianGong LCA MCP (remote)

Der Remote-Endpunkt ist https://lcamcp.tiangong.earth/mcp. Verwenden Sie einen MCP-Host mit Unterstützung für Streamable HTTP, OAuth 2.1, PKCE und Protected Resource Metadata.

Browserautorisierung

1. Wählen Sie im MCP-Host Streamable HTTP und tragen Sie den Remote-Endpunkt ein.
2. Die erste Verbindung erhält 401 mit resource_metadata. Der Host liest automatisch /.well-known/oauth-protected-resource/mcp und die Metadaten des Autorisierungsservers.
3. Der Host öffnet den Browser mit einer vorregistrierten öffentlichen Client-ID und S256-PKCE. Dynamic Client Registration ist in der ersten Produktionsversion deaktiviert; nicht registrierte Clients oder Callbacks können keine Verbindung herstellen.
4. Der Nutzer meldet sich auf der TianGong Life Cycle Data Platform an, prüft Anwendung, Konto und Zugriff auf der Einwilligungsseite und erlaubt oder verweigert die Anfrage.
5. Der Browser kehrt zum exakten Callback des Hosts zurück. Der Host tauscht den Code direkt mit Supabase aus und speichert das rotierende Refresh-Token in seinem geschützten lokalen Anmeldedatenspeicher. Der Nutzer kopiert keinen Autorisierungscode und sieht oder fügt kein Token ein.

Supabase stellt ein standardmäßiges kurzlebiges Supabase access JWT aus. Der MCP Resource Server prüft die ES256-Signatur über Supabase JWKS sowie iss, aud, exp, iat, sub, session_id, role und die exakt zugelassene client_id. Anschließend leitet er dasselbe JWT an Edge Functions oder PostgREST weiter; Edge führt unabhängig getClaims() aus, und die Datenbank-RLS kombiniert auth.uid() mit auth.jwt() ->> 'client_id'. Der MCP-Dienst speichert weder OAuth-Sitzung noch Refresh-Token und verwendet kein Redis für die Authentifizierung.

Geben Sie KI, Chat, Kommandoargumenten oder manuellen Headern niemals Benutzername, Passwort, Autorisierungscode oder Access-/Refresh-Token. Der Remote-Dienst unterstützt nur Authorization Code + S256-PKCE und Refresh, weder Password- noch Client-Credentials-Grant.

Claude Code

Verwenden Sie die vom Betreiber für Claude Code registrierte öffentliche Client-ID mit festem Callback:

claude mcp add --transport http --scope user \
  --client-id "<registered-claude-code-client-id>" \
  --callback-port 49192 \
  tiangong-lca https://lcamcp.tiangong.earth/mcp

Öffnen Sie Claude Code, wählen Sie in /mcp den Eintrag tiangong-lca und autorisieren Sie im Browser. Claude Code hält das Refresh-Token lokal; fügen Sie weder Authorization-Header noch Client Secret hinzu.

Codex

Tragen Sie vor der Anmeldung die öffentliche Client-ID, die globale Loopback-Callback-Basis und den festen Listener-Port in ~/.codex/config.toml ein:

mcp_oauth_callback_url = "http://127.0.0.1:49193/callback"
mcp_oauth_callback_port = 49193

[mcp_servers.tiangong_lca]
url = "https://lcamcp.tiangong.earth/mcp"
oauth_resource = "https://lcamcp.tiangong.earth/mcp"

[mcp_servers.tiangong_lca.oauth]
client_id = "<registered-codex-client-id>"

codex mcp login tiangong_lca --scopes openid,email,profile

Codex kombiniert diese Basis mit der stabilen Callback-ID der MCP-URL und erzeugt http://127.0.0.1:49193/callback/sB-dwg9ebTQE, die in Supabase bytegenau registrierte endgültige Redirect-URI. Ein expliziter URL-Port konfiguriert den Listener nicht; deshalb muss auch mcp_oauth_callback_port auf 49193 bleiben. Codex öffnet den Browser und speichert das rotierende Refresh-Token lokal. Aktivieren Sie nicht DCR, fügen Sie kein Client Secret und kein Bearer-Token ein.

MCP Inspector

npx @modelcontextprotocol/inspector

1. Wählen Sie Streamable HTTP.
2. Tragen Sie https://lcamcp.tiangong.earth/mcp als URL ein.
3. Verwenden Sie die vom Betreiber bereitgestellte vorregistrierte Client-ID. Erzeugen Sie keinen Client und fügen Sie kein Bearer-Token ein.
4. Stellen Sie die Verbindung her und schließen Sie die Browserautorisierung ab.
5. Öffnen Sie Tools → List Tools und führen Sie eine Suche oder ein anderes Werkzeug aus.

Das anfängliche Fixed-Client-Rollout unterstützt nur registrierte Hosts. Wenn Cherry Studio, Dify oder ein anderer Host nur manuelle Authorization-Header unterstützt oder Dynamic Client Registration erzwingt, ist dies noch kein unterstützter Pfad; umgehen Sie dies nicht durch Kopieren von Tokens.

Sitzung, Refresh und Widerruf

• Access-Tokens sind kurzlebig; der Host erneuert sie mit einem rotierenden Refresh-Token.
• Lokales Trennen oder Abmelden soll die lokalen OAuth-Anmeldedaten des Clients löschen, ersetzt aber nicht den kontoseitigen Widerruf.
• Der Widerruf des entsprechenden Claude-Code-, Codex- oder Inspector-Clients unter Verbundene Anwendungen invalidiert sofort dessen Supabase-Sitzungen und Refresh-Tokens. Bei rein lokaler JWKS-Prüfung kann ein bereits ausgestelltes kurzlebiges Access JWT kryptografisch bis zum Ablauf gültig bleiben; sensible Vorgänge folgen ihrem eigenen Online-Validierungsvertrag.
• Nach Widerruf, Refresh-Replay, Client-/Callback-Fehler oder ungültigem Grant erneut verbinden und im Browser autorisieren.

Headless- und Dienstidentitäten

Supabase OAuth unterstützt nur Authorization Code + PKCE und Refresh. Ein unbeaufsichtigter Workflow benötigt zuerst eine menschliche Autorisierung für einen festen Client und speichert die Refresh-Sitzung in einem genehmigten Secret Store, oder erhält ein kurzlebiges Akteur-Token vom Orchestrator. Eine KI darf niemals Kontozugangsdaten sammeln. Eine wirklich nutzerlose Integration verwendet eine separat geprüfte Service Capability statt vorgetäuschtem Nutzer-OAuth.

Werkzeug- und Datengrenze

Die Werkzeugliste enthält normalerweise Flow-, Process- und LifecycleModel-Suche sowie RLS-geschützte Datenoperationen. Ist GLAD aktiviert, erscheinen auch Search_GLAD_Datasets_Tool und Get_GLAD_Dataset_Tool; der GLAD-API-Key liegt nur auf dem Remote-Server. GLAD-Werkzeuge fragen externe Datensatzmetadaten ab und importieren keine Daten automatisch.