Brancher un serveur MCP

Un serveur MCP, ou connecteur, donne à l’agent des outils qui ne sont pas les siens. Ces outils suivent les mêmes règles que les autres :

• les outils d’une session sont fixés par la politique du projet avant toute lecture, et l’administrateur peut en retirer un (livre blanc sécurité V3, sections 5.1 et 5.2). Un connecteur démarre donc une fois approuvé par l’administrateur ;
• un connecteur s’exécute dans le même confinement que la session : sans réseau, sans secret et sans l’environnement de votre poste (livre blanc sécurité V3, garantie G05 et section 4.3).

Deux formes de connecteur n’ont donc pas leur place dans une session : un serveur joint par le réseau, et une commande qui télécharge son programme au lancement.

Un serveur lancé en local

Le serveur est un processus démarré pour la session, avec lequel l’agent parle par son entrée et sa sortie standard. Déclarez-le dans ~/.lemniscate/workstation.yaml :

name: Local Config
version: 1.0.0
mcpServers:
  - name: analyse-statique
    command: /opt/mcp/bin/analyse-statique
    args:
      - "--format"
      - json
    env:
      LOG_LEVEL: debug

name et command sont obligatoires. args, env et cwd ne le sont pas ; un cwd relatif est résolu depuis la racine de l’espace de travail.

command désigne un programme déjà installé. Une commande qui récupère son programme au moment de s’exécuter n’a aucune destination réseau à joindre, et son contenu changerait sans que sa déclaration change.

Ce que le serveur reçoit comme environnement

Le serveur ne reçoit pas l’environnement de votre poste : ni vos jetons, ni vos clés d’API, ni l’adresse de votre agent SSH. Il reçoit ce que la déclaration nomme dans env, écrit en clair. Ce bloc porte des réglages, pas des secrets : l’agent et ses outils ne détiennent aucun secret (livre blanc sécurité V3, section 4.3).

Faire approuver le connecteur

L’administrateur approuve un connecteur dans la politique, par deux informations : son nom, et l’empreinte de sa déclaration de lancement. L’empreinte couvre la commande et ses arguments, dans l’ordre. Elle ne couvre ni le nom, ni le bloc env.

1. Déclarez le connecteur comme ci-dessus et ouvrez une session. Tant qu’il n’est pas approuvé, il ne démarre pas, et le refus donne son empreinte :

   The connector "analyse-statique" is not approved by your organization's policy. Its fingerprint here is sha256:<empreinte>. It will not start.

2. Transmettez le nom et l’empreinte à l’administrateur du projet.

3. L’administrateur ajoute l’entrée au champ approvedConnectors de la politique. Dans la console, ce champ s’édite dans la section Advanced de l’onglet Policy ; voir Ce qui reste dans le document JSON.

{
  "approvedConnectors": [
    {
      "name": "analyse-statique",
      "fingerprint": "sha256:0000000000000000000000000000000000000000000000000000000000000000"
    }
  ]
}

Une empreinte s’écrit sha256: suivi de 64 caractères hexadécimaux. Une entrée sans empreinte, ou d’une autre forme, fait refuser la politique entière à l’installation.

Ce qui en découle :

• modifier command ou args change l’empreinte, et le connecteur ne démarre plus tant que la nouvelle n’est pas approuvée. Le refus dit alors que l’empreinte ne correspond pas à celle approuvée pour ce nom ;
• une liste vide n’approuve aucun connecteur ;
• la règle External connectors (MCP servers) de la console, en position Forbidden, empêche tout connecteur de démarrer, approuvé ou non.

L’empreinte atteste la déclaration, pas le code du programme lancé.

Le délai d’attente

connectionTimeout s’exprime en millisecondes et vaut 20 000 par défaut. Un serveur lent à démarrer a besoin d’une valeur plus haute :

name: Local Config
version: 1.0.0
mcpServers:
  - name: serveur-lent
    command: /opt/mcp/bin/serveur
    connectionTimeout: 60000

Ce champ s’applique des deux côtés : lemni et l’IDE ouvrent la connexion par le même code.

Déclarer le serveur dans un fichier à part

Un serveur peut vivre dans un fichier à lui, hors de workstation.yaml, dans le dossier ~/.lemniscate/mcpServers/ de votre configuration personnelle. Deux formats existent, et ils ne sont pas lus par les mêmes surfaces.

Le fichier JSON est lu par l’IDE et par lemni :

{
  "mcpServers": {
    "analyse-statique": {
      "command": "/opt/mcp/bin/analyse-statique",
      "args": ["--format", "json"],
      "env": { "LOG_LEVEL": "debug" }
    }
  }
}

Le fichier YAML est lu par l’IDE seulement. Il porte son propre en-tête et exactement un serveur :

name: serveur-analyse
version: 0.0.1
mcpServers:
  - name: analyse-statique
    command: /opt/mcp/bin/analyse-statique

Les serveurs ainsi déclarés s’ajoutent à ceux de workstation.yaml : rien n’est remplacé. Un même serveur déclaré à deux endroits n’ouvre qu’une connexion.

Une déclaration portée par un dépôt

Un connecteur déclaré dans un dépôt ne démarre pas, qu’il vienne d’un dossier .lemniscate/mcpServers/ du dépôt ou du bloc mcpServers de son fichier .lemniscate/project.yaml. Le produit nomme la déclaration écartée. Un contenu lu dans le dépôt n’ajoute aucun outil à la session (livre blanc sécurité V3, section 5.2).

Pour utiliser ce connecteur, déclarez-le dans votre configuration et faites-le approuver.

Vérifier que le serveur répond

Dans l’IDE, l’enregistrement du fichier relance la connexion, seulement si la commande, les arguments ou l’environnement ont changé ; renommer un serveur ne le reconnecte pas.

L’écran Settings → Tools liste les serveurs avec une pastille d’état et regroupe sous chacun les outils qu’il expose. Une erreur de connexion y apparaît, et remonte aussi dans les erreurs de chargement de la configuration. La sortie du processus est jointe au message.

Dans lemni, la commande /mcp ouvre la liste des connexions et leur état :

/mcp

Une différence de comportement à connaître : en session interactive, un serveur qui échoue laisse le reste fonctionner. En mode -p (sortie unique), un échec de serveur MCP fait échouer le démarrage.

Utiliser les outils exposés

Les outils du serveur rejoignent la liste des outils de l’agent. Dans l’IDE, ils apparaissent groupés sous le nom du serveur et préfixés par lui.

Chaque appel vous est soumis avant son exécution. La politique du projet décide du reste : l’administrateur peut retirer un outil à l’agent, par son nom, sans redéploiement (livre blanc sécurité V3, section 5.1). Voir Régler la politique des postes depuis la console.

Les prompts exposés par un serveur deviennent des commandes en /. Ses ressources deviennent des mentions en @, sous une entrée portant le nom du serveur ; cette dernière capacité n’existe que dans l’IDE.

Deux pièges

Le nom fait l’identité. Deux serveurs portant le même name ne coexistent pas : le second n’ouvre pas de connexion propre.

La forme uses: ne fonctionne pas ici. Le schéma l’accepte, mais aucun serveur n’est résolu par ce champ. Déclarez le serveur en clair, comme ci-dessus.