Aller au contenu

Brancher un serveur MCP

Vous ouvrez cette page parce que vous voulez donner à l’agent des outils qui ne sont pas les siens — un accès à une base, à un système de tickets, à un navigateur. C’est le rôle du bloc mcpServers de la configuration.

Le cas le plus courant : le serveur est un processus que l’agent démarre lui-même et avec lequel il parle par son entrée et sa sortie standard.

name: Local Config
version: 1.0.0
mcpServers:
- name: filesystem
command: npx
args:
- "-y"
- "@modelcontextprotocol/server-filesystem"
- /home/moi/projets
env:
LOG_LEVEL: debug
cwd: /home/moi/projets

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.

Le transport se déduit de command, pas du champ type. La présence d’une commande suffit à choisir le mode local.

name: Local Config
version: 1.0.0
mcpServers:
- name: serveur-interne
url: https://mcp.interne.example/mcp
type: streamable-http
apiKey: ${{ secrets.JETON_MCP }}
requestOptions:
headers:
X-Equipe: plateforme

name et url sont obligatoires. type accepte sse ou streamable-http, et rien d’autre — la valeur http, valide dans les configurations MCP d’autres outils, est refusée ici. Champ omis, les deux transports sont essayés dans l’ordre, et l’échec des deux est signalé comme tel.

apiKey est envoyé en en-tête Authorization: Bearer. Comme pour un modèle, ${{ secrets.NOM }} va chercher la valeur dans ~/.lemniscate/.env, puis <projet>/.lemniscate/.env, puis <projet>/.env.

requestOptions accepte notamment headers, proxy, caBundlePath, verifySsl et clientCertificate — de quoi passer un proxy d’entreprise ou une autorité de certification interne.

connectionTimeout s’exprime en millisecondes et vaut 20 000 par défaut. Un serveur lent à démarrer a besoin qu’on l’allonge :

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

Ce champ n’est pas appliqué par lemni : le CLI attend la connexion sans borne. Le régler ne change le comportement que dans l’IDE.

Attacher un serveur à un dépôt plutôt qu’à votre poste

Section intitulée « Attacher un serveur à un dépôt plutôt qu’à votre poste »

Dans l’IDE, un serveur peut vivre dans un fichier du dépôt, ce qui le rend partageable avec l’équipe : .lemniscate/mcpServers/<nom>.yaml. Le fichier porte son propre en-tête et exactement un serveur.

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

Les mêmes fichiers sont lus dans ~/.lemniscate/mcpServers/ pour un serveur personnel valable sur tous vos dépôts. Les serveurs ainsi déclarés s’ajoutent à ceux de config.yaml : rien n’est remplacé.

lemni ne lit pas ces fichiers. Pour le CLI, les serveurs se déclarent dans ~/.lemniscate/config.yaml, ou dans le fichier passé à --config.

Dans l’IDE, l’enregistrement du fichier relance la connexion — et seulement si la commande, les arguments, l’environnement ou l’URL 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. Pour un serveur local, la sortie du processus est jointe au message : c’est là que se lit la vraie cause.

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.

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 ; leur politique par défaut est de demander avant chaque appel, et se change par outil ou par groupe dans Settings → Tools.

Dans lemni, la même politique s’applique. Pour en pré-autoriser un :

Fenêtre de terminal
lemni --allow lire_ticket "résume le ticket 4213"

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.

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 pour référencer un serveur publié dans un registre, qui n’est pas opéré. Déclarez le serveur en clair, comme ci-dessus : c’est la forme qui ne dépend de rien d’extérieur.