GitHub MCP Server

✓ Officiel★ 31.389

Serveur MCP maintenu par GitHub lui-même pour les dépôts, pull requests, issues, recherche de code et informations CI/CD — en distant ou en local, avec connexion OAuth.

Le GitHub MCP Server connecte les agents directement à la plateforme GitHub — selon deux modes de fonctionnement. Le serveur distant est hébergé par GitHub lui-même sous https://api.githubcopilot.com/mcp/ et constitue, selon le README, l'entrée la plus simple : connexion par OAuth dans le navigateur (le token ne reste alors qu'en mémoire) ou, en alternative, via un Personal Access Token (PAT) dans l'en-tête Authorization: Bearer. Pour qui préfère tout garder en local, le serveur peut être lancé comme conteneur Docker (ghcr.io/github/github-mcp-server) avec un PAT ou un callback OAuth — ou compilé soi-même depuis les sources via go build.

Les capacités sont organisées en toolsets, que l'on peut activer et désactiver de façon ciblée : repos (opérations sur les dépôts), issues, pull_requests, actions (CI/CD), code_security (scan de code et de secrets), ainsi que dependabot, discussions, gists, projects, orgs, users, notifications et labels. Sans indication particulière, context, repos, issues, pull_requests et users sont actifs par défaut. La sélection se pilote via le flag --toolsets ou la variable d'environnement GITHUB_TOOLSETS ; des outils individuels peuvent être activés via GITHUB_TOOLS. Un flag --read-only désactive tous les outils d'écriture — utile lorsque l'agent doit seulement analyser, sans rien modifier.

Un agent peut ainsi trier des issues, créer et réviser des pull requests, inspecter des exécutions CI et rechercher du code à travers plusieurs dépôts — avec le support officiel de l'éditeur GitHub plutôt qu'une solution bricolée par la communauté.

🔧 SETUP

Méthode la plus simple (distant) : déclarer le serveur hébergé dans le client MCP comme serveur HTTP : `{"servers": {"github": {"type": "http", "url": "https://api.githubcopilot.com/mcp/"}}}` — connexion ensuite par OAuth dans le navigateur
Ou avec un Personal Access Token au lieu d'OAuth : configurer en plus l'en-tête `"Authorization": "Bearer <PAT>"`
En local plutôt qu'à distance : `docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN=<your-token> ghcr.io/github/github-mcp-server`
Restreindre les toolsets selon les besoins, par ex. `--toolsets repos,issues,pull_requests,actions` ou via la variable d'environnement `GITHUB_TOOLSETS="repos,issues,pull_requests"`
Pour des tâches purement analytiques, définir le flag `--read-only` — les outils d'écriture sont alors ignorés

✅ QUAND L’UTILISER ?

Travail sur les PR et issues directement depuis l'agent

« Résume les issues ouvertes avec le label ‘bug', priorise-les et crée pour la plus critique une branche avec une PR en brouillon » — le tout via les outils GitHub officiels, sans changer de navigateur.

Diagnostiquer des erreurs CI/CD

Avec le toolset `actions`, récupérer l'exécution de workflow échouée du dernier push, analyser les logs et se faire proposer directement un correctif.

⛔ QUAND ÉVITER ?

Opérations Git locales dans le répertoire de travail

Le serveur parle l'API GitHub — il ne voit pas les commits, branches et diffs de l'état de travail local pas encore poussé (push).

Mieux: Effectuer le travail Git local via la CLI Git habituelle de l'agent ; n'utiliser le GitHub MCP Server que pour le volet plateforme (PR, issues, Actions).

L'agent ne doit que lire, mais reçoit un accès en écriture complet

Avec les toolsets par défaut et un PAT aux droits étendus, l'agent peut modifier issues, PR et bien plus — des droits plus larges que nécessaire représentent un risque inutile.

Mieux: Définir `--read-only`, choisir des toolsets minimaux et utiliser un PAT finement scopé avec le moins de scopes possible.