TianGong LCA MCP (distant)

Le point d'accès distant est https://lcamcp.tiangong.earth/mcp. Utilisez un hôte MCP compatible avec Streamable HTTP, OAuth 2.1, PKCE et Protected Resource Metadata.

Autorisation dans le navigateur

1. Sélectionnez Streamable HTTP dans l'hôte MCP et renseignez le point d'accès distant.
2. La première connexion reçoit un 401 avec resource_metadata. L'hôte lit automatiquement /.well-known/oauth-protected-resource/mcp et les métadonnées du serveur d'autorisation.
3. L'hôte ouvre le navigateur avec un identifiant public préenregistré et PKCE S256. Dynamic Client Registration est désactivé pour la première version de production ; un client ou callback non enregistré ne peut pas se connecter.
4. L'utilisateur se connecte à la plateforme TianGong Life Cycle Data, vérifie l'application, le compte et l'accès demandé sur la page de consentement, puis accepte ou refuse.
5. Le navigateur revient au callback exact de l'hôte. L'hôte échange le code directement avec Supabase et conserve le refresh token rotatif dans son stockage local protégé. L'utilisateur ne copie jamais de code d'autorisation et ne voit ni ne colle de jeton.

Supabase émet un Supabase access JWT standard et de courte durée. Le MCP Resource Server vérifie sa signature ES256 avec Supabase JWKS ainsi que iss, aud, exp, iat, sub, session_id, role et la client_id précisément admise. Il transmet ensuite le même JWT à Edge Functions ou PostgREST ; Edge exécute indépendamment getClaims(), et la RLS de la base combine auth.uid() avec auth.jwt() ->> 'client_id'. Le service MCP ne stocke ni session OAuth ni refresh token et n'utilise pas Redis pour l'authentification.

Ne donnez jamais à une IA, un chat, un argument de commande ou un en-tête manuel un nom d'utilisateur, mot de passe, code d'autorisation ou jeton d'accès/rafraîchissement. Le service distant prend uniquement en charge Authorization Code + PKCE S256 et refresh, sans grant password ni client-credentials.

Claude Code

Utilisez l'identifiant public et le callback fixe enregistrés par l'opérateur pour Claude Code :

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

Ouvrez Claude Code, sélectionnez tiangong-lca dans /mcp, puis autorisez dans le navigateur. Claude Code conserve le refresh token localement ; n'ajoutez ni en-tête Authorization ni secret client.

Codex

Avant la connexion, ajoutez l'identifiant public, la base globale du callback loopback et le port d'écoute fixe dans ~/.codex/config.toml :

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 combine cette base avec l'identifiant de callback stable de l'URL MCP pour produire http://127.0.0.1:49193/callback/sB-dwg9ebTQE, l'URI de redirection finale enregistrée octet pour octet dans Supabase. Un port explicite dans l'URL ne configure pas le listener ; mcp_oauth_callback_port doit donc aussi rester à 49193. Codex ouvre le navigateur et conserve le refresh token rotatif localement. N'activez pas DCR, n'ajoutez pas de secret client et ne collez pas de jeton Bearer.

MCP Inspector

npx @modelcontextprotocol/inspector

1. Sélectionnez Streamable HTTP.
2. Saisissez https://lcamcp.tiangong.earth/mcp comme URL.
3. Utilisez l'identifiant client préenregistré fourni par l'opérateur. Ne générez pas de client et ne collez pas de jeton Bearer.
4. Connectez-vous et terminez l'autorisation dans le navigateur ouvert.
5. Ouvrez Tools → List Tools et exécutez une recherche ou un autre outil.

Le déploiement initial à clients fixes ne prend en charge que les hôtes enregistrés. Si Cherry Studio, Dify ou un autre hôte ne sait utiliser que des en-têtes Authorization manuels ou exige Dynamic Client Registration, ce chemin n'est pas encore pris en charge ; ne contournez pas cette limite en copiant des jetons.

Session, rafraîchissement et révocation

• Les jetons d'accès sont courts ; l'hôte les renouvelle avec un jeton de rafraîchissement rotatif.
• Une déconnexion locale doit supprimer les identifiants OAuth locaux du client, mais ne remplace pas la révocation côté compte.
• Révoquer le client Claude Code, Codex ou Inspector correspondant dans les applications connectées invalide immédiatement ses sessions Supabase et refresh tokens. Avec une validation JWKS purement locale, un access JWT court déjà émis peut rester cryptographiquement valide jusqu'à son expiration ; les opérations sensibles appliquent leur propre contrat de vérification en ligne.
• Après révocation, replay de refresh, erreur client/callback ou grant invalide, reconnectez-vous et autorisez à nouveau dans le navigateur.

Identités headless et de service

Supabase OAuth ne prend en charge que Authorization Code + PKCE et refresh. Un workflow sans surveillance doit d'abord recevoir une autorisation humaine pour un client fixe et stocker sa session de rafraîchissement dans un secret store approuvé, ou recevoir un jeton acteur court de son orchestrateur. Une IA ne doit jamais collecter les identifiants du compte. Une intégration réellement sans utilisateur emploie une service capability auditée séparément au lieu de simuler un OAuth utilisateur.

Limite des outils et des données

La liste d'outils contient normalement les recherches Flow, Process et LifecycleModel ainsi que des opérations protégées par RLS. Si GLAD est activé, elle contient aussi Search_GLAD_Datasets_Tool et Get_GLAD_Dataset_Tool ; la clé API GLAD existe uniquement sur le serveur distant. Les outils GLAD interrogent les métadonnées externes et n'importent jamais de données automatiquement.