GitHub Copilot Coding Agent mit MCP-Tools erweitern

Den GitHub Copilot Coding Agent mit MCP-Tools zu erweitern bedeutet nicht, beliebige Integrationen an ein Modell zu schrauben und zu hoffen, dass es schlauer wird. Es bedeutet, dem Agenten einen kontrollierten Satz externer Tools zur Verfuegung zu stellen, die er waehrend der Arbeit an einem Repository aufrufen kann, damit er den richtigen Kontext im richtigen Moment abrufen kann, anstatt Sie zu zwingen, Fehlerprotokolle, Issue-Details, API-Schemas oder Dokumentation in jeden Prompt einzufuegen.

Deshalb ist MCP besser als Einzel-Integrationen. Statt fuer jede IDE, Chat-Oberflaeche oder jeden Automatisierungspfad individuellen Kleber zu bauen, gibt Ihnen MCP eine standardisierte Moeglichkeit, dem Agenten Tools zur Verfuegung zu stellen. Derselbe Gesamtansatz kann ueber Copilot-Oberflaechen, benutzerdefinierte Agenten und internes Tooling hinweg angewendet werden. Wenn Sie bereits MCP-gesteuerte Coding-Agenten in GitHub Copilot und Xcode einrichten durchgearbeitet haben, ist dieses Tutorial die naechste Schicht: Geben Sie dem Agenten bessere Tools und beweisen Sie dann, dass diese Tools ihn nuetzlicher machen.

In dieser Anleitung werden Sie den GitHub Copilot Coding Agent mit einer echten MCP-Integration erweitern, verifizieren, dass das Tool korrekt startet, die Aufrufe mit engen Prompts testen und das in praktische Workflows wie Bug-Fixes, PR-Erstellung und Testgenerierung umwandeln. Das detaillierte Beispiel verwendet ein Sentry-artiges Issue-Lookup-Muster, weil es realistisch, signalstark und leicht zu validieren ist, aber dieselbe Struktur funktioniert fuer Docs-Lookup, API-Schema-Abruf oder Build/Test-Tooling.

Schritt 1: Das MCP-Modell verstehen

Bevor Sie etwas konfigurieren, brauchen Sie das richtige mentale Modell. In MCP koennen Server drei Arten von Faehigkeiten exponieren: Tools, Resources und Prompts. Das klingt einfach, aber die Unterscheidung ist sehr wichtig, wenn Sie den GitHub Copilot Coding Agent ansteuern.

Tools, Resources und Prompts

Auf hoher Ebene:

• Tools fuehren Aktionen aus oder holen strukturierte Ergebnisse fuer das Modell.
• Resources exponieren Daten fuer Kontext, normalerweise wie Dateien oder URIs identifiziert.
• Prompts stellen wiederverwendbare Prompt-Templates oder Workflows bereit.

Fuer den Copilot Coding Agent ist das kritische Detail: Er arbeitet mit Tools von MCP-Servern. Wenn Ihr Server nur eine Docs-Seite als Resource exponiert oder nur einen wiederverwendbaren Workflow als Prompt, wird der Coding Agent das nicht direkt nutzen. Fuer diese Oberflaeche muessen Sie den wertvollen Teil als Tool exponieren.

Das bedeutet, dies ist schlecht geeignet fuer den Copilot Coding Agent:

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

Und dies ist konzeptionell viel besser geeignet:

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

Die Lektion ist praktisch: Wenn Sie moechten, dass der Copilot Coding Agent API-Schema oder Dokumentation verwendet, verpacken Sie diesen Abruf hinter einem Tool wie get_operation_schema oder lookup_docs_page.

Wie Agenten entscheiden, was aufgerufen wird

MCP-Tools sind modellgesteuert. Das Modell entscheidet, ob ein Tool relevant ist, basierend auf Ihrem Prompt, dem Namen des Tools, seiner Beschreibung und seinem Eingabeschema. Das bedeutet, dass Benennung und Umfang mehr ausmachen, als die meisten erwarten.

Schlechte Tool-Namen machen den Agenten weniger zuverlaessig:

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

Bessere Tool-Namen machen die Absicht offensichtlich:

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

Warum das fuer den GitHub Copilot Coding Agent wichtig ist

Der Copilot Coding Agent arbeitet autonom, sobald ein Task beginnt. Wenn Sie einen MCP-Server konfigurieren, kann der Agent dessen Tools verwenden, ohne Sie um Per-Call-Genehmigung zu bitten. Das ist maechtig, aber es bedeutet auch, dass eine schlampige Tool-Oberflaeche echtes Risiko erzeugt. Die sicherste Konfiguration ist eng, beschreibend und schreibgeschuetzt.

