Serveur MCP de GitHub : brancher un assistant IA sur ses dépôts, sans tout lui ouvrir

Un serveur MCP est un connecteur : il permet à un assistant IA d'agir dans un outil au lieu de seulement en parler. Celui de GitHub est maintenu par GitHub lui-même, sous licence MIT. Il sert à lire des dépôts et du code, gérer des tickets (issues) et des demandes de fusion (pull requests), suivre les exécutions GitHub Actions, consulter les alertes de sécurité, les discussions et les notifications.

Deux façons de l'utiliser

La version hébergée. GitHub exploite le serveur à l'adresse https://api.githubcopilot.com/mcp/. Rien à installer : on déclare l'adresse dans son outil et on s'authentifie par OAuth, c'est-à-dire par une fenêtre de connexion GitHub classique. Dans VS Code (version 1.101 ou plus récente), la configuration tient en quelques lignes :

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

La version locale. Le serveur tourne sur votre poste, dans un conteneur Docker, avec un jeton d'accès personnel (PAT). Pour Claude Code, le README donne cette commande :

claude mcp add github -e GITHUB_PERSONAL_ACCESS_TOKEN=$GITHUB_PAT -- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server

Il est aussi possible de compiler le serveur soi-même en Go. Pour le jeton, le README recommande au minimum les permissions repo, read:packages et read:org.

Limiter ce que l'assistant peut faire

C'est le point fort de ce serveur : il se règle finement.

• Les groupes d'outils (toolsets). Par défaut, cinq groupes sont actifs : context, repos, issues, pull_requests et users. Les autres (Actions, Dependabot, sécurité du code, projets, etc.) s'ajoutent avec l'option --toolsets ou la variable GITHUB_TOOLSETS. La valeur all active tout.
• Le mode lecture seule. L'option --read-only (ou GITHUB_READ_ONLY=1) ne propose que les outils de consultation. L'assistant ne peut alors modifier ni dépôt, ni ticket, ni demande de fusion.
• Le mode verrouillage. L'option --lockdown-mode (ou GITHUB_LOCKDOWN_MODE=1) concerne les dépôts publics : le serveur vérifie que l'auteur d'un contenu a le droit d'écrire dans le dépôt avant de le transmettre à l'assistant. L'objectif est de réduire le risque qu'un inconnu glisse des instructions piégées dans un ticket.

Les limites à connaître

• Le mode verrouillage est présenté par GitHub comme un filtre « au mieux », pas comme une garantie. Il ne change rien à ce que le jeton peut lire ou écrire, et ne s'applique pas aux dépôts privés.
• La version hébergée ne fonctionne pas avec GitHub Enterprise Server. Dans ce cas, il faut la version locale et la variable GITHUB_HOST.
• La version locale demande Docker ou une compilation Go.
• Les noms d'outils doivent être exacts : une faute dans la configuration empêche le serveur de démarrer.

Les consignes de sécurité du README

GitHub recommande de stocker le jeton dans une variable d'environnement ou un fichier .env exclu du dépôt, d'utiliser un jeton distinct par projet, de le renouveler régulièrement et de restreindre les droits du fichier de configuration. Côté OAuth, les jetons ne sont conservés qu'en mémoire.

Notre lecture

Pour une petite équipe, c'est l'un des serveurs MCP les plus simples à justifier : il fait gagner du temps sur le tri des tickets et la relecture de code, et ses garde-fous sont documentés.

Notre conseil : commencez par la version hébergée, en lecture seule, avec les cinq groupes par défaut. N'ouvrez l'écriture que pour un usage précis, et créez pour cela un jeton limité aux dépôts concernés. Si vos dépôts publics reçoivent des contributions extérieures, activez le mode verrouillage, en gardant à l'esprit qu'il réduit le risque sans le supprimer. Nous n'avons pas testé ce serveur nous-mêmes : cette fiche s'appuie sur sa documentation.