Comment étendre l'agent de codage GitHub Copilot avec des outils MCP

Étendre l’agent de codage GitHub Copilot avec des outils MCP ne signifie pas greffer des intégrations aléatoires sur un modèle en espérant qu’il devienne plus intelligent. Cela signifie donner à l’agent un ensemble contrôlé d’outils externes qu’il peut appeler pendant qu’il travaille sur un dépôt afin qu’il puisse récupérer le bon contexte au bon moment, au lieu de vous forcer à coller des logs d’erreurs, des détails de tickets, des schémas d’API ou de la documentation dans chaque prompt.

C’est pourquoi MCP est mieux que des intégrations ponctuelles. Au lieu de construire de la colle personnalisée pour chaque IDE, surface de chat ou chemin d’automatisation, MCP vous donne un moyen standard d’exposer des outils à l’agent. La même approche globale peut se transposer à travers les surfaces Copilot, les agents personnalisés et l’outillage interne. Si vous avez déjà travaillé sur Comment configurer des agents de codage MCP dans GitHub Copilot et Xcode, ce tutoriel est la couche suivante : donner à l’agent de meilleurs outils, puis prouver que ces outils le rendent plus utile.

Dans ce guide, vous allez étendre l’agent de codage GitHub Copilot avec une vraie intégration MCP, vérifier que l’outil démarre correctement, tester l’invocation avec des prompts ciblés, et transformer cela en workflows pratiques comme des corrections de bugs, la rédaction de PR et la génération de tests. L’exemple détaillé utilise un pattern de recherche de tickets de type Sentry parce qu’il est réaliste, à haut signal et facile à valider, mais la même structure fonctionne pour la recherche de documentation, la récupération de schéma d’API ou l’outillage de build/test.

Étape 1 : Comprendre le modèle MCP

Avant de configurer quoi que ce soit, vous avez besoin du bon modèle mental. Dans MCP, les serveurs peuvent exposer trois types de capacités : tools (outils), resources (ressources) et prompts. Cela semble simple, mais la distinction compte beaucoup quand vous ciblez l’agent de codage GitHub Copilot.

Outils, ressources et prompts

À un haut niveau :

• Les Tools effectuent des actions ou récupèrent des résultats structurés pour le modèle.
• Les Resources exposent des données pour le contexte, généralement identifiées comme des fichiers ou URI.
• Les Prompts fournissent des templates de prompt ou workflows réutilisables.

Pour l’agent de codage Copilot, le détail critique est celui-ci : il fonctionne avec les tools des serveurs MCP. Si votre serveur n’expose qu’une page de documentation comme ressource ou n’expose qu’un workflow réutilisable comme prompt, l’agent de codage ne l’utilisera pas directement. Pour cette surface, vous devez exposer la partie précieuse comme un outil.

Cela signifie que ceci est un mauvais choix pour l’agent de codage Copilot :

{
  "resourcesOnly": [
    "openapi://billing/v1",
    "docs://runbooks/payments"
  ]
}

Et ceci est conceptuellement bien mieux adapté :

{
  "toolExamples": [
    "get_operation_schema",
    "lookup_runbook_section",
    "get_issue_summary",
    "get_build_failure_details"
  ]
}

La leçon est pratique : si vous voulez que l’agent de codage Copilot utilise un schéma d’API ou de la documentation, encapsulez cette récupération derrière un outil comme get_operation_schema ou lookup_docs_page.

Comment les agents décident quoi appeler

Les outils MCP sont contrôlés par le modèle. Le modèle décide si un outil est pertinent en se basant sur votre prompt, le nom de l’outil, sa description et son schéma d’entrée. Cela signifie que le nommage et le périmètre comptent plus que les gens ne le pensent.

De mauvais noms d’outils rendent l’agent moins fiable :

{
  "tools": ["run", "fetch", "data", "misc"]
}

De meilleurs noms d’outils rendent l’intention évidente :

{
  "tools": [
    "get_issue_details",
    "get_issue_summary",
    "lookup_docs_page",
    "get_operation_schema"
  ]
}