Sie sollten nun die wichtigste Designregel fuer dieses Tutorial kennen: Wenn Sie moechten, dass der Coding Agent von externem Kontext profitiert, exponieren Sie ihn als Tool mit einem klaren Namen und einem engen Zweck.

Schritt 2: Eine erste MCP-Integration waehlen

Ihre erste Integration sollte den Agenten bei einer echten Aufgabe merklich besser machen und dabei einfach zu validieren bleiben. Die falsche erste Integration ist etwas Breites, Verrauschtes oder Destruktives. Die richtige erste Integration ist etwas, das dem Agenten signalstarken Kontext gibt, den Sie sofort in einem Pull Request sehen koennen.

Gute erste Integrationsoptionen

Einige starke Startpunkte sind:

• Docs-Lookup fuer Framework- oder Produktdokumentation
• Issue-Tracker-Kontext fuer Bug-Triage und Akzeptanzkriterien
• Internes API-Schema fuer Testgenerierung oder Client-Updates
• Build- oder Test-Tooling, wenn Fehler repetitiv und strukturiert sind

Eine Docs-Lookup-Integration ist grossartig, wenn Ihr Team staendig dieselbe Dokumentation oder Runbook-Ausschnitte in Prompts einfuegt. Eine Issue-Tracker-Integration ist ideal, wenn Bug-Fixes von Tickets, Stack-Traces oder Exception-IDs ausgehen. Ein API-Spec-Tool ist hervorragend, wenn Sie bessere endpunktbewusste Testgenerierung wollen.

Waehlen Sie zuerst etwas Enges und Schreibgeschuetztes

Fuer dieses Tutorial verwenden Sie ein Issue-Lookup-Muster aehnlich wie Sentry oder einen anderen Issue-Tracker. Es ist ein starkes erstes Beispiel, weil es dem Agenten gezielten, externen Bug-Kontext gibt, ohne Schreibzugriff zu gewaehren.

Die Schluesselkriterien fuer eine erste MCP-Integration sind:

• Sie beantwortet eine Frage, die der Agent allein aus dem Repo nicht zuverlaessig beantworten kann.
• Ihre Ergebnisse sind fuer Sie leicht zu verifizieren.
• Sie braucht keine Schreibberechtigungen.
• Sie verbessert einen haeufigen Workflow, nicht nur eine Demo.

Beispiele fuer gute erste Wahlen

Ein schreibgeschuetzter Issue-Lookup:

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

Eine Docs-Lookup-Integration:

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

Eine API-Spec-Integration:

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

Sie sollten nun ein klares erstes Integrationsziel haben. Fuer den Rest dieses Tutorials verwendet das konkrete Setup ein schreibgeschuetztes Issue-Lookup-Muster, weil es praktisch und sicher ist.

Schritt 3: Einen externen MCP-Server hinzufuegen

Dieser Schritt setzt voraus, dass Sie den Copilot Coding Agent bereits aktiviert haben und eine grundlegende MCP-Konfiguration vorhanden ist. Falls nicht, absolvieren Sie zuerst die Schritte 2-4 in MCP-gesteuerte Coding-Agenten einrichten — dieses Tutorial behandelt das Aktivieren des Coding Agent, Repository-Einstellungen, copilot-setup-steps.yml und COPILOT_MCP_-Secrets von Grund auf.

Einen externen Servereintrag hinzufuegen

Oeffnen Sie Settings > Copilot > Coding agent in Ihrem Repository und fuegen Sie einen neuen Servereintrag zu Ihrem bestehenden mcpServers-Objekt hinzu.

Fuer einen Sentry-artigen lokalen MCP-Server sieht die Konfiguration so aus. Verifizieren Sie den Paketnamen und die verfuegbaren Tools gegen die aktuelle Dokumentation des Anbieters, da sich MCP-Server-Pakete schnell weiterentwickeln:

{
  "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"
      }
    }
  }
}

Dies ist ein gutes erstes Beispiel, weil es drei Dinge richtig macht:

• verwendet einen lokalen Server, der in Copilots Umgebung laeuft
• exponiert eine kleine Allowlist von Tools statt *
• uebergibt Werte ueber Umgebungskonfiguration statt Geheimnisse hartzucodieren

Berechtigungen und Secrets korrekt scopen

