Dix serveurs MCP qui donnent à un modèle d’IA local des capacités de manipulation et de perception.

D’abord, un modèle performant exécuté localement semble excellent : pas de requêtes vers le cloud, pas de abonnement mensuel. Puis arrive la première tâche de développement réelle : examiner une erreur dans un script Python écrit la veille au soir. À ce moment-là, le modèle local si ingénieux s’avère être aveugle : il ne peut pas voir les fichiers locaux, ni lire la documentation la plus récente en ligne, ni consulter un dépôt GitHub ou interroger une base de données.

Ainsi, le flux de travail se transforme en un travail manuel. Il faut ouvrir l’éditeur, trouver le code défectueux, le copier, le coller dans la chat, attendre, copier la correction, retourner à l’éditeur, remplacer le code ancien, et répéter. Le modèle possède l’intelligence, tandis que le développeur est contraint de jouer les yeux, les mains et le clavier du modèle.

C’est cette lacune que le Model Context Protocol (MCP) comble. Anthropic l’a introduit en 2024 comme un standard ouvert qui permet aux applications d’IA de se connecter à des outils externes, des fichiers, des bases de données, des API et d’autres sources de données. L’image la plus simple à se faire est celle d’un port USB pour l’IA. Au lieu de créer une intégration distincte pour chaque modèle et chaque outil, MCP leur offre un moyen commun de communiquer. Pour ceux qui exécutent des modèles localement, ce changement est considérable. Il est utile de connaître les dix serveurs correspondants.

1. Système de fichiers

Toute personne qui installe un seul serveur de cette liste devrait probablement commencer par ici. Un modèle local ne sait rien de ce qui se trouve sur le disque dur. Le serveur de système de fichiers accorde un accès contrôlé aux fichiers et dossiers choisis par l’utilisateur.

Imaginez un projet Python en désordre avec des dizaines de fichiers. Au lieu de coller tout le contenu dans une conversation, un développeur peut demander au modèle d’examiner le dossier backend pour déterminer pourquoi un jeton d’authentification expire prématurément. Le modèle analyse les fichiers autorisés, observe la manière dont les morceaux de code interagissent et aide à identifier la cause. Il peut également créer des fichiers, modifier du code, organiser des dossiers et analyser les configurations.

Les permissions sont un point essentiel. Accordez au serveur uniquement les répertoires dont il a vraiment besoin, car un accès illimité à toute la machine est rarement judicieux.

2. Firecrawl

Tout ceux qui ont effectué du scraping sur le web savent à quel point les sites peuvent être problématiques. Certains utilisent du HTML propre, d’autres s’appuient sur JavaScript, et d’autres encore changent leur layout six mois plus tard, ce qui brise tous les sélecteurs soigneusement écrits.

Firecrawl gère le balayage et l’extraction pour fournir du contenu plus facile à traiter par les systèmes d’IA. Grâce à son intégration MCP, un utilisateur peut fournir un site web au modèle et lui demander de récupérer et de comprendre les parties pertinentes, par exemple pour lire la documentation d’une bibliothèque et expliquer le fonctionnement de l’authentification. Le modèle reçoit directement le matériel, sans avoir à ouvrir manuellement les pages ni à copier-coller du contenu dans le modèle local. Pour ceux qui travaillent régulièrement avec de la documentation, des recherches et des données web, les économies de temps sont considérables.

3. SQLite

SQLite est omniprésent dans le développement. Il est léger, ne nécessite pas de serveur de base de données et se retrouve dans des prototypes, des applications de bureau, des tests ainsi que de petits projets. Cependant, un modèle local ne peut pas ouvrir directement la base de données ; c’est là que le serveur SQLite joue le rôle de pont.

Avec une application qui stocke des milliers d’enregistrements localement, un développeur peut éviter l’écriture manuelle de requêtes SQL et demander, par exemple, quels sont les cinq types d’erreurs enregistrés le plus souvent ce mois-ci. Le modèle examine le schéma, construit une requête appropriée, la exécute et explique les résultats obtenus. Cela est particulièrement utile lorsqu’on expérimente avec des applications locales et que l’on souhaite que le modèle travaille sur des données de projet réelles plutôt que sur des exemples inventés.

4. PostgreSQL

SQLite convient aux projets plus petits, mais de nombreuses applications sérieuses fonctionnent sous PostgreSQL. Un serveur PostgreSQL permet à l’assistant de travailler avec une telle base de données via MCP.

Supposons qu’une application web affiche soudainement une vague d’échecs de connexion. Au lieu de parcourir des tables et d’écrire plusieurs requêtes manuellement, le développeur peut demander quels utilisateurs ont eu le plus d’échecs de connexion au cours des 48 dernières heures. Le modèle examine le schéma disponible, écrit la requête nécessaire, l’exécute via la connexion autorisée et résume les résultats.

Les permissions sur la base de données méritent une attention particulière. Commencer par un accès en lecture seule est bien plus sûr que d’autoriser des écritures illimitées pour presque tout flux de travail d’IA.

5. GitHub

Une grande partie du développement moderne a lieu sur GitHub, il est donc avantageux de le connecter au modèle. En fonction des permissions et de l’implémentation, l’intégration peut mettre à disposition des dépôts, des problèmes, des demandes de fusion, des commits ainsi que des informations connexes.

Imaginez arriver devant une demande de fusion qui concerne 30 fichiers. Au lieu de lire chacun d’eux immédiatement, le développeur peut demander un résumé des modifications ainsi qu’une liste des domaines nécessitant une vérification de sécurité. Le modèle examine les données pertinentes et propose un point de départ pour l’examen. Il ne remplace pas un développeur expérimenté, mais il peut réduire considérablement le nombre d’enquêtes répétitives.

