Serveur MCP distant ou local : lequel choisir

Serveurs distants

Rien à installer : l’assistant se connecte au point de terminaison de l’éditeur. Ce sont donc les serveurs que peuvent utiliser les assistants web et mobiles, pour autant que l’assistant accepte les connexions distantes. L’éditeur exploite et met à jour le serveur : vous bénéficiez toujours de sa version actuelle - et subissez ses pannes.

L’authentification passe généralement par OAuth, qui vous fait approuver l’accès sur la page du service lui-même, où vous pourrez le révoquer plus tard, ou par une clé d’API envoyée dans un en-tête. Vos demandes transitent par les serveurs de l’éditeur, selon ses conditions.

Serveurs locaux

Un serveur local a besoin de son environnement d’exécution - Node.js pour les paquets npm, Python ou uv pour les paquets PyPI, Docker pour les images de conteneur - et d’un client capable de lancer des programmes : généralement une application de bureau, un éditeur de code ou un agent en ligne de commande. Il peut accéder à vos fichiers, à vos applications et à votre réseau local, et c’est la raison d’en choisir un.

Les identifiants sont placés dans des variables d’environnement de la configuration du client, sur votre ordinateur. Vous décidez quand mettre à jour, et pouvez figer une version pour que le serveur ne change pas à votre insu.

Les questions qui tranchent

L’assistant que vous utilisez accepte-t-il les serveurs distants, les serveurs locaux, ou les deux ? La tâche nécessite-t-elle des fichiers ou des applications locales ? Les identifiants doivent-ils rester sur votre ordinateur, ou une connexion révocable auprès du service est-elle préférable ? Qui assurera les mises à jour ? La page de chaque serveur de cet annuaire indique les types qu’il propose, d’après son entrée dans le registre.