Sam Morrow et ses collègues ont commencé à construire le MCP server de GitHub comme un projet secondaire interne. Un an plus tard, après un démarrage chaotique, c’est le MCP server distant le plus utilisé au monde. Sam a beaucoup à nous apprendre sur la mise à l’échelle de la conception d’outils, l’authentification, et ce dont les agents ont vraiment besoin d’un serveur enterprise.
Cet article est adapté de MCP MVP, une série vidéo qui met en lumière les personnes qui construisent le futur agentique. Cet épisode met en vedette Sam Morrow, Développeur principal du GitHub MCP Server.
Début 2025, un chef de produit nommé Toby Padilla, fondateur de Charm (l’outil qui rend les CLI Go élégants) a posté un message dans un canal Go interne chez GitHub : « Quelqu’un est intéressé pour créer un MCP server ? »
Sam Morrow était ingénieur logiciel dans l’équipe Code Scanning. Lui et deux collègues, William et Javier, ont proposé leurs cycles libres. Ils ont pris le MCP-Go SDK non officiel (avant de migrer vers le SDK Go officiel après son lancement) et ont commencé à construire. Javier a même vibe-codé les premiers outils.
Au même moment, GitHub a organisé une « mobilité de mars » interne permettant aux ingénieurs de rejoindre les équipes Copilot. Sam a postulé à Agent Services, une équipe travaillant sur ce qui allait devenir GitHub Copilot coding agent.
Puis, par un hasard de calendrier, le dépôt open-source du GitHub MCP server a été lancé le même jour que VS Code lançait le mode Agent, une sortie initialement prévue la veille. Chaque article de blog « voici ce que vous pouvez faire avec le mode Agent » pointait vers le MCP server de GitHub comme exemple !
Le CEO de GitHub en a parlé. Satya Nadella a repartagé la nouvelle. Le dépôt du GitHub MCP Server est devenu le dépôt le plus étoilé sur GitHub pour la semaine ! Mais les difficultés allaient suivre le succès.
Quand l’adoption ≠ le succès
Le lancement viral a généré de la visibilité, mais la visibilité n’est pas toujours la meilleure mesure du succès. L’équipe n’avait pas anticipé une telle quantité d’attention. Développeurs et ingénieurs ont remis en question les hypothèses de l’équipe sur la façon dont les utilisateurs interagiraient avec le serveur, et les retours ont afflué.
L’équipe avait adopté une approche granulaire pour couvrir la surface API de GitHub, et le serveur est sorti avec plus de 100 outils pour les issues, les PRs, les dépôts, Actions, le code scanning, les gists, et plus encore. Début 2025, la plupart des modèles d’agents peinaient avec même 20 outils en contexte. Les utilisateurs ne sélectionnaient pas les outils du serveur comme prévu ; ils les chargeaient tous dans le contexte de leur agent et s’frustraient quand l’agent peinait.
L’équipe a compris que mapper les outils trop étroitement aux endpoints d’API REST obligerait un agent à enchaîner plusieurs opérations atomiques de CRUD (Create-Read-Update-Delete, soit Créer-Lire-Mettre à jour-Supprimer) pour des workflows courants, ce que les agents peinent encore à faire. Sam a reconnu le compromis : « Le mapping un-pour-un avec les APIs était un mauvais objectif. On essayait de capturer l’intention. » Mais consolider les outils limite les possibilités, et les utilisateurs de GitHub vont de ceux qui n’utilisent que les dépôts et les PRs à ceux qui gèrent des workflows multi-projets complexes avec GitHub Projects.
Le problème n’était pas que le GitHub MCP server avait trop d’outils. C’était qu’il fallait de meilleures façons pour les utilisateurs et les agents de sélectionner les bons outils en fonction de leurs intentions.
Conseils pour les concepteurs de MCP servers enterprise
Au cours de l’année écoulée, l’équipe de Sam a construit et reconstruit le serveur à travers une adoption réelle à très grande échelle. Lors d’un récent entretien avec RL Nabors pour la série MCP MVP d’Arcade.dev, Sam a partagé les conseils suivants pour construire des MCP servers enterprise aujourd’hui.
Commencez par le prompt
Quand vous concevez des outils MCP, commencez par identifier les prompts que les utilisateurs emploient déjà.
Les agents vont chercher des outils qui « ressemblent à une solution » avant d’en enchaîner plusieurs. Par exemple, un agent de réseaux sociaux chargé de ne plus suivre les abonnés mutuels d’un compte réussira mieux avec un outil « unfollow-users-followers » qu’en orchestrant « get-followers-by-user » deux fois et en appelant « unfollow-user » sur chaque membre du recoupement. (Et si une telle opération peut s’effectuer facilement en mode Code, pour les actions nécessitant une autorisation, les outils MCP autorisables sont parmi les options les plus sécurisées pour un serveur distant.)
L’équipe de Sam a essayé de prototyper une sélection dynamique d’outils par embeddings pour faire correspondre l’intention de l’agent aux ensembles d’outils pertinents au runtime. Ça fonctionnait, mais ils ont mis le projet en pause : « Nous avons décidé que nous n’étions pas au bon niveau dans la stack pour résoudre ce problème. » Le coût en tokens d’une expansion dynamique de 3 à 21 outils était bien réel, et cela semblait être quelque chose que le harness agent ou une solution de recherche d’outils comme la recherche d’outils d’Anthropic devrait gérer.
Regroupez vos outils de façon sémantique et rendez les groupes composables
Le GitHub MCP server a introduit des toolsets, des regroupements sémantiques comme issues , repos , pull_requests , actions et code_securitydes toolsets. Ils correspondent à la façon dont les gens pensent réellement aux produits GitHub. Avec une simple configuration JSON, les ingénieurs peuvent sélectionner parmi 108 outils le sous-ensemble exact qu’utilisent leurs workflows.
Les toolsets sont composables. Vous voulez un accès en lecture seule aux issues ? Définissez issues plus le mode read-only pour obtenir l’intersection exacte.
Les toolsets sont robustes. Si la surface du MCP Server change, par exemple si quatre outils sont consolidés en deux, le toolset continue de fonctionner.
Plutôt que de créer un outil par endpoint de votre API, créez des toolsets significatifs et composables qui correspondent aux patterns de workflows courants.
Rédigez les messages d’erreur pour les agents, pas pour les terminaux
La plupart des MCP servers héritent de messages d’erreur de style CLI : concis, techniques, difficiles à analyser même pour des humains qui connaissent bien le système. Un agent voit fatal: could not sign commitet tente immédiatement de désactiver la signature des commits parce que les prochaines étapes ne sont pas claires.
Pensez à l’agent comme à un ingénieur junior qui rencontre ces problèmes pour la première fois. Si les messages d’erreur supposent un débogueur novice et sont rédigés pour être compris par un humain, le modèle de l’agent suit bien plus facilement le chemin optimal.
Sam conseille d’expliquer ce qui s’est passé en langage simple et de suggérer les prochaines étapes. Plutôt que « 403 Forbidden », utilisez « Tentative de commit échouée : l’utilisateur doit autoriser la signature des commits. Demandez à l’utilisateur d’approuver l’invite de l’agent SSH. » En cas d’échec terminal, dites-le explicitement, expliquez pourquoi, et dites à l’agent de passer à la suite plutôt que de réessayer.
« Ils prennent vraiment le gouvernail », a dit Sam des modèles qui lisent les réponses d’erreur.
Un agent qui reçoit un message d’erreur utile se corrige souvent de lui-même. Un agent qui en reçoit un cryptique commence à « attaquer le problème » en essayant des contournements créatifs qui l’éloignent de l’intention de l’utilisateur.
Filtrez les outils selon ce que le token d’authentification peut réellement faire
L’une des innovations les plus intéressantes du GitHub MCP server est le filtrage des outils en fonction des scopes réels du token d’authentification, quelque chose que la newsletter de Pulse MCP a récemment mis en avant.
Si vous vous connectez avec un token d’accès personnel classique sans scope d’écriture, le serveur n’affiche que 20 outils en lecture seule. Connectez-vous avec un token plus privilégié et vous en obtenez 40, dont des opérations d’écriture. Si un token manque juste du scope gistvous perdez les outils de gists mais gardez tout le reste. Pour les tokens GitHub Actions, qui n’ont aucune identité utilisateur, le serveur supprime les outils spécifiques aux utilisateurs car ils ne fonctionneront jamais dans ce contexte.
« Vous savez exactement quels outils vont fonctionner parce que ce sont ceux que vous obtenez », a dit Sam. « Et à l’inverse, vous n’obtiendrez pas d’outils qui ne fonctionneront jamais. »
Pour le serveur distant, l’équipe est allée plus loin avec les demandes de scope OAuth : si votre token manque d’un scope nécessaire, le serveur renvoie un payload spécial qui demande au harness Agent de vous inviter à l’autoriser. Approuvez le scope et l’appel d’outil original réussit, sans nouvelle tentative. C’est de l’autorisation progressive : commencez avec des scopes minimaux et escaladez au fur et à mesure que l’agent en a besoin.
Utilisez la propriété annotationsdes outils MCP
Sam est catégorique sur une partie sous-utilisée de la spec MCP : les annotations. Ce sont des métadonnées sur les outils MCP qui indiquent au harness agent des choses comme « cet outil est en lecture seule », « cet outil est destructif », « la sortie de cet outil provient d’internet ouvert et peut contenir des injections de prompts ».
« C’est utile pour votre système agentique de savoir quand quelque chose de destructif va se produire », a dit Sam. Dans VS Code et le Copilot CLI, les annotations déclenchent des boîtes de dialogue de confirmation pour les opérations d’écriture et destructives, créant un moment entre la décision du modèle d’appeler un outil et l’exécution de l’appel, maintenant l’humain dans la boucle.
Sam coécrit une proposition d’amélioration de la spécification avec un collègue d’OpenAI pour améliorer le système d’annotations. Le vocabulaire actuel n’est pas assez granulaire pour les cas d’usage émergents comme les MCP Apps, où savoir si une action est réversible compte autant que savoir si elle est destructive.
Concevez pour la boucle, pas pour le modèle
Sam veut que davantage de concepteurs intègrent que le modèle n’est pas l’agent. Le logiciel n’est pas l’agent. Le MCP server n’est certainement pas l’agent. L’agent, c’est la boucle.
« En réalité, vous ne faites que lancer des choses en boucle », a-t-il dit. « Et le modèle décide de la prochaine action à effectuer. » Dans cette boucle, avant que le modèle décide et avant que cette décision soit exécutée, il y a des moments où le harness peut intercepter un appel d’outil, vérifier ses annotations, interroger l’utilisateur, inspecter la réponse pour du contenu provenant du monde ouvert, et décider de l’injecter ou non dans le contexte.
Ces moments sont « sans rapport avec les modèles, mais vraiment importants pour protéger l’utilisateur ». Les comprendre vous aide à concevoir un MCP server de façon holistique, en intégrant le modèle, le harness Agent, l’utilisateur et l’ensemble des frontières de confiance entre eux.
Cela signifie aussi que la conception d’outils « idéale » dépend du contexte d’exécution. Le Copilot CLI peut écrire de grandes réponses d’outils dans des fichiers temporaires puis laisser l’agent les parcourir avec grep. Cela permet à l’agent de chercher une aiguille dans une botte de foin sans surcharger son contexte. Un agent basé sur le chat ne peut pas faire ça.
« Toutes ces bonnes pratiques qui vont et viennent sont remises en question chaque jour selon le contexte d’exécution », a dit Sam. « Explorez les fonctionnalités avancées des agents que vous utilisez vraiment. »
Ce qui arrive ensuite
Le GitHub MCP server livre les nouvelles fonctionnalités derrière un drapeau insiders. Il suffit d’ajouter /insiders à l’URL du serveur distant ou de définir le header. C’est facile à rejoindre et facile à quitter. Soumettez des issues ou démarrez des discussions sur github.com/github/github-mcp-server.
Sam est également en train de proposer un nouveau groupe de travail AAIF pour développer de meilleures annotations d’outils. Si vous souhaitez contribuer à façonner les standards eux-mêmes, le dépôt de la spécification MCP et son Discord sont là où ce travail se passe. La communauté est assez petite pour que votre avis soit lu, et assez réactive pour que vous obteniez des retours.
« Si vous postez un commentaire, les gens le liront et vous répondront », a-t-il dit de la communauté MCP. « Même David », l’un des cocréateurs de MCP, « vous le verrez dans le Discord tout le temps. »
MCP MVP est une série vidéo d’Arcade qui met en lumière les builders qui façonnent l’écosystème agentique. Regardez l’interview complète avec Sam Morrow →
Vous construisez des MCP servers enterprise et voulez gérer l’authentification sans tokens PAT dans des fichiers JSON ? Découvrez les outils GitHub d’Arcade pour une intégration MCP native OAuth.