Wenn Ihr MCP-Server Variablen oder Secrets benoetigt, erstellen Sie ein Repository-Environment namens copilot und fuegen Sie nur die benoetigten Werte hinzu. Die Namen muessen mit COPILOT_MCP_ beginnen.

Fuer das obige Beispiel fuegen Sie hinzu:

• COPILOT_MCP_SENTRY_HOST
• COPILOT_MCP_SENTRY_ACCESS_TOKEN

Wenn Sie stattdessen einen internen HTTP- oder SSE-basierten MCP-Server integrieren, koennten Sie Header statt Env verwenden:

{
  "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"
      }
    }
  }
}

Setup-Schritte hinzufuegen, wenn der Server Abhaengigkeiten benoetigt

Wenn Ihr externer MCP-Server Laufzeitabhaengigkeiten benoetigt, die standardmaessig nicht vorhanden sind, aktualisieren Sie Ihren bestehenden copilot-setup-steps.yml-Workflow mit den zusaetzlichen Setup-Schritten. Siehe MCP-gesteuerte Coding-Agenten einrichten, Schritt 4 fuer das vollstaendige Workflow-Template, falls Sie noch keins haben.

Konnektivitaet verifizieren

Nach dem Speichern der MCP-Konfiguration erstellen Sie ein Test-Issue im Repository und weisen es Copilot zu. Sobald die Session startet:

1. Oeffnen Sie die Issue-Timeline.
2. Oeffnen Sie den generierten Pull Request oder Session-Link.
3. Sehen Sie sich die Session-Logs an.
4. Erweitern Sie Start MCP Servers.

Wenn die Konfiguration gueltig ist und der Server startet, sollten Sie den MCP-Server und seine Tools dort aufgelistet sehen.

Sie sollten nun den Copilot Coding Agent mit mindestens einem MCP-Server konfiguriert haben und einen deterministischen Ort zum Debuggen des Starts, wenn etwas schief geht.

Schritt 4: Tool-Aufruf testen

An diesem Punkt laeuft der Server moeglicherweise, aber das garantiert nicht, dass der Agent ihn korrekt nutzt. Ihre naechste Aufgabe ist zu testen, ob das Tool tatsaechlich fuer relevante Tasks ausgewaehlt wird und ob der zurueckgegebene Kontext die Codearbeit formt.

Den Agenten bitten, nur Kontext abzurufen

Beginnen Sie mit einem Prompt, der das externe Tool erfordert, aber noch keine Codeaenderungen benoetigt.

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.

Dies ist eine gute erste Pruefung, weil sie den Abruf vom Bearbeiten isoliert. Wenn die Antwort Details enthaelt, die nur im Issue-Tracker existieren, wird das Tool wahrscheinlich aufgerufen.

Den Agenten bitten, Repo + externen Kontext zu kombinieren

Geben Sie ihm als Naechstes eine Aufgabe, die offensichtlich sowohl Repository-Kontext als auch externen Kontext benoetigt:

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.

Dies sollte eine staerkere Antwort erzeugen als reines Repo-Prompting, weil der Agent den Stack-Trace oder die Issue-Details mit der echten Codestruktur kombinieren kann.

Bestaetigen, dass das beabsichtigte Tool verwendet wird

Es gibt drei zuverlaessige Signale:

1. Start-Logs zeigen, dass das Tool geladen wurde.
2. Die Antwort enthaelt Details, die nur das Tool haette liefern koennen.
3. Der resultierende Diff stimmt mit diesem externen Kontext ueberein.

Was Sie vermeiden wollen, ist “es hat selbstbewusst geantwortet, aber das Tool nie wirklich benutzt.”

Ein praktischer Validierungsprompt ist:

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

Wenn die Antwort die richtigen Issue-Metadaten referenziert und sie auf die richtigen Dateien abbildet, funktioniert der Workflow.

Sie sollten nun den Unterschied zwischen “MCP ist konfiguriert” und “MCP hilft tatsaechlich” erkennen koennen.

Schritt 5: Einen praktischen Workflow aufbauen

Mit dem bewiesenen Setup koennen Sie es in wiederholbare Workflows umwandeln, die Zeit sparen, statt Komplexitaet hinzuzufuegen.

Beispiel 1: Bugfix mit Repo + Issue-Kontext

Dies ist der wertstaerkste erste Workflow fuer viele Teams.

Verwenden Sie einen Prompt wie:

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.

Dies funktioniert gut, weil das externe Tool beantwortet “Was ist in der Produktion passiert?”, waehrend das Repository beantwortet “Wo sollte der Fix leben?”

