Serveur MCP GitHub : installation, usage des tokens et limites de débit sans mauvaises surprises
Connectez le serveur MCP GitHub à VS Code, Claude Desktop ou Cursor avec OAuth ou un token restreint, allégez ses définitions d’outils grâce aux toolsets et au mode lecture seule, et gérez les limites de GitHub, 5 000 par heure et 80 par minute, sans erreurs 403 ou 429.
Branchez le serveur MCP GitHub sur votre éditeur et un agent IA peut lire les issues, relire les pull requests et ouvrir des branches pour votre compte. Il charge aussi une longue liste de définitions d’outils dans chaque conversation, et il consomme le quota de requêtes du token que vous lui confiez. Trois éléments déterminent si la configuration reste fluide ou devient pénible : la manière de vous connecter, le nombre de tokens de contexte que le serveur consomme et les limites de débit que vous atteignez en premier.
Tous les chiffres ci-dessous proviennent de la documentation de GitHub ou de mesures communautaires publiées en 2026, et chacun est signalé comme tel. Le nombre de tokens varie d’une version de serveur à l’autre : considérez-les comme des ordres de grandeur plutôt que comme des promesses. Il en va de même pour tout chiffre que vous lirez sur l’outillage MCP : vérifiez la version sur laquelle il a été mesuré avant de bâtir un budget dessus.
💡 En bref : utilisez le serveur distant, donnez-lui un token restreint, n’activez que les toolsets que vous utilisez et attendez au moins une minute lorsque GitHub répond 403 ou 429.
Serveur distant ou local ?
Les deux options exposent les mêmes outils GitHub. Ce qui change, c’est qui fait tourner le processus et comment vous vous connectez. Faites le mauvais choix et vous finirez à maintenir Docker sur cinq ordinateurs portables, ou à attendre GitHub pour une fonctionnalité dont vous aviez besoin la veille.
Les bases du serveur distant
GitHub héberge le serveur distant à https://api.githubcopilot.com/mcp/. Votre client pointe vers cette URL et vous vous connectez via le navigateur avec OAuth, ou vous envoyez un personal access token dans un en-tête Authorization. Il n’y a rien à installer ni à mettre à jour, car les nouveaux outils arrivent selon le calendrier de GitHub, pas du vôtre.
Le même hôte propose une variante insiders à https://api.githubcopilot.com/mcp/insiders pour les fonctionnalités en avant-première. Testez-la sur une machine de test avant qu’elle ne touche votre configuration quotidienne.
L’option Docker en local
Le serveur local est distribué sous forme d’image ghcr.io/github/github-mcp-server. Votre client le lance avec docker run -i --rm et communique avec lui via stdio. Vous choisissez la version, vous contrôlez chaque variable d’environnement et vous pouvez le faire pointer vers GitHub Enterprise Server avec GITHUB_HOST. Le prix : Docker sur chaque machine et un token stocké dans un fichier de configuration.
Serveur distant
Serveur Docker local
Installation
Aucune
Image Docker
Connexion
OAuth, ou un token dans un en-tête
Token dans GITHUB_PERSONAL_ACCESS_TOKEN, ou OAuth avec un port de rappel
Mises à jour
Gérées par GitHub
Vous tirez l’image
GitHub Enterprise Server
Non pris en charge
Pris en charge via GITHUB_HOST
Idéal pour
La plupart des développeurs individuels
Versions figées et Enterprise Server
Configuration en cinq minutes
Chaque extrait ci-dessous provient du README du projet. Collez-en un, redémarrez le client et demandez à l’agent de lister vos pull requests ouvertes comme test rapide. Si la liste s’affiche, la connexion fonctionne et tout ce qui suit relève du réglage.
VS Code avec OAuth
La voie la plus courte. Aucun token à créer et aucun secret à stocker.
L’indicateur password: true masque la valeur lorsque VS Code la demande, de sorte que le token n’est jamais écrit dans le fichier que vous pourriez versionner.
Configuration de Claude Desktop
Claude Desktop lance le serveur Docker local et lui transmet le token via une variable d’environnement :
Remplacez your_token_here par un vrai token et gardez ce fichier hors du contrôle de version. Cursor accepte une structure proche de celle des exemples VS Code.
💡 Si un token et OAuth sont tous deux configurés, le token l’emporte. La documentation du projet indique que GITHUB_PERSONAL_ACCESS_TOKEN est prioritaire sur OAuth.
Portées des personal access tokens
Le token est la seule partie de cette configuration qui peut vous nuire. Un agent qui détient un token large peut faire tout ce que ce token autorise, y compris des erreurs que vous ne feriez jamais à la main.
Choisir les portées les plus restreintes
Le README recommande trois portées :
Portée
Ce qu’elle autorise
repo
Opérations sur les dépôts
read:packages
Accès aux images Docker
read:org
Accès aux équipes de l’organisation
Commencez par repo et ajoutez les autres seulement lorsqu’un outil échoue avec une erreur de permission. Si vous ne travaillez que dans quelques dépôts, un token à granularité fine limité à ces dépôts est encore plus strict. Utilisez un token distinct pour chaque projet, afin que la révocation de l’un n’interrompe pas les autres.
Garder les tokens hors de Git
Trois habitudes évitent la plupart des fuites :
Placez le token dans une variable d’environnement ou une saisie de prompt, jamais dans un fichier de configuration versionné.
Restreignez les permissions de toute configuration locale avec chmod 600 ~/.your-app/config.json.
Renouvelez les tokens selon un calendrier, et révoquez-en un dès qu’il apparaît dans un diff.
Le coût réel des définitions d’outils
Un client MCP charge dans le modèle les définitions de chaque serveur connecté, afin que le modèle sache ce qu’il peut appeler. Cette charge compte dans votre fenêtre de contexte à chaque requête, que l’agent utilise un outil ou non. Selon les estimations de la communauté, une seule définition représente environ 300 à 600 tokens une fois le nom, la description et le schéma des paramètres ajoutés.
Le serveur GitHub comporte beaucoup d’outils, ce qui explique qu’il revienne dans toutes les discussions sur le gonflement du contexte.
Ce que disent les chiffres
Il s’agit de mesures communautaires publiées sur dev.to en 2026, et non de chiffres de GitHub :
Mesure
Tokens
Outils
Source
Surface complète des outils
environ 55 000
93
Piotr Hajdas
Surface complète, nombre réduit
environ 42 000
non précisé
The Daily Agent
Toolsets par défaut uniquement
environ 4 200
26
Ken Imoto
Sur une fenêtre de 200 000 tokens, le chiffre de 55 000 représente plus d’un quart de l’espace consommé avant même que vous ayez tapé un mot. Les toolsets par défaut représentent environ 2 %. Les chiffres diffèrent parce que les mesures portent sur des versions de serveur et des configurations de toolsets différentes.
Votre client compte aussi. Selon un article de 2026, Claude Code diffère par défaut les schémas d’outils MCP derrière une étape de recherche d’outils, et une mesure fait état d’une réduction de 46,9 % grâce à cela. Cursor, Windsurf et Gemini CLI chargent les définitions dès le départ : ils paient donc le plein tarif.
Réduire la charge avec les toolsets
Les toolsets activent ou désactivent des groupes entiers d’outils. Sans réglage, le serveur active context, issues, pull_requests, repos et users. Le reste de la liste comprend actions, code_quality, code_security, copilot, dependabot, discussions, gists, git, governance, labels, notifications, orgs, projects, secret_protection, security_advisories et stargazers. Les valeurs spéciales all et default font ce qu’elles disent.
Pour le serveur local, définissez GITHUB_TOOLSETS :
docker run -e GITHUB_PERSONAL_ACCESS_TOKEN=<token> \
-e GITHUB_TOOLSETS="repos,issues,pull_requests" \
ghcr.io/github/github-mcp-server
Pour le serveur distant, envoyez l’en-tête X-MCP-Toolsets avec la même liste séparée par des virgules :
Deux autres contrôles affinent le résultat. GITHUB_TOOLS (ou l’en-tête X-MCP-Tools) ajoute des outils individuels par-dessus vos toolsets, par exemple get_gist sans activer tous les outils de gists. X-MCP-Exclude-Tools retire des outils, et la documentation précise que les outils exclus sont prioritaires sur les toolsets et les outils individuels.
💡 Résistez à all. Passer d’environ 4 200 tokens de définitions à environ 55 000 vous achète des outils que vous n’appellerez probablement jamais, et vous les payez à chaque requête.
Modes lecture seule et Lockdown
Deux interrupteurs réduisent la portée des dégâts sans toucher à vos toolsets :
Mode
Serveur local
Serveur distant
Effet
Lecture seule
--read-only ou GITHUB_READ_ONLY
X-MCP-Readonly: true, ou le chemin /mcp/x/all/readonly
Désactive chaque outil d’écriture, même ceux que vous avez demandés
Lockdown
--lockdown-mode ou GITHUB_LOCKDOWN_MODE
En-tête X-MCP-Lockdown
N’expose que le contenu des dépôts publics provenant d’utilisateurs ayant un accès en écriture
Le mode lecture seule agit comme un filtre strict qui prime sur le reste de votre configuration, et les outils désactivés signifient aussi moins de définitions à charger. Le mode Lockdown compte lorsqu’un agent lit des issues ou des commentaires écrits par des inconnus, car le texte de personnes sans accès en écriture est précisément l’endroit où se cachent les instructions malveillantes. En mode HTTP, une fois qu’un opérateur active Lockdown sur le serveur, l’en-tête X-MCP-Lockdown ne peut plus le désactiver pour une seule requête.
Les limites de débit que vous atteindrez vraiment
Le serveur appelle l’API GitHub sous votre identité ; les limites qui comptent sont donc celles que GitHub documente pour son API REST. Deux niveaux s’appliquent : une limite principale par heure et des limites secondaires par minute.
Limites principales par heure
Appelant
Limite
Non authentifié
60 requêtes par heure
Utilisateur authentifié (token, application OAuth ou GitHub App)
5 000 par heure
Applications détenues ou approuvées par des organisations Enterprise Cloud
15 000 par heure
Installations de GitHub App hors Enterprise
5 000, pouvant monter jusqu’à 12 500
GITHUB_TOKEN dans Actions
1 000 par heure et par dépôt (15 000 sur Enterprise Cloud)
À 5 000 par heure, vous disposez en moyenne d’environ 83 appels par minute. Un agent qui liste les issues d’un dépôt, ouvre chacune d’elles puis lit chaque commentaire peut dépenser des centaines d’appels en quelques minutes ; le budget horaire est donc une contrainte réelle lors des grosses sessions de tri.
Limites secondaires par minute
Les limites secondaires existent pour freiner les rafales, et les agents produisent des rafales. GitHub les documente ainsi :
100 requêtes simultanées au maximum.
900 points par minute pour les endpoints REST.
90 secondes de temps CPU par 60 secondes de temps réel.
80 requêtes de génération de contenu par minute et 500 par heure.
2 000 requêtes de token d’accès OAuth par heure.
Les appels d’outils en parallèle butent sur la limite de concurrence. Un agent qui commente des dizaines d’issues dans une boucle atteint le plafond de 80 contenus par minute bien avant d’entamer le budget horaire.
Corriger les erreurs 403 et 429
Lorsqu’une limite est atteinte, GitHub répond 403 ou 429. Lisez les en-têtes de réponse avant de modifier quoi que ce soit :
En-tête
Signification
x-ratelimit-limit
Nombre maximal de requêtes par heure
x-ratelimit-remaining
Requêtes restantes dans la fenêtre en cours
x-ratelimit-used
Requêtes effectuées dans la fenêtre en cours
x-ratelimit-reset
Moment de réinitialisation de la fenêtre, en secondes epoch UTC
x-ratelimit-resource
Ressource à laquelle la requête a été comptée
Une temporisation qui fonctionne
Si la réponse contient un en-tête retry-after, attendez le nombre de secondes indiqué.
Sinon, attendez jusqu’à l’heure indiquée dans x-ratelimit-reset.
Pour les limites secondaires sans en-têtes, attendez au moins une minute, puis allongez le délai de façon exponentielle à chaque nouvel échec.
Inscrivez aussi la règle dans les instructions de votre agent : lorsque GitHub renvoie 403 ou 429, il doit s’arrêter et signaler le problème au lieu de réessayer. Un agent qui réessaie aussitôt ne fait que consommer davantage de requêtes contre une limite qui ne s’est pas réinitialisée.
3 erreurs courantes
Activer tous les toolsets. Le contexte se remplit de définitions d’outils et l’agent devient plus lent et moins précis pour choisir ses outils.
Écrire en boucle. Les commentaires, labels ou issues en masse atteignent très vite le plafond de 80 contenus par minute. Découpez le travail en lots et marquez une pause entre chaque lot.
Réutiliser un token large partout. Quand il fuit ou se comporte mal, tout casse d’un coup. Donnez à chaque projet son propre token restreint.
Faire travailler un modèle PicassoIA
Le serveur MCP GitHub renvoie de la matière brute : listes d’issues, diffs, fils de commentaires. Un modèle de langage transforme cela en décisions. Claude Sonnet 5 sur PicassoIA gère les tâches de codage et d’utilisation d’outils en plusieurs étapes, lit les captures d’écran et vous laisse régler le niveau de réflexion, ce qui en fait un bon second regard sur ce que renvoie votre agent GitHub.
Collez la liste d’issues ou le diff renvoyé par votre agent dans le champ Prompt. Supprimez d’abord les tokens et les données privées.
Définissez une fois le System Prompt, par exemple : « You review pull requests and flag risky changes in three bullets. » Réutilisez-le pour tout le projet.
Choisissez le niveau Effort. low est la valeur par défaut et la plus rapide, tandis que high ou max convient à un bug qui touche plusieurs fichiers.
Laissez Max Tokens à 8 192, sauf si la réponse est coupée.
Joignez une capture d’écran de l’erreur dans le champ Image lorsque le texte seul ne suffit pas.
PicassoIA propose aussi sa propre API développeur et son connecteur MCP, et la même logique de limites s’applique. L’API se trouve à https://api.picassoia.com/v1, accepte des identifiants Bearer commençant par pia_sk_ et exécute les tâches de façon asynchrone : vous créez une prédiction, vous l’interrogez, puis vous récupérez le résultat. Quatre modèles sont accessibles via l’API et MCP : PicassoIA Image, PicassoIA Image Editor Pro, PicassoIA Video et Seedance 2.5 Lite. Un compte peut exécuter 5 prédictions simultanées, partagées entre les identifiants et les connexions MCP. Même leçon que les 100 requêtes simultanées de GitHub : le plafond de concurrence est le premier mur que heurte un agent parallèle.
Essayez sur Picasso IA
Votre README, vos notes de version et vos modèles d’issues gagnent à présenter une vraie image en tête. Générez un en-tête photoréaliste avec PicassoIA Image, puis affinez le cadrage ou corrigez un détail avec PicassoIA Image Editor Pro.
Trois prompts à essayer dès aujourd’hui :
Un bureau de développeur bien rangé au lever du soleil, avec un ordinateur portable, un carnet et une tasse, photographié sur pellicule 35 mm.
Une allée étroite de salle serveur avec une lumière douce au plafond et des câbles bien rangés, grand angle.
Une séance de revue d’équipe tranquille autour d’une table en bois, lumière naturelle de fenêtre.
Choisissez-en un, générez quelques variations et voyez laquelle fait ressortir votre prochaine page de dépôt. Commencez à créer vos propres images avec Picasso IA et expérimentez jusqu’à ce que le résultat ressemble à votre projet.