Pourquoi c’est important pour l’agent de codage GitHub Copilot

L’agent de codage Copilot travaille de manière autonome une fois qu’une tâche démarre. Si vous configurez un serveur MCP, l’agent peut utiliser ses outils sans vous demander une approbation par appel. C’est puissant, mais cela signifie aussi qu’une surface d’outils bâclée crée un vrai risque. La configuration la plus sûre est étroite, descriptive et en lecture seule.

Vous devriez maintenant connaître la règle de conception la plus importante pour ce tutoriel : si vous voulez que l’agent de codage bénéficie de contexte externe, exposez-le comme un outil avec un nom clair et un objectif étroit.

Étape 2 : Choisir une première intégration MCP

Votre première intégration devrait rendre l’agent notablement meilleur sur une vraie tâche, tout en restant facile à valider. La mauvaise première intégration est quelque chose de large, bruyant ou destructeur. La bonne première intégration est quelque chose qui donne à l’agent un contexte à haut signal que vous pouvez immédiatement voir dans une pull request.

Bonnes premières options d’intégration

Quelques bons points de départ sont :

• Recherche de documentation pour la documentation de framework ou produit
• Contexte du tracker de tickets pour le tri de bugs et les critères d’acceptation
• Schéma d’API interne pour générer des tests ou des mises à jour de client
• Outillage de build ou test quand les échecs sont répétitifs et structurés

Une intégration de recherche de documentation est excellente si votre équipe colle constamment les mêmes extraits de documentation ou de runbook dans les prompts. Une intégration de tracker de tickets est idéale si les corrections de bugs partent de tickets, traces de pile ou ID d’exceptions. Un outil de spec API est excellent quand vous voulez une meilleure génération de tests orientée endpoint.

Choisir quelque chose d’étroit et en lecture seule d’abord

Pour ce tutoriel, utilisez un pattern de recherche de ticket similaire à Sentry ou un autre tracker de tickets. C’est un bon premier exemple parce qu’il donne à l’agent un contexte de bug externe ciblé sans accorder d’accès en écriture.

Les critères clés pour une première intégration MCP sont :

• Elle répond à une question à laquelle l’agent ne peut pas répondre de manière fiable à partir du dépôt seul.
• Ses résultats sont faciles à vérifier pour vous.
• Elle n’a pas besoin de permissions d’écriture.
• Elle améliore un workflow courant, pas seulement une démo.

Exemples de bons premiers choix

Une recherche de ticket en lecture seule :

{
  "candidateIntegration": {
    "name": "issue-context",
    "goal": "Let Copilot retrieve stack traces, issue summaries, and affected services for a bugfix task"
  }
}

Une intégration de recherche de documentation :

{
  "candidateIntegration": {
    "name": "docs-lookup",
    "goal": "Let Copilot retrieve framework or product documentation relevant to the code it is editing"
  }
}

Une intégration de spec API :

{
  "candidateIntegration": {
    "name": "api-schema",
    "goal": "Let Copilot retrieve endpoint contracts, request shapes, and error models while writing tests"
  }
}

Vous devriez maintenant avoir une cible claire de première intégration. Pour le reste de ce tutoriel, la configuration concrète utilise un pattern de recherche de ticket en lecture seule parce que c’est pratique et sûr.

Étape 3 : Ajouter un serveur MCP externe

Cette étape suppose que vous avez déjà l’agent de codage Copilot activé et une configuration MCP de base en place. Sinon, complétez les étapes 2 à 4 de Comment configurer des agents de codage MCP d’abord — ce tutoriel couvre l’activation de l’agent de codage, les paramètres du dépôt, copilot-setup-steps.yml et les secrets COPILOT_MCP_ depuis zéro.

Ajouter une entrée de serveur externe

Ouvrez Settings > Copilot > Coding agent dans votre dépôt et ajoutez une nouvelle entrée de serveur à votre objet mcpServers existant.

