MCP Router : un poste de contrôle local pour vos serveurs MCP

Le problème concret : la configuration MCP se disperse

Chaque client MCP veut son propre fichier de configuration. Un serveur ajouté pour Cursor doit être redéclaré pour Claude, puis pour Cline, avec les mêmes chemins, les mêmes variables d'environnement, les mêmes clés d'API recopiées à plusieurs endroits. Quand on teste cinq ou six serveurs, la duplication devient le principal coût de maintenance, bien avant la qualité des serveurs eux-mêmes. MCP Router prend le problème par l'autre bout : au lieu de configurer chaque client séparément, on déclare les serveurs une fois dans une application de bureau, et les clients s'y connectent. Le README cite Claude, Cline, Windsurf et Cursor parmi les intégrations, avec un jeton généré par application personnalisée. La cible est donc l'utilisateur individuel qui jongle entre plusieurs outils, pas l'équipe qui déploie un serveur MCP en production.

Projets et workspaces : deux axes de regroupement

Le README distingue deux mécanismes qui ne jouent pas au même niveau. Les projets regroupent des serveurs MCP : on associe un ensemble de serveurs à un projet donné. Les workspaces fonctionnent comme des profils de navigateur, selon la comparaison du README, et servent à gérer des modes. S'y ajoute une bascule plus fine : chaque outil exposé par un serveur peut être activé ou désactivé individuellement. C'est cette granularité qui rend l'outil utile en pratique. Un serveur de fichiers peut rester actif pour ses lectures sans exposer ses opérations d'écriture. Un serveur de base de données peut être coupé entièrement dans un workspace de rédaction. La documentation ne détaille pas comment ces trois niveaux se combinent en cas de conflit, et c'est une zone d'ombre : si un outil est désactivé dans un projet mais activé dans le workspace courant, le README ne dit pas lequel l'emporte. À tester soi-même avant de bâtir un flux de travail dessus.

Ce qui circule et où : le modèle de données

L'architecture est celle d'un routeur local. L'application de bureau héberge la configuration des serveurs, locaux ou distants, et les clients s'y raccordent via la CLI plutôt que directement aux serveurs. Le README indique que les journaux de requêtes, les configurations et les données des serveurs restent sur la machine, et que les clés d'API et identifiants d'authentification sont stockés localement et ne sont pas transmis à l'extérieur. Il présente aussi le code source de l'application de bureau comme publiquement disponible, ce qui permet de vérifier cette affirmation plutôt que de la croire sur parole. Deux réserves. D'abord, « reste local » ne dit rien sur le chiffrement au repos : le README ne précise pas comment les identifiants sont protégés sur le disque. Ensuite, un serveur MCP distant reste un appel réseau sortant : ce qui reste local, c'est la configuration et la journalisation, pas les données que vous envoyez volontairement à un serveur tiers.

Mise en route : téléchargement puis connexion par la CLI

L'installation passe par la page des releases du dépôt, où sont publiés les binaires de bureau. Le README annonce une prise en charge de Windows et de macOS uniquement. Une fois l'application configurée, la connexion d'un client se fait en ligne de commande. Le jeton est émis lors de l'ajout d'une application personnalisée :

export MCPR_TOKEN="mcpr_your_token" npx -y @mcp_router/cli connect

Pour rattacher la session à un projet précis, la commande accepte une option :

npx -y @mcp_router/cli connect --project <project-name>

Trois remarques pratiques. Le paquet npm s'appelle @mcp_router/cli, avec un underscore, alors que le dépôt GitHub s'écrit mcp-router avec un tiret : une confusion facile à faire dans un script. La variable d'environnement s'appelle MCPR_TOKEN, sans underscore après MCPR. Enfin, le README ne décrit pas de commande de déconnexion ni de révocation de jeton depuis la CLI, ni de mécanisme de rafraîchissement : la gestion des jetons semble se faire dans l'interface graphique.

Le cas où l'outil ne convient pas

MCP Router suppose un poste de travail avec interface graphique. Le README ne mentionne que Windows et macOS, sans build Linux ni mode serveur sans interface. Sur un runner d'intégration continue, dans un conteneur ou sur une machine distante en SSH, il n'y a pas de tableau de bord à ouvrir, donc pas de configuration à modifier. C'est la limite la plus nette. S'y ajoute un point de défaillance unique : si l'application de bureau n'est pas lancée, les clients qui pointent vers elle n'ont plus accès aux serveurs. Le README ne décrit ni service d'arrière-plan ni démarrage automatique. Une équipe qui a besoin que ses serveurs MCP soient disponibles en permanence devrait passer par une configuration statique par client ou par un serveur MCP hébergé, pas par un routeur de bureau.

Face à une configuration statique par client

L'alternative la plus directe n'est pas un autre produit mais la méthode d'origine : un bloc de configuration par client, avec les serveurs déclarés en JSON ou en DXT, formats que MCP Router accepte justement en entrée. La différence tient à l'endroit où vit l'état. Dans une configuration statique, chaque client est autonome : ajouter un serveur signifie éditer chaque fichier, mais rien ne dépend d'un processus tiers, et le même fichier fonctionne sur un serveur distant comme sur un portable. MCP Router inverse ce compromis : une seule déclaration, mais un composant supplémentaire qui doit tourner. Le gain est réel dès qu'on dépasse quelques serveurs et quelques clients. Il disparaît si vous n'utilisez qu'un seul client avec deux serveurs : vous ajoutez une couche d'indirection pour économiser une poignée de lignes JSON. Le README ne fournit pas de commande d'export de la configuration vers un client, donc la migration inverse n'est pas documentée.

Licence et coût de suivi

Le dépôt est publié sous Sustainable Use License, et le champ licence de l'API GitHub renvoie NOASSERTION : ce n'est pas une licence reconnue par l'OSI. Ce n'est pas un détail de forme. Le code est lisible et l'application de bureau est présentée comme auditable, mais une licence de ce type restreint en général les usages commerciaux et la redistribution. Pour un usage personnel, la question ne se pose guère. Pour intégrer l'outil dans un produit ou le redistribuer en interne, il faut lire LICENSE.md, et ce texte ne remplace pas un avis juridique. Côté maintenance, les releases récentes s'échelonnent sur environ huit mois (v0.6.1 en novembre 2025, v0.6.2 en janvier 2026, v0.6.3 en juin 2026) et le dépôt n'est pas archivé, avec un dernier push en août 2026. La version 0.6.x indique un projet encore en phase de stabilisation : attendez-vous à des changements d'interface et de format de configuration entre versions mineures. La CLI étant distribuée via npx, chaque connexion récupère la version publiée au moment de l'exécution, ce qui peut désynchroniser un client d'une application de bureau non mise à jour.

Conclusion éditoriale

À adopter si vous accumulez plusieurs serveurs MCP et que vous voulez basculer entre des jeux d'outils par projet sans éditer des fichiers de configuration à la main, à condition d'accepter une application de bureau et une licence Sustainable Use. À éviter si votre poste est Linux ou si vous avez besoin d'une licence OSI. Avant de vous engager, lisez LICENSE.md et vérifiez que la CLI @mcp_router/cli se connecte bien à votre version du routeur.

Sources officielles

1. Issues
2. mcp-router/mcp-router on GitHub
3. Project website
4. README
5. Releases