6. Brave Search

Une grande faiblesse des modèles locaux est que leurs connaissances intégrées deviennent obsolètes. Un modèle peut savoir comment fonctionnait une bibliothèque Python l’année dernière, sans aucune garantie qu’il connaisse la version publiée cette semaine.

Le serveur Brave Search offre une recherche web assistée. Un développeur peut demander la méthode actuellement recommandée pour configurer un paquet, et le modèle consulte des informations en temps réel plutôt que de se fier uniquement aux données d’entraînement. Cela est essentiel pour le travail logiciel, car la documentation, les API, les versions des paquets et les meilleures pratiques évoluent constamment. Le modèle local conserve ses avantages en matière de confidentialité tout en ayant accès au web en direct.

7. Puppeteer

Le scraping ne concerne pas toujours le téléchargement d’HTML. Les sites modernes dépendent fortement de JavaScript, de boutons, de formulaires et de contenu dynamique. C’est là que des outils d’automatisation de navigateur comme Puppeteer entrent en jeu. Avec un serveur Puppeteer, le modèle peut faire fonctionner un navigateur grâce aux fonctionnalités d’automatisation prises en charge.

Une tâche pourrait consister à ouvrir un site, à naviguer vers sa page de documentation et à trouver l’exemple de configuration pour l’authentification. Au lieu de ne lire que du contenu statique, le modèle fonctionne à l’intérieur d’un véritable navigateur. Pour les développeurs qui connaissent déjà l’automatisation des navigateurs, cela ouvre de nombreuses possibilités pour les agents locaux.

8. Git

Git et GitHub sont liés mais différents. Git est le système de contrôle de version qui fonctionne à l’intérieur de l’environnement de développement, et un serveur Git permet au modèle de travailler avec les commits, les branches et les modifications d’un répertoire local.

Celui-ci est utile lors du débogage. Un développeur peut se demander ce qui a changé entre les deux dernières commits et quelle modification a pu introduire une erreur. Sans MCP, cela signifie de lancer plusieurs commandes git puis de coller les résultats dans le chat. Avec MCP, l’assistant examine directement le contexte du répertoire. Le modèle cesse de voir le code comme des fichiers isolés et acquiert une certaine compréhension de l’histoire qui se cache derrière eux.

9. Pensée séquentielle

Chaque problème ne nécessite pas forcément une autre source de données. Parfois, le problème réside dans le raisonnement. Le débogage complexe implique plusieurs possibilités, hypothèses et décisions intermédiaires, et un serveur de pensée séquentielle permet au modèle de diviser un problème difficile en étapes plus petites de manière structurée.

Au lieu de se limiter à demander « pourquoi l’application plante-t-elle ? », un développeur peut confier une tâche de débogage plus approfondie couvrant les journaux d’activité, les dépendances, les modifications récentes et les causes probables. Ce flux structuré incite le modèle à travailler de manière méthodique plutôt qu’à se fier à la première explication qui semble convaincante. Ce n’est pas de la magie et cela ne garantit pas une réflexion correcte, mais pour des tâches complexes en plusieurs étapes, cette structure est utile.

10. Fetch

Parfois, un moteur de recherche complet ou une plateforme de balayage est excessif. Il n’y a qu’une URL, et le modèle doit la lire. Un serveur de type Fetch récupère une page et permet au modèle de la résumer, par exemple en lisant une page de documentation API et en expliquant son exemple d’authentification.

Cela fonctionne bien en complément des outils de recherche : un serveur de recherche trouve la bonne page et un serveur de récupération charge celle spécifique que le modèle doit comprendre. Cette fonctionnalité est simple, et ce sont souvent les fonctionnalités simples qui sont utilisées en permanence.

Qu’est-ce qui change lorsque les serveurs se combinent ?

Ce qui est intéressant avec MCP, ce n’est pas un serveur en particulier, mais plutôt ce qui se passe lorsque plusieurs travaillent ensemble. Imaginez un modèle local ayant accès aux fichiers du projet, au répertoire Git, aux problèmes GitHub, à une base de données, à un navigateur et au web en direct. Une tâche pourrait consister à : enquêter sur les raisons des pannes du système de connexion, vérifier les dernières modifications Git, examiner les fichiers Python pertinents, analyser les erreurs de la base de données, trouver la documentation actuelle relative à la bibliothèque d’authentification, et proposer une solution.

C’est une expérience complètement différente de coller du code et de se demander ce qui ne va pas. Le modèle ne se contente plus de répondre aux questions ; il devient un agent capable d’agir dans l’environnement de développement.

Une mise en garde s’impose : MCP ne rend rien automatiquement sûr. Chaque serveur installé est un logiciel supplémentaire qui peut accéder à des données, des fichiers ou des services. Préférez des implementations fiables, examinez attentivement les permissions, omettez l’accès en écriture qui n’est pas nécessaire, et ne donnez jamais à un serveur plus de pouvoirs que son fonctionnement ne l’exige. L’objectif n’est pas de contrôler l’ensemble de l’ordinateur, mais d’avoir juste assez d’accès pour être utile.

Au-delà de la fenêtre de chat

L’IA locale était autrefois soumise à une limite frustrante : un modèle puissant pouvait fonctionner en privé sur du matériel personnel, mais restait confiné dans une fenêtre de chat. MCP commence à abattre ce mur. Un modèle local performant, associé aux serveurs adéquats, peut devenir un assistant de développement surprenamment efficace. Plutôt que de demander à un modèle local ce qu’il sait, demandez-lui plutôt ce qu’il peut faire.