Beispiel 2: PR-Generierung mit Repo + Issue-Tracker

Wenn Ihr Issue-Tracker Akzeptanzkriterien enthaelt, kann das den ersten Pull-Request-Entwurf schaerfen.

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.

Der Vorteil hier ist nicht magisches Schreiben. Es ist Konsistenz. Der Agent kann die Codeaenderung mit dem tatsaechlichen Ticket abgleichen, statt aus einem einzeiligen Prompt zu raten.

Beispiel 3: Testgenerierung mit Code + API-Spec

Hier entdecken viele Teams den echten Wert von MCP. Wenn Sie Ihr OpenAPI- oder internes Schema ueber Tools exponieren, kann Copilot Tests gegen den tatsaechlichen Vertrag generieren, statt Anfrage-Formen zu raten.

Eine Repository-Level-MCP-Konfiguration fuer einen internen API-Spec-Server koennte so aussehen:

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

Dann prompten Sie Copilot so:

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.

Das ist ein viel besserer Workflow als grosse Schema-Blobs in den Chat einzufuegen.

Ein einfaches Issue-Template zum Testen des Workflows

File: .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

Das macht fruehes Testen konsistenter und einfacher, Durchlaeufe zu vergleichen.

Sie sollten nun mindestens einen praktischen Workflow haben, bei dem MCP die Qualitaet des Ergebnisses veraendert, nicht nur die Menge des verfuegbaren Kontexts.

Schritt 6: Ihre Tool-Oberflaeche steuern

MCP kann den Coding Agent definitiv verbessern, aber nur wenn Sie die Tool-Oberflaeche sauber halten. Fuer allgemeine Leitplanken um Branch-Protection, erforderliche Reviews und Beibehaltung von Menschen in der Schleife, siehe MCP-gesteuerte Coding-Agenten einrichten, Schritt 7. Dieser Schritt konzentriert sich auf das, was einzigartig an der Verwaltung mehrerer externer Tools ist.

Explizite Allowlists pro Server erzwingen

Wenn Sie mehrere MCP-Server haben, sollte jeder nur die Tools exponieren, die der jeweilige Workflow tatsaechlich benoetigt. Verwenden Sie * nicht auf Servern mit breiter Oberflaeche:

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

Entfernen Sie destruktive Tools (delete, deploy, mutate) komplett aus der Konfiguration, anstatt sich auf den Prompt zu verlassen, um gefaehrliches Verhalten zu verhindern.

Spezialisierte benutzerdefinierte Agenten fuer externe Tools verwenden

Wenn verschiedene Workflows verschiedenen externen Kontext benoetigen, erstellen Sie separate benutzerdefinierte Agenten mit eng gescopttem Tool-Zugriff, statt einen Agenten mit Zugriff auf alles.

File: .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.

Das ersetzt nicht das Review, reduziert aber unnoetige Ausbreitung.

Externen Kontext signalstark halten

Einer der einfachsten Fehler ist, viele niedrigwertige Tools zu exponieren, nur weil man es kann. Das macht den Agenten normalerweise langsamer und weniger fokussiert. Gute MCP-Integrationen liefern gezielten, vertrauenswuerdigen Kontext. Schlechte ertranken den Agenten in unstrukturiertem Rauschen.

Sie sollten nun ein sichereres Betriebsmodell haben: enge Tools, geschuetzte Merges und einen klaren Platz fuer menschliche Genehmigung.

Schritt 7: Messen, ob MCP tatsaechlich hilft

Wenn Sie den Unterschied nicht messen, ist es leicht, “mehr bewegliche Teile” mit “besserem Workflow” zu verwechseln. Der Sinn von MCP ist nicht Neuheit. Es sind bessere Ergebnisse mit weniger manuellem Kontext-Laden.

Eine kleine Basislinie waehlen

Nehmen Sie 5 bis 10 aehnliche Tasks und vergleichen Sie:

• Copilot Coding Agent ohne MCP
• Copilot Coding Agent mit aktiviertem MCP

Gute Tasks umfassen:

• kleine Bug-Fixes
• Test-Ergaenzungen
• Docs-Updates gebunden an bestehende Issues
• Endpunktbezogene Testgenerierung

Die richtigen Metriken verfolgen

Die nuetzlichsten fruehen Metriken sind:

