agent-connector : un outil pour déployer en une fois des serveurs/hooks MCP sur plusieurs CLI d’agents

 (github.com/ken-jo)
1 points par kenjo 4 시간 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Problème actuel : il faut adapter séparément les serveurs/hooks MCP à chaque CLI d’agent

Quand on connecte un serveur MCP à plusieurs CLI d’agents, il faut continuer à maintenir la même configuration dans des formats différents.

Par exemple :

  • Claude Code : JSON mcpServers
  • Codex : TOML [mcp_servers.*]
  • Cursor : mcp.json + hooks.json
  • Gemini : .gemini/settings.json

Rien que l’enregistrement d’un serveur est déjà fastidieux, mais les hooks sont encore plus complexes.
Le modèle d’événements diffère selon l’hôte, donc il faut réadapter le même comportement pour chaque CLI.

C’est pour réduire cette répétition que j’ai créé agent-connector.

Approche

Avec defineConnector(), on définit une seule fois la configuration, puis elle est rendue dans les fichiers de configuration natifs réellement lus par chaque hôte.

defineConnector({  
  server,  
  hooks,  
  plugins,  
  marketplace,  
})

Ce n’est pas une approche qui exécute un wrapper intermédiaire ou impose un format propriétaire.
L’idée est de générer les JSON, TOML, fichiers settings et autres fichiers que chaque CLI lit déjà nativement.

Périmètre pris en charge

À l’heure actuelle, cela couvre non seulement l’enregistrement des serveurs MCP, mais aussi les domaines suivants.

  • Enregistrement des serveurs MCP
  • Conversion du modèle d’événements des hooks selon l’hôte
  • Packaging des plugins / extensions
  • Flux d’installation via la marketplace de chaque hôte
  • Installation groupée pour plusieurs CLI
  • Suppression des configurations résiduelles via uninstall --purge
  • Télémétrie des tokens par outil
  • Création de CLI en marque propre sur la base du SDK

L’utilisation ressemble globalement à ceci.

$ agent-connector install  
$ agent-connector uninstall --purge  
# ou  
$ plugin install brand-name

État actuel

Pour l’instant, je développe ce projet seul.

J’ai principalement passé du temps sur les points suivants.

  • Rendu de configuration cross-host
  • Normalisation du modèle d’événements des hooks
  • Packaging des plugins / extensions
  • Flux d’installation via les marketplaces
  • Télémétrie
  • Tests sur Linux / macOS / Windows

À ce jour, il est possible de générer des configurations pour 42 CLI d’agents.

Ce que j’ai validé

En test réel, j’ai porté un MCP existant, context-mode.

Voici le résultat.

  • Code de déploiement par hôte : 20 322 lignes → 76 lignes
  • Scripts de hooks : 71 → 0
  • CLI prises en charge : 15 → 42

Cela dit, ce n’est pas un serveur MCP que j’ai moi-même créé, mais un cas de portage d’un serveur existant.
J’aimerais donc voir des cas de casse sur un plus grand nombre de serveurs MCP.

Retours recherchés

Si des personnes qui développent des serveurs MCP pouvaient l’essayer elles-mêmes et me faire un retour, ce serait d’une grande aide.

En particulier, j’aimerais recevoir ce type de feedback.

  • Cas où la configuration casse sur une CLI donnée
  • Cas où le modèle d’événements des hooks est insuffisant
  • Points maladroits dans le flux plugins / marketplace
  • Aspects peu pratiques dans la conception de l’API
  • Remarques sur la structure du projet OSS

Si le MCP est la couche qui connecte de vrais outils à l’agent, je pense qu’il faut une architecture qui ne reste pas prisonnière des méthodes de configuration propres à une CLI particulière.

À lire aussi

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.