Pour un serveur MCP local de type Sentry, la configuration ressemble à ceci. Vérifiez le nom du package et les outils disponibles par rapport à la documentation actuelle du fournisseur, car les packages de serveurs MCP évoluent rapidement :

{
  "mcpServers": {
    "sentry": {
      "type": "local",
      "command": "npx",
      "args": ["@sentry/mcp-server@latest", "--host=$SENTRY_HOST"],
      "tools": ["get_issue_details", "get_issue_summary"],
      "env": {
        "SENTRY_HOST": "COPILOT_MCP_SENTRY_HOST",
        "SENTRY_ACCESS_TOKEN": "COPILOT_MCP_SENTRY_ACCESS_TOKEN"
      }
    }
  }
}

C’est un bon premier exemple parce qu’il fait trois choses correctement :

• utilise un serveur local qui s’exécute dans l’environnement de Copilot
• expose une petite liste blanche d’outils au lieu de *
• passe les valeurs via la configuration d’environnement au lieu de coder les secrets en dur

Périmètre des permissions et secrets correctement

Si votre serveur MCP nécessite des variables ou secrets, créez un environnement de dépôt nommé copilot, puis ajoutez uniquement les valeurs nécessaires. Les noms doivent commencer par COPILOT_MCP_.

Pour l’exemple ci-dessus, ajoutez :

• COPILOT_MCP_SENTRY_HOST
• COPILOT_MCP_SENTRY_ACCESS_TOKEN

Si vous intégrez un serveur MCP interne basé sur HTTP ou SSE à la place, vous pourriez utiliser des headers au lieu d’env :

{
  "mcpServers": {
    "internal-api-spec": {
      "type": "http",
      "url": "https://mcp.example.com/openapi",
      "tools": ["list_operations", "get_operation_schema", "get_error_examples"],
      "headers": {
        "Authorization": "$COPILOT_MCP_INTERNAL_API_TOKEN"
      }
    }
  }
}

Ajouter des étapes de setup si le serveur a besoin de dépendances

Si votre serveur MCP externe a besoin de dépendances runtime non présentes par défaut, mettez à jour votre workflow copilot-setup-steps.yml existant avec les étapes de setup additionnelles. Consultez Comment configurer des agents de codage MCP, Étape 4 pour le template complet de workflow si vous n’en avez pas encore.

Vérifier la connectivité

Après avoir sauvegardé la configuration MCP, créez un ticket de test dans le dépôt et assignez-le à Copilot. Une fois la session démarrée :

1. Ouvrez la timeline du ticket.
2. Ouvrez la pull request générée ou le lien de session.
3. Consultez les logs de session.
4. Développez Start MCP Servers.

Si la configuration est valide et que le serveur démarre, vous devriez voir le serveur MCP et ses outils listés là.

Vous devriez maintenant avoir l’agent de codage Copilot configuré avec au moins un serveur MCP et un endroit déterministe pour débugger le démarrage si quelque chose ne va pas.

Étape 4 : Tester l’invocation d’outils

À ce stade, le serveur peut tourner, mais cela ne garantit pas que l’agent l’utilise correctement. Votre prochain travail est de tester si l’outil est réellement sélectionné pour les tâches pertinentes et si le contexte retourné façonne le travail de code.

Demander à l’agent de récupérer uniquement du contexte

Commencez avec un prompt qui nécessite l’outil externe mais ne nécessite pas encore de changements de code.

Use the issue-context tool to summarize the linked exception or issue. Tell me the likely root cause, affected file or subsystem, and the smallest safe fix. Do not make code changes yet.

C’est une bonne première vérification parce qu’elle isole la récupération de l’édition. Si la réponse inclut des détails qui n’existent que dans le tracker de tickets, l’outil est probablement invoqué.

Demander à l’agent de combiner dépôt + contexte externe

Ensuite, donnez-lui une tâche qui a clairement besoin à la fois du contexte du dépôt et du contexte externe :