• weniger halluzinierte Referenzen auf nicht-existierende Docs oder APIs
• schnellerer erster Pull-Request-Entwurf
• genauere PR-Zusammenfassungen
• weniger manuelles Copy/Paste von Logs, Schemas oder Ticket-Details
• weniger “falsche Datei”-Edits beim ersten Durchgang

Eine leichte Evaluierungsdatei haelt das geerdet.

File: 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?

Entscheiden, ob eine Integration behalten, verfeinert oder entfernt wird

Nach ein oder zwei Wochen sollte jede MCP-Integration in einen von drei Bereichen fallen:

• Behalten, weil sie konsequent die Task-Qualitaet verbessert
• Verfeinern, weil die Tool-Benennung oder der Umfang zu breit ist
• Entfernen, weil sie Rauschen hinzufuegt, ohne Ergebnisse zu verbessern

Die letzte Option ist wichtig. Einige Integrationen klingen maechtig, helfen aber nicht genug, um die Komplexitaet zu rechtfertigen.

Sie sollten nun eine Moeglichkeit haben, MCP anhand von Belegen statt Begeisterung zu beurteilen.

Haeufige Einrichtungsprobleme

Zu viel Zugriff gewaehren

Symptome

• Der Agent beruehrt unzusammenhaengende Systeme oder versucht zu viel.
• Tool-Nutzung fuehlt sich unvorhersehbar an.
• Security-Review wird schnell unbehaglich.

Ursache

Sie haben zu viele Tools exponiert oder * auf einem Server mit breiter Oberflaeche verwendet.

Loesung

Wechseln Sie zu einer expliziten Allowlist:

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

Erweitern Sie dann nur, wenn das kleinere Set konsequent nuetzlich ist.

Verrauschten Kontext exponieren

Symptome

• Der Agent bringt irrelevante externe Fakten ein.
• Prompts werden laenger, nicht kuerzer.
• Pull Requests werden breit oder verwirrt.

Ursache

Die Integration liefert zu viele signalschwache Informationen, oder die Tool-Beschreibungen sind vage.

Loesung

Exponieren Sie weniger Tools, benennen Sie sie klarer um und bevorzugen Sie Tools, die fokussierte Fragen beantworten.

Schlecht benannte Tools oder ueberladene Beschreibungen

Symptome

• Der Agent ruft das falsche Tool auf.
• Er vermeidet das Tool, selbst wenn er es nutzen sollte.
• Ergebnisse sind inkonsistent zwischen aehnlichen Tasks.

Ursache

Tool-Namen wie fetch, run oder query kommunizieren die Absicht nicht gut genug.

Loesung

Benennen Sie sie um oder ersetzen Sie sie durch absichtsreiche Namen wie:

• get_issue_details
• lookup_docs_page
• get_operation_schema
• get_build_failure_details

Server startet, aber das Tool fuehlt sich ungenutzt an

Symptome

• Die Logs zeigen, dass der Server gestartet ist.
• Die Ausgabe liest sich immer noch wie eine generische Antwort.
• Die externen Details erscheinen nicht im Reasoning oder Diff.

Ursache

Der Task-Prompt machte das externe Tool nicht relevant genug, oder die Tool-Namen sind zu vage.

Loesung

Beginnen Sie mit expliziten Retrieval-First-Prompts:

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.

Das macht die Tool-Nutzung einfacher zu validieren.

Zusammenfassung

Sie haben nun den GitHub Copilot Coding Agent mit MCP-Tools auf eine Weise erweitert, die praktisch, ueberpruefbar und sicher ist. Sie haben das MCP-Modell gelernt, eine erste signalstarke Integration gewaehlt, sie auf Repository-Ebene konfiguriert, den Tool-Start verifiziert, den Aufruf getestet und Workflows aufgebaut, die Repository-Kontext mit externen Systemen kombinieren.

Die besten naechsten Integrationen sind normalerweise oeffentliche oder interne Docs-Lookup, Issue-Tracker, API-Spec-Abruf und fokussierter Build/Test-Kontext. Erstellen Sie einen benutzerdefinierten internen MCP-Server, wenn Ihr Team staendig denselben strukturierten Kontext in Prompts einfuegt oder wenn das wertvollste Wissen in internen Systemen lebt, die das Repository allein nicht sauber darstellen kann.

Der Grund, dies jetzt zu tun, ist, dass GitHub das MCP-Modell des Copilot Coding Agent konkret genug gemacht hat, um es zu implementieren, zu validieren und zu verbessern. Das verschiebt MCP von einem interessanten Konzept zu etwas, das Sie tatsaechlich in einem Entwicklungsworkflow operationalisieren koennen.