# Serveur MCP GitHub : installation et coût réel > Le serveur MCP de GitHub est l'un des plus lourds, surtout par ce qu'il renvoie. Voici comment l'installer, le restreindre et garder ses réponses compactes. Source: https://tokenade.net/fr/articles/github-mcp-server · Updated: 2026-10-15 ## Qu'est-ce que le serveur MCP GitHub ? Le serveur MCP GitHub est l'implémentation [MCP](https://tokenade.net/fr/glossary/mcp) officielle de GitHub : il expose issues, pull requests, dépôts, Actions, alertes de sécurité et davantage sous forme d'outils que votre agent peut appeler directement. Vous pouvez l'utiliser comme endpoint hébergé sur `https://api.githubcopilot.com/mcp/`, ou le faire tourner vous-même depuis l'image Docker `ghcr.io/github/github-mcp-server`. Il est réellement utile — un agent capable de lire un diff de PR, de comprendre pourquoi la CI a échoué et d'ouvrir une issue sans copier-coller entre onglets supprime beaucoup de friction. C'est aussi, et de loin, l'un des serveurs les plus lourds à utiliser, surtout à cause de tout ce qu'il renvoie, et presque personne ne le mentionne au moment de vous dire de l'installer. ## Comment ajouter le serveur MCP GitHub ? Une commande pour l'endpoint hébergé, avec un token GitHub dans l'en-tête : ```bash claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \ --header "Authorization: Bearer " ``` L'authentification fonctionne de deux façons : un personal access token comme ci-dessus, ou OAuth — les serveurs MCP en HTTP le négocient automatiquement, et le panneau `/mcp` vous guide dans la connexion navigateur. OAuth est le meilleur défaut sur une machine personnelle ; un PAT à portée restreinte se raisonne plus facilement en CI ou sur un environnement partagé. Vous préférez rester local ? Faites tourner l'image Docker et pointez votre agent sur le processus en stdio. Mêmes outils, aucun trafic vers un endpoint hébergé, et contrôle total sur les flags de démarrage — ce qui compte, pour les raisons de la section suivante. Pour la mécanique générale — scopes, `.mcp.json`, expansion des secrets, états de connexion — voir [la configuration MCP de Claude Code](https://tokenade.net/fr/articles/claude-code-mcp-setup). ## Pourquoi coûte-t-il cher ? À cause de ce qu'il renvoie et, sur certaines configurations, de sa taille. Ses réponses sont le coût principal : `list_issues`, `list_pull_requests` ou `get_pull_request` reviennent sous forme de pages de JSON remplies d'URL, d'identifiants de nœuds, d'avatars, d'objets label et d'enregistrements utilisateur imbriqués, dont le modèle ne lit presque rien. Chaque résultat atterrit dans le contexte et reste dans l'historique : il est donc renvoyé à chaque tour suivant de la session. Le manifeste est volumineux lui aussi. Le serveur documente environ **82 outils répartis sur 20 toolsets** ; 56 sont en lecture seule, le reste en écriture. Sur les agents qui chargent les définitions d'outils d'emblée, chacun de ces schémas voyage à chaque tour. Les agents actuels le font rarement : Claude Code diffère par défaut les définitions d'outils MCP grâce au tool search (modèles Claude 4.5 et suivants), et ne charge un schéma que quand le modèle en a besoin. Derrière un proxy d'API tiers, avec `alwaysLoad` ou dans un agent sans tool search, le manifeste complet revient à chaque tour. Deux mises en garde honnêtes sur les chiffres, parce que c'est là que les articles dérapent : **GitHub n'a jamais publié de coût en tokens pour ce manifeste.** Les estimations tierces se contredisent franchement — 42 000, 55 000 et 64 600 tokens circulent pour le même serveur sur la même période. Méfiez-vous de tout chiffre précis, y compris présenté ailleurs comme un fait. **Le seul chiffre de l'éditeur est plus étroit qu'il n'y paraît.** Le [changelog de janvier 2026](https://github.blog/changelog/2026-01-28-github-mcp-server-new-projects-tools-oauth-scope-filtering-and-new-features/) annonce une économie d'« environ 23 000 tokens » en consolidant le toolset Projects en trois outils. C'est une économie sur un toolset issue d'un changement précis — pas la taille du manifeste complet, et pas un chiffre généralisable. Ce que vous pouvez faire à la place : mesurer le vôtre. Lancez `/context` dans une session fraîche avant de taper quoi que ce soit, branchez le serveur, redémarrez, comparez. Traitez ensuite quelques issues ou PR et regardez à nouveau : l'écart, c'est le coût de ses réponses. Deux minutes, et les chiffres sont réellement les vôtres. ## Comment réduire son coût sans y renoncer ? Deux leviers : restreindre ce qu'il expose, et réduire ce qu'il renvoie. Le premier est ce qui rend ce serveur particulier : contrairement à la plupart, il fournit de vrais contrôles pour restreindre ce qu'il annonce. Moins d'outils, c'est moins de risques que le modèle choisisse le mauvais, aucun droit d'écriture non voulu, et un manifeste plus petit partout où les outils se chargent encore d'emblée. **Choisissez vos toolsets.** Cinq seulement sont actifs par défaut (`context`, `issues`, `pull_requests`, `repos`, `users`) sur vingt. Si votre travail est la revue de PR, deux peuvent suffire : ```bash --toolsets pull_requests,repos # ou, dans l'environnement Docker GITHUB_TOOLSETS="pull_requests,repos" ``` **Passez en lecture seule si vous n'écrivez pas.** `--read-only` (ou `GITHUB_READ_ONLY=1`) supprime tous les outils d'écriture, soit l'essentiel de l'écart entre 82 et 56 outils. C'est aussi une posture de sécurité raisonnable pour un agent autonome : il peut enquêter, il ne peut rien ouvrir ni fermer. **Sélectionnez à l'outil près.** `--tools` et `--exclude-tools` permettent de composer un ensemble à la main : `--toolsets repos --tools get_gist` ajoute un outil venu d'un toolset non activé. **N'allez pas chercher `--dynamic-toolsets`.** Il a été retiré en mai 2026. Des guides le mentionnent encore ; il n'existe plus. **Réduisez les réponses.** Les flags ci-dessus ne changent rien à la verbosité de chaque résultat. Pour cela, il faut une couche entre l'agent et le serveur : le proxy MCP de [Tokenade](https://tokenade.net/fr) (`tokenade mcp-wrap install github`) fait passer la sortie de GitHub par un compacteur dédié avant qu'elle n'atteigne le modèle, en gardant les champs dont l'agent se sert et en repliant le reste. Le résultat complet reste récupérable si l'agent a besoin d'un détail. Le réflexe à acquérir : l'installation par défaut est l'installation large. Quelques flags à la connexion ne coûtent rien ; sur les configurations sans chargement différé, ils se remboursent à chaque tour, la même logique que le [lazy MCP loading](https://tokenade.net/fr/articles/lazy-mcp-loading) appliquée à la main. ## De quels toolsets avez-vous réellement besoin ? De moins que le défaut, dans la plupart des cas. Les cinq activés d'office couvrent un profil « usage général de GitHub », bon défaut produit mais rarement le bon ajustement pour un projet précis. Faire correspondre le travail au toolset est une décision de deux minutes qui garde l'agent concentré sur les outils dont il a besoin. Points de départ indicatifs, selon ce que vous faites : - **Relire des pull requests.** `pull_requests` et `repos`. Vous avez besoin des diffs et du contenu des fichiers ; pas de Dependabot, des discussions ni des stargazers. - **Trier des issues.** `issues` et `labels`, plus `orgs` si vous travaillez sur plusieurs organisations. Supprimez `pull_requests` si le tri est une session distincte de la relecture. - **Déboguer la CI.** `actions` et `repos`. C'est le cas où le serveur gagne le plus clairement sa place : lire un run échoué bat un agent qui devine à partir du YAML. - **Travail de sécurité.** `code_security`, `secret_protection`, `security_advisories`, `dependabot`. Ensemble lourd, mais chargé uniquement dans les sessions qui en ont besoin. - **Lire un dépôt qui n'est pas le vôtre.** `repos` et `context`, en `--read-only`. Surface minimale, aucun risque d'écriture. Ce qui compte le plus n'est pas de trouver l'ensemble parfait, c'est d'en avoir *un* plutôt que d'accepter les défauts. Deux toolsets en `--read-only` représentent une fraction de la surface par défaut, et couvrent l'essentiel de ce que vous appellerez dans une session mono-objectif. Une réserve : trop restreindre a son propre coût. Si l'agent a besoin d'un outil que vous avez exclu, il ne peut pas l'appeler — et il contournera généralement en lisant des fichiers, ce qui coûte plus cher que l'outil n'aurait coûté. Partez du workflow, pas d'un objectif chiffré d'outils. ## Faut-il le faire tourner du tout ? Oui si vous travaillez réellement via GitHub depuis votre agent — non si vous l'avez branché une fois sans l'appeler depuis. Le test n'est pas de savoir si le serveur est utile en principe, mais s'il a gagné sa place cette semaine. Un serveur qui répond « pourquoi la CI a-t-elle échoué sur cette PR » en un appel bat un agent qui lit des fichiers de workflow et devine. Un serveur inutilisé dans un projet sans lien avec GitHub est au mieux de l'encombrement, et du surcoût à chaque tour sur les configurations qui chargent les outils d'emblée. Si vous le gardez, cantonnez-le aux projets concernés plutôt qu'en installation globale, et restreignez les toolsets au travail réellement effectué. Si vos sessions sont dominées par la sortie MCP, [Tokenade](https://tokenade.net/fr) compacte ce que renvoient les serveurs MCP avant que cela n'entre dans le contexte — la sortie de GitHub a son compacteur dédié, tous les autres serveurs connectés un compacteur générique — sur Claude Code, Cursor, Codex, Copilot et Windsurf. ## Quelles alternatives au MCP GitHub consomment moins de tokens ? L'alternative la moins chère, c'est souvent de ne pas utiliser de serveur MCP du tout : laissez l'agent lancer la CLI officielle `gh` dans son shell. Une CLI n'ajoute aucune liste d'outils, et des flags comme `--json` avec `--jq` ne renvoient que les champs demandés. Si vous gardez le serveur MCP, un toolset étroit en `--read-only` en est la version économe. Trois options, de zéro configuration à la plus outillée : - **`gh` via le shell de l'agent.** `gh pr view 123 --json title,files`, `gh pr diff 123`, ou `gh run view --log-failed` pour ne récupérer que les étapes en échec d'un run de CI. Vous payez la sortie de l'appel effectué, rien d'autre. - **Le serveur de GitHub, restreint.** `--toolsets` plus `--read-only`, comme plus haut. Le même serveur, une fraction de la surface. - **Une couche de compaction par-dessus.** [Tokenade](https://tokenade.net/fr) compacte les résultats MCP (avec un compacteur GitHub dédié) et les sorties de commandes, `gh` compris, avant qu'ils n'atteignent le modèle. Il tourne en local, via un proxy MCP et les hooks de votre agent. Le compromis : la sortie de `gh` est du texte que le modèle doit analyser, alors que le MCP renvoie des résultats structurés. Pour un « pourquoi la CI a échoué » ponctuel, la CLI gagne. Pour une longue session qui enchaîne issues et PR, un serveur MCP restreint peut rester le choix le plus propre. ## Ce qui tourne mal (anti-patterns) **L'installer par défaut et l'oublier.** Cinq toolsets que vous n'avez pas choisis, dans chaque projet, et à chaque tour si votre configuration charge les outils d'emblée. **Laisser les réponses brutes s'accumuler.** Une longue session de tri peut remplir le contexte de JSON d'issues que le modèle n'a parcouru qu'une fois. Compactez-le avant qu'il n'arrive. **La portée globale.** Un serveur GitHub qui vous suit dans un dépôt qui n'est pas sur GitHub encombre pour rien. **Citer une taille de manifeste lue sur un blog.** Les estimations divergent de plus de 20 000 tokens. Mesurez la vôtre. **Utiliser `--dynamic-toolsets`.** Retiré en mai 2026. Si un guide le recommande, il est périmé — traitez le reste de ses conseils en conséquence. **Accorder les droits d'écriture par défaut.** `--read-only` retire la majorité des outils et la majorité du rayon d'action. Ajoutez l'écriture quand vous en avez besoin, pas avant. ## Foire aux questions ### Le serveur MCP GitHub est-il gratuit ? Le serveur est open source et l'image Docker est publique : le faire tourner ne coûte rien au-delà des tokens qu'il met dans votre contexte, surtout par ses réponses. L'endpoint hébergé est lié à votre compte GitHub. Le vrai coût est contextuel, pas monétaire. ### Faut-il un PAT, ou OAuth suffit-il ? Les deux fonctionnent. OAuth est plus fluide sur une machine personnelle : le panneau `/mcp` gère la connexion navigateur et vous ne collez aucun token. Un PAT à portée restreinte s'audite et se renouvelle plus facilement, ce qui en fait généralement le bon choix en environnement partagé ou automatisé. ### Combien d'outils expose-t-il réellement ? Environ 82 répartis sur 20 toolsets, dont 56 en lecture seule. Cinq toolsets seulement sont actifs par défaut. Le compte évolue d'une version à l'autre — raison de plus pour mesurer votre propre contexte plutôt que de faire confiance à un chiffre lu quelque part, y compris celui-ci dans six mois. ### Peut-on l'utiliser hors de Claude Code ? Oui. C'est un serveur MCP standard : tout hôte parlant MCP peut s'y connecter — Cursor, Codex, Copilot, Windsurf et d'autres. Le format de configuration diffère selon l'hôte, tout comme le chargement différé des définitions d'outils ; la taille de ses réponses, non. [Les serveurs MCP expliqués](https://tokenade.net/fr/articles/mcp-servers-explained) traitent la vue d'ensemble. ### Quelle différence entre `--toolsets` et `--tools` ? `--toolsets` sélectionne des groupes entiers (`pull_requests`, `actions`, `security_advisories`…). `--tools` sélectionne des outils individuels par leur nom, et peut en tirer un d'un toolset non activé par ailleurs. `--exclude-tools` retire des outils précis de ce que le reste de la configuration a sélectionné. Les trois se combinent. --- **À voir aussi :** - [Serveurs MCP : ce qu'ils sont et ce qu'ils coûtent](https://tokenade.net/fr/articles/mcp-servers-explained) — la vue d'ensemble, tous agents confondus. - [Claude Code MCP : comment le configurer](https://tokenade.net/fr/articles/claude-code-mcp-setup) — transports, scopes, secrets. - [Meilleurs serveurs MCP Claude Code, classés au coût réel](https://tokenade.net/fr/articles/best-mcp-servers-for-claude-code) — où se situe celui de GitHub face aux autres. - [Lazy MCP loading](https://tokenade.net/fr/articles/lazy-mcp-loading) — désormais intégré à la plupart des agents, et quand le configurer encore.