Le MCP Steering Group maintient un ensemble de serveurs de référence sur modelcontextprotocol/servers. Ce sont les exemples canoniques de la façon dont un serveur MCP doit être construit ; ils valent la peine d’être étudiés lors de la conception de serveurs personnalisés.
Serveurs activement maintenus
Sept serveurs restent sous développement actif du Steering Group au début 2026 :
| Serveur | Description |
|---|---|
| Everything | Serveur de référence/test illustrant les trois primitives : prompts, ressources et outils. Le « hello world » du design de serveur MCP. |
| Fetch | Récupère du contenu web et le convertit pour une utilisation efficace par les LLM. Gère les formats web courants afin d’éviter de coller des URL dans le chat. |
| Filesystem | Opérations sécurisées sur les fichiers avec contrôles d’accès configurables. Permet de spécifier les répertoires que l’IA peut lire et écrire. |
| Git | Lecture, recherche et manipulation de dépôts Git. Utile pour la revue de code et l’exploration de dépôts. |
| Memory | Système de mémoire persistante fondé sur un graphe de connaissances. Permet à l’IA de maintenir des notes structurées entre les sessions. |
| Sequential Thinking | Résolution de problèmes dynamique via des séquences de réflexion. Aide l’IA à décomposer des tâches de raisonnement complexes. |
| Time | Capacités de conversion de temps et de fuseaux horaires. Plus simple qu’il n’y paraît, mais véritablement utile. |
Tous sont écrits en TypeScript. Tous illustrent les bonnes pratiques pour l’outil qu’ils implémentent.
Notes sur certains serveurs
Filesystem est largement utile pour le travail d’ingénierie de données. L’IA lit directement les fichiers SQL, les modèles dbt et les fichiers de configuration. Les chemins autorisés sont définis dans la configuration et appliqués par le serveur.
Git est utile pour tout flux de travail impliquant la revue de code ou l’exploration de dépôts : résumé des commits récents, exploration des changements de branches ou révision de l’historique de fichiers. Pour les projets dbt, il permet à l’IA de comprendre ce qui a changé dans une PR sans quitter le terminal.
Everything montre comment les trois primitives (outils, ressources, prompts) fonctionnent ensemble dans une seule implémentation. Il sert de référence pour la construction de serveurs personnalisés, non comme une dépendance de production.
Serveurs archivés et transférés
Plusieurs serveurs de référence originaux ont été archivés depuis le dépôt du Steering Group et transférés à la maintenance des éditeurs ou de la communauté. Ils fonctionnent toujours — le code n’a pas disparu — mais l’équipe MCP centrale ne les met plus à jour.
Serveurs de bases de données transférés à la communauté :
- PostgreSQL — l’intégration de base de données originale, désormais maintenue par la communauté
- SQLite — également maintenu par la communauté
- Redis — maintenu par la communauté
Intégrations de plateformes transférées aux éditeurs :
- GitHub — désormais maintenu directement par GitHub
- Slack — désormais maintenu par Zencoder
- Google Drive — maintenu par la communauté
- Brave Search — désormais maintenu par Brave
Outils de développement transférés à la communauté :
- Puppeteer — automatisation de navigateur, maintenu par la communauté
- Sentry — intégration de suivi des erreurs
- AWS KB Retrieval — intégration de base de connaissances AWS
Les serveurs maintenus par les éditeurs reçoivent généralement des mises à jour plus rapides lors des changements d’API en amont et une meilleure intégration avec la feuille de route de la plateforme que leurs équivalents maintenus par la communauté.
Utiliser les serveurs de référence comme modèles de conception
Au-delà de leur utilité pratique, les serveurs de référence méritent d’être étudiés si vous construisez les vôtres. Ils montrent :
Comment structurer les descriptions d’outils. Les outils du serveur Filesystem ont des descriptions qui guident l’IA sur le moment d’utiliser read_file plutôt que list_directory ou search_files. La formulation compte — c’est ce que l’IA utilise pour décider quel outil appeler.
Comment implémenter des limites de sécurité. Le serveur Filesystem montre comment appliquer des restrictions de chemin au niveau du serveur, pas seulement dans la configuration. Le serveur valide chaque chemin par rapport à la liste autorisée avant d’exécuter toute opération.
Comment gérer les erreurs gracieusement. Les serveurs de référence renvoient des messages d’erreur structurés qui aident l’IA à comprendre ce qui s’est mal passé et quoi tenter à la place, plutôt que de propager des exceptions brutes.
Comment le code indépendant du transport se présente. Tous les serveurs de référence fonctionnent avec les transports stdio et HTTP sans modification de la logique métier. La configuration du transport est isolée dans le code de démarrage.
Pour l’écosystème complet — serveurs spécifiques aux bases de données, intégrations de plateformes de données et outils éditeurs — voir MCP Data Engineering Servers et MCP Discovery Resources.