Use the issue-context tool to retrieve the latest details for the linked error, then inspect this repository and propose the smallest code change that would fix it. Include the exact files you would edit and the regression tests you would add.

Cela devrait produire une meilleure réponse que le prompting uniquement sur le dépôt parce que l’agent peut combiner la trace de pile ou les détails du ticket avec la vraie structure du code.

Confirmer qu’il utilise l’outil prévu

Il y a trois signaux fiables :

1. Les logs de démarrage montrent que l’outil a été chargé.
2. La réponse contient des détails que seul l’outil aurait pu fournir.
3. Le diff résultant s’aligne avec ce contexte externe.

Ce que vous essayez d’éviter c’est « il a répondu avec assurance, mais n’a jamais vraiment utilisé l’outil ».

Un prompt de validation pratique est :

Before writing code, tell me which external details influenced your plan and which repository files they map to.

Si la réponse référence les bonnes métadonnées du ticket et les mappe aux bons fichiers, le workflow fonctionne.

Vous devriez maintenant pouvoir faire la différence entre « MCP est configuré » et « MCP aide vraiment ».

Étape 5 : Construire un workflow pratique

Avec la configuration prouvée, vous pouvez la transformer en workflows reproductibles qui font gagner du temps au lieu d’ajouter de la complexité.

Exemple 1 : Correction de bug utilisant dépôt + contexte de ticket

C’est le workflow de plus haute valeur en premier pour beaucoup d’équipes.

Utilisez un prompt comme :

Use the issue-context tool to retrieve the latest bug details for ISSUE-1427. Then inspect this repository and fix the bug with the smallest safe change. Add a regression test, explain the root cause, and keep the diff narrowly scoped.

Cela fonctionne bien parce que l’outil externe répond « Que s’est-il passé en production ? » tandis que le dépôt répond « Où la correction devrait-elle vivre ? »

Exemple 2 : Génération de PR utilisant dépôt + tracker de tickets

Si votre tracker de tickets contient des critères d’acceptation, cela peut affiner le premier brouillon de pull request.

Retrieve the linked ticket details and acceptance criteria using the issue-context tool. Then prepare the code changes for the requested fix and draft a pull request summary that references the issue, the root cause, and the test coverage added.

Le bénéfice ici n’est pas l’écriture magique. C’est la cohérence. L’agent peut aligner le changement de code avec le vrai ticket au lieu de deviner à partir d’un prompt d’une ligne.

Exemple 3 : Génération de tests utilisant code + spec API

C’est là que beaucoup d’équipes découvrent la vraie valeur de MCP. Si vous exposez votre OpenAPI ou schéma interne via des outils, Copilot peut générer des tests contre le vrai contrat au lieu de deviner les formes de requête.

Une configuration MCP au niveau du dépôt pour un serveur de spec API interne pourrait ressembler à ceci :

{
  "mcpServers": {
    "apiSpec": {
      "type": "sse",
      "url": "https://mcp.example.com/spec",
      "tools": ["list_operations", "get_operation_schema", "get_error_examples"]
    }
  }
}

Puis promptez Copilot comme ceci :

Use the apiSpec tools to retrieve the request and response schema for POST /v1/customers, then generate or update tests in this repository so they reflect the current contract. Do not change production code unless the tests prove a real mismatch.

C’est un bien meilleur workflow que de coller de gros blobs de schéma dans le chat.

Un simple template de ticket pour tester le workflow

Fichier : .github/ISSUE_TEMPLATE/mcp-bugfix.md

---
name: MCP bugfix task
about: Test Copilot coding agent with external MCP context
title: "[MCP] "
labels: bug
assignees: ""
---

## External context
- Issue ID:
- Link:
- Severity:
- Environment:

## Expected outcome
- Minimal code change
- Regression test added
- PR summary includes root cause

Cela rend les tests précoces plus cohérents et plus faciles à comparer entre les exécutions.

Vous devriez maintenant avoir au moins un workflow pratique où MCP change la qualité du résultat, pas seulement la quantité de contexte disponible.

Étape 6 : Gouverner votre surface d’outils

MCP peut absolument rendre l’agent de codage meilleur, mais seulement si vous gardez la surface d’outils propre. Pour les garde-fous généraux autour de la protection de branche, des revues requises et du maintien des humains dans la boucle, consultez Comment configurer des agents de codage MCP, Étape 7. Cette étape se concentre sur ce qui est unique à la gestion de plusieurs outils externes.

Appliquer des listes blanches explicites par serveur

Quand vous avez plusieurs serveurs MCP, chacun ne devrait exposer que les outils dont ce workflow a réellement besoin. N’utilisez pas * sur un serveur avec une large surface :

{
  "tools": ["get_issue_details", "get_issue_summary"]
}

Supprimez les outils destructeurs (delete, deploy, mutate) de la configuration entièrement plutôt que de compter sur le prompt pour empêcher un comportement dangereux.

Utiliser des agents personnalisés spécialisés pour les outils externes

Quand différents workflows ont besoin de contexte externe différent, créez des agents personnalisés séparés avec un accès aux outils étroitement périmétré plutôt qu’un seul agent avec accès à tout.

Fichier : .github/agents/bugfix-with-issue-context.agent.md

---
name: bugfix-with-issue-context
description: Specialized agent for narrow bug fixes using repository context and issue details
tools: ["github/*", "sentry/get_issue_details", "sentry/get_issue_summary"]
---

You are a maintenance-focused coding agent.

Rules:
- Prefer the smallest safe change.
- Use issue context only to clarify the bug and expected behavior.
- Add or update regression tests when behavior changes.
- Do not add dependencies.
- Do not edit unrelated files.
- Do not change CI, deployment, or project configuration unless explicitly instructed.
- Summarize which external facts influenced the fix.

Cela ne remplace pas la revue, mais cela réduit la dispersion inutile.

Garder le contexte externe à haut signal

L’une des erreurs les plus faciles est d’exposer beaucoup d’outils de faible valeur juste parce que vous le pouvez. Cela rend généralement l’agent plus lent et moins concentré. Les bonnes intégrations MCP fournissent du contexte ciblé et de confiance. Les mauvaises noient l’agent dans du bruit non structuré.

Vous devriez maintenant avoir un modèle opérationnel plus sûr : outils étroits, merges protégés et un endroit clair pour l’approbation humaine.

Étape 7 : Mesurer si MCP aide réellement

Si vous ne mesurez pas la différence, il est facile de confondre « plus de pièces mobiles » avec « meilleur workflow ». Le but de MCP n’est pas la nouveauté. C’est de meilleurs résultats avec moins de chargement manuel de contexte.

Choisir une petite base de référence

Prenez 5 à 10 tâches similaires et comparez :

• Agent de codage Copilot sans MCP
• Agent de codage Copilot avec MCP activé

De bonnes tâches incluent :

• petites corrections de bugs
• ajouts de tests
• mises à jour de documentation liées à des tickets existants
• génération de tests liée aux endpoints

Suivre les bonnes métriques

Les métriques précoces les plus utiles sont :

• moins de références hallucinées à des docs ou API inexistantes
• premier brouillon de pull request plus rapide
• résumés de PR plus précis
• moins de copier/coller manuel de logs, schémas ou détails de tickets
• moins d’éditions du « mauvais fichier » au premier passage

Un fichier d’évaluation léger garde cela ancré.

Fichier : docs/mcp-evaluation.md

# MCP Evaluation

## Task Log

| Date | Task | MCP Enabled | External Tool Used | First Diff Usable | Manual Context Pasted | Notes |
|------|------|-------------|--------------------|-------------------|-----------------------|-------|
| 2026-03-09 | Bugfix ISSUE-1427 | Yes | sentry/get_issue_details | Yes | No | Correct root cause on first pass |
| 2026-03-09 | API tests for POST /v1/customers | No | N/A | Partial | Yes | Needed manual schema paste |

## Questions to answer
- Did MCP reduce hallucinations?
- Did MCP reduce prompt length?
- Did the first diff require fewer corrections?
- Did the agent use the intended tool?
- Was the added setup complexity worth it?

Décider s’il faut garder, affiner ou supprimer une intégration

Après une ou deux semaines, chaque intégration MCP devrait tomber dans l’un des trois paniers :

• Garder parce qu’elle améliore régulièrement la qualité des tâches
• Affiner parce que le nommage ou le périmètre de l’outil est trop large
• Supprimer parce qu’elle ajoute du bruit sans améliorer les résultats

Cette dernière option compte. Certaines intégrations semblent puissantes mais n’aident pas assez pour justifier la complexité.

Vous devriez maintenant avoir un moyen de juger MCP par les preuves plutôt que par l’enthousiasme.

Problèmes courants de configuration

Donner trop d’accès

Symptômes

• L’agent touche des systèmes non liés ou essaie d’en faire trop.
• L’utilisation des outils semble imprévisible.
• La revue de sécurité devient inconfortable rapidement.

Cause racine

Vous avez exposé trop d’outils ou utilisé * sur un serveur avec une large surface.

Correction

Passez à une liste blanche explicite :

{
  "tools": ["get_issue_details", "get_issue_summary"]
}

Puis n’étendez que quand le plus petit ensemble est régulièrement utile.

Exposer du contexte bruyant

Symptômes

• L’agent apporte des faits externes non pertinents.
• Les prompts deviennent plus longs, pas plus courts.
• Les pull requests deviennent larges ou confuses.

Cause racine

L’intégration fournit trop d’informations de faible signal, ou les descriptions des outils sont vagues.

Correction

Exposez moins d’outils, renommez-les plus clairement, et préférez les outils qui répondent à des questions ciblées.

Outils mal nommés ou descriptions surchargées

Symptômes

• L’agent appelle le mauvais outil.
• Il évite l’outil même quand il devrait l’utiliser.
• Les résultats sont incohérents entre des tâches similaires.

Cause racine

Des noms d’outils comme fetch, run ou query ne communiquent pas assez bien l’intention.

Correction

Renommez-les ou remplacez-les par des noms riches en intention comme :

• get_issue_details
• lookup_docs_page
• get_operation_schema
• get_build_failure_details

Le serveur démarre mais l’outil semble quand même inutilisé

Symptômes

• Les logs montrent que le serveur a démarré.
• La sortie ressemble quand même à une réponse générique.
• Les détails externes n’apparaissent pas dans le raisonnement ou le diff.

Cause racine

Le prompt de la tâche n’a pas rendu l’outil externe suffisamment pertinent, ou les noms d’outils sont trop vagues.

Correction

Commencez par des prompts explicites de récupération d’abord :

Use the issue-context tool to summarize the external bug details first. Then map those details to the exact files you would change in this repository.

Cela rend l’utilisation de l’outil plus facile à valider.

Conclusion

Vous avez maintenant étendu l’agent de codage GitHub Copilot avec des outils MCP d’une manière qui est pratique, vérifiable et sûre. Vous avez appris le modèle MCP, choisi une première intégration à haut signal, l’avez configurée au niveau du dépôt, vérifié le démarrage de l’outil, testé l’invocation et construit des workflows qui combinent le contexte du dépôt avec des systèmes externes.

Les meilleures prochaines intégrations à ajouter sont généralement la recherche de documentation publique ou interne, les trackers de tickets, la récupération de spec API et le contexte ciblé de build/test. Créez un serveur MCP interne personnalisé quand votre équipe continue de coller le même contexte structuré dans les prompts ou quand les connaissances les plus précieuses vivent dans des systèmes internes que le dépôt ne peut pas représenter proprement par lui-même.

La raison de le faire maintenant est que GitHub a rendu le modèle MCP de l’agent de codage Copilot suffisamment concret pour être implémenté, validé et amélioré. Cela fait passer MCP d’un concept intéressant à quelque chose que vous pouvez réellement opérationnaliser dans un workflow de développement.