Copilot Agent Mode – MCP-Integration und -Nutzung
Einer der wichtigsten Faktoren, der Code-Generierungs-Agenten überhaupt erst ermöglicht, ist der Einsatz von Tool-Aufrufen. Eine Code-Generierung, die keine weiteren Dateien lesen, den Compiler-Output interpretieren oder Test-Resultate auswerten kann, wäre schlichtweg unmöglich – beziehungsweise die Ergebnisse wären so schlecht, dass niemand sie verwenden würde. Erst der richtige Kontext, der dem LLM zur Verfügung gestellt wird, bringt den gewünschten Erfolg. Softwareentwicklung hängt nun mal von dynamischen Gegebenheiten ab, und dementsprechend benötigen wir Tool-Aufrufe.
Das Konzept dahinter gibt es schon länger. Über sogenanntes Function Calling wird dem LLM mitgeteilt, welche Aufrufe zur Verfügung stehen und wie die Struktur der Aufrufparameter sowie der Resultate aussieht. Daraufhin entscheidet das Large Language Model, welche Function-Calls auszuführen sind, und bindet die Ergebnisse in die weitere Verarbeitung ein.
Alle gängigen KI-Modelle, die derzeit zur Code-Generierung im Rahmen von GitHub Copilot eingesetzt werden, unterstützen Tool-Aufrufe von Haus aus. GitHub Copilot bringt bereits einige eingebaute Tools mit. Über das MCP-Protokoll lässt sich diese Funktionalität beliebig erweitern – bis hin zu firmenspezifischen MCP-Server-Implementierungen, die Domänenwissen bereitstellen oder Zugriff auf interne Dienste erlauben oder Infrastruktur verwalten.
Model Context Protocol (MCP)
Das Model Context Protocol (MCP) ist ein offener Standard, der definiert, wie Applikationen Kontext und Werkzeuge mit Large Language Models (LLMs) teilen. Anders gesagt: MCP ermöglicht es einem KI-Agenten wie zum Beispiel dem GitHub Copilot Agent Mode, sich auf eine standardisierte Weise mit externen Diensten zu verbinden.
Sind MCP-Server konfiguriert, können diese vom Agenten genutzt werden, ohne dass der eigentliche Workflow verlassen werden muss. Die Verwendung von MCP-Servern bringt mehrere Vorteile mit sich:
- Erweiterter Kontext und zusätzliche Werkzeuge: MCP-Server können Tools für unterschiedlichste Aufgaben bereitstellen – vom Lesen von Dateien über das Ausführen von Tests bis hin zum Abfragen von Datenbanken, dem Aufrufen von APIs oder dem Verwalten von Cloud-Ressourcen. All das lässt sich implementieren und zur Laufzeit einbinden.
- Autonome Workflows: Erst durch den Aufruf dieser Werkzeuge im Agent-Loop kann der Kontext dynamisch erweitert oder ein Ergebnis verifiziert werden.
- Einfache Integration: Durch das standardisierte Protokoll lassen sich MCP-Server leicht einbinden. Es ist kein zusätzlicher Code erforderlich; benötigt wird lediglich eine Konfiguration, in der festgelegt wird, welche MCP-Server zur Verfügung stehen. Anschließend ist der KI-Agent selbst in der Lage, die Werkzeuge und deren Funktionalität zu erkunden.
Bild 1 zeigt die grobe Funktionsweise der MCP-Server. Über eine Konfigurationsdatei (mcp.json) – respektive über die MCP-Konfiguration in den Repository-Einstellungen bei GitHub für Coding Agents – wird definiert, welche MCPs zur Verfügung stehen und ob eine Authentifizierung erforderlich ist.
Der Agent kann anschließend über das MCP-Protokoll die Fähigkeiten der einzelnen MCP-Server abfragen. Entsprechend wird der Prompt, der an das LLM gesendet wird, mit diesen Informationen erweitert. Entscheidet das LLM, dass ein bestimmter Tool-Call erforderlich ist, ruft es das entsprechende Werkzeug über JSON-RPC (zum Beispiel via HTTP oder stdio für lokale Server) auf und erhält eine strukturierte Antwort. Diese fließt in den Kontext zurück und steht für nachfolgende Tasks zur Verfügung.
MCP-Funktionsweise (Bild 1)
AutorMCP-Konfiguration in VS Code
Damit wir zusätzliche Tools im lokalen GitHub Copilot Agent Mode oder im serverseitigen Coding Agent nutzen können, müssen die entsprechenden MCP-Server zuerst konfiguriert werden.
Eine kuratierte Auflistung von MCP-Servern ist auf der GitHub-Seite von MCP verfügbar. Alternativ finden wir die Konfigurationseinstellungen direkt auf den Webseiten der jeweiligen Anbieter.
In unserem Beispiel möchten wir drei zusätzliche MCP-Server einbinden: Azure, Microsoft-Docs und Context7. Dazu legen wir im Repository die Datei .vscode/mcp.json an. Es handelt sich hierbei um eine Workspace-Konfiguration. Alternativ kann die Konfiguration auch im Benutzerprofil erfolgen – dann gilt sie global für alle Repositories.
Listing 1 zeigt die MCP-Konfiguration mit den drei hinzugefügten MCP-Servern. Wir sehen, dass sowohl der Typ http als auch stdio verwendet wird. Was ist der Unterschied?
- stdio bezeichnet die Kommunikation über Standard Input/Output mit einem lokalen MCP-Server. In unserem Beispiel wird dieser über ein npx-Kommando gestartet.
- http bezeichnet einen entfernten MCP-Server, der über einen URL angebunden wird.
- sse steht für Server-Sent Events und ist ein dritter, historischer Typ, der laut MCP-Spezifikation inzwischen als deprecated gilt. VS Code unterstützt ihn aber weiterhin, um die Rückwärtskompatibilität mit älteren Implementierungen zu gewährleisten. Funktionalitäten, die früher via SSE liefen (etwa Streaming), sind heute bereits in der Variante http integriert.
Unabhängig vom gewählten Transportkanal (stdio oder http) erfolgt die Kommunikation immer über JSON-RPC.
Listing 1: .vscode/mcp.json zur Registrierung der MCP-Server in VS Code
{
"servers": {
"microsoft-docs": {
"url": "https://learn.microsoft.com/api/mcp",
"type": "http"
},
"upstash/context7": {
"type": "http",
"url": "https://mcp.context7.com/mcp"
},
"azure": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@azure/mcp@latest",
"server",
"start"
]
}
},
"inputs": []
} Kritische Leserinnen oder Leser fragen sich an dieser Stelle vielleicht, wie das Ganze funktionieren soll – das Azure API ist schließlich ein authentifiziertes API, und in der Konfiguration haben wir keinerlei Authentisierungsinformationen angegeben. Richtig! Aufrufe an Azure müssen zwingend authentifiziert sein. In unserem Fall handelt es sich beim Azure-MCP um einen lokalen Server, der via stdio angesprochen wird. Dieser Prozess greift auf den Authentisierungskontext des Azure CLI zurück. Ist das Azure CLI im Benutzerkontext bereits authentifiziert, müssen wir nichts weiter tun. Anders verhält es sich bei Coding Agents, die in einer GitHub-Actions-Runner-Umgebung laufen – hier ist eine separate Authentisierung notwendig (mehr dazu weiter unten). Der Context7-MCP-Server ist ein Remote-Server, der optional eine Authentisierung per API-Key unterstützt. Mit authentifizierten Requests erhalten wir höhere Zugriffsraten. Aber natürlich gilt: Niemals einen API-Key im Klartext in die Repository-Datei einfügen!
Die VS-Code-MCP-Konfiguration erlaubt eine sichere Handhabung von Secrets. Wir übergeben den API-Key nicht direkt, sondern über eine Input-Variable, die aus einem sicheren Speicherort gelesen wird.
Dazu nutzen wir den Abschnitt "inputs". Das Token wird als HTTP-Header in der MCP-Server-Konfiguration übergeben. VS Code unterstützt dabei Input-Variablen vom Typ promptString. Diese werden beim ersten Aufruf vom Benutzer abgefragt und über die Betriebssystemfunktionen sicher gespeichert.
Mit ${input:<variablename>} referenzieren wir die Input-Variable. "password: true" sorgt dafür, dass die Eingabe verdeckt erfolgt und sicher gespeichert wird.
Listing 2 zeigt die erweiterte MCP-Konfiguration mit einem Passwort-Prompt für den API-Key von Context7, Bild 2 demonstriert die Eingabe der sensiblen Variablen direkt in VS Code bei der Bearbeitung der Datei mcp.json.
Listing 2: .vscode/mcp.json mit API Key Input
{
"servers": {
"microsoft-docs": {
"url": "https://learn.microsoft.com/api/mcp",
"type": "http"
},
"upstash/context7": {
"type": "http",
"url": "https://mcp.context7.com/mcp",
"headers": {
"CONTEXT7_API_KEY": "${input:context7_api_key}"
}
},
"azure": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@azure/mcp@latest",
"server",
"start"
]
}
},
"inputs": [
{
"id": "context7_api_key",
"type": "promptString",
"password": true,
"description": "API key for Context7 Upstash instance"
}
]
} 
Secret-Werte in der Konfiguration (Bild 2)
Autor
Tool-Auswahl für aktuellen Kontext in VS Code (Bild 3)
AutorSind die MCP-Server konfiguriert, stehen sie dem GitHub Copilot Agent Mode als Tools zur Verfügung. Bild 3 zeigt die Tool-Auswahl: Über das kleine Werkzeug-Icon im Prompt-Feld öffnet sich das Menü Configure Tools. Hier können komplette MCP-Server oder auch einzelne Werkzeuge pro Server aktiviert beziehungsweise deaktiviert werden.
MCP-Konfiguration für den Coding Agent
Damit dieselben MCP-Server auch im Coding Agent in GitHub verwendet werden können, ist nahezu die gleiche Konfiguration erforderlich. Allerdings ist diese direkt in den GitHub-Repository-Einstellungen integriert und folgt einem leicht abweichenden Schema. Bild 4 zeigt die Konfiguration in GitHub; die vollständige JSON-Struktur ist in Listing 3 dargestellt.
Der Grund für die separate Konfiguration ist, dass der Coding Agent wesentlich autonomer agiert und gegebenenfalls mit anderen oder weniger MCPs arbeiten soll als der lokale Agent in VS Code. Auffällig ist außerdem, dass die JSON-Struktur hier ein "tools"-Array enthält. Während man in VS Code die Tools beim Prompting dynamisch auswählen kann, muss man sie beim Coding Agent vorab definieren, da hier keine Interaktion über ein Dialogfenster möglich ist.
Der Vollständigkeit halber muss erwähnt werden, dass der Coding Agent standardmäßig mit stark eingeschränkten Firewall-Regeln arbeitet. Greift ein MCP auf externe Dienste zu, müssen diese in den Firewall-Regeln explizit freigegeben werden.
Die Verwaltung von Secrets ist relativ einfach gelöst: In der MCP-Konfiguration sehen wir, dass der API-Key-Header den Wert "$COPILOT_MCP_CONTEXT7_API_KEY" enthält.
Secrets für Copilot-MCPs müssen mit dem Präfix COPILOT_MCP_ beginnen und im Copilot-Environment des Repositorys als Environment Secrets hinterlegt werden. Dies zeigt Bild 5. Zur Laufzeit wird der Wert automatisch aus dem Secret-Store eingefügt.
Die Authentisierung des Azure-MCP gestaltet sich dagegen etwas aufwendiger. Wie auch lokal muss das Azure CLI authentisiert werden. Dazu erweitern wir den Job copilot-setup-steps in der Workflow-Definition copilot-setup-steps.yml. Dieser Job läuft in der GitHub-Actions-Runner-Umgebung, bevor die Coding-Agent-Tasks ausgeführt werden. Die Authentisierung erfolgt dort wie in jedem anderen GitHub-Workflow. Listing 4 zeigt den entsprechenden Step. Damit ist auch der Coding Agent mit denselben MCPs ausgestattet wie unsere lokale VS-Code-Umgebung.
Coding-Agent-MCP-Konfiguration (Bild 4)
Autor
Secret-Verwaltung für Coding-Agent-MCPs (Bild 5)
AutorListing 3: Komplette MCP-Konfiguration für Coding Agent
{
"mcpServers": {
"microsoft-docs": {
"type": "http",
"url": "https://learn.microsoft.com/api/mcp",
"tools": ["*"]
},
"upstash-context7": {
"type": "http",
"url": "https://mcp.context7.com/mcp",
"headers": {
"CONTEXT7_API_KEY": "$COPILOT_MCP_CONTEXT7_API_KEY"
},
"tools": ["*"]
},
"azure": {
"type": "local",
"command": "npx",
"args": ["-y", "@azure/mcp@latest", "server", "start"],
"tools": ["*"]
}
}
} Listing 4: Azure-CLI-Authentisierung für Azure MCP
# .github/workflows/copilot-setup-steps.yml
on:
workflow_dispatch:
permissions:
id-token: write
contents: read
jobs:
copilot-setup-steps:
runs-on: ubuntu-latest
environment: copilot
permissions:
id-token: write
contents: read
steps:
- name: Azure login
uses: azure/login@a457da9ea143d694b1b9c7c869ebb04ebe844ef5
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
allow-no-subscriptions: true MCPs verwenden
Nachdem die MCP-Server registriert und die entsprechenden Tools für den Kontext aktiviert wurden, stehen sie im Agent zur Verfügung. Der Prompt, der an das Large Language Model gesendet wird, enthält die Informationen der aktivierten Tools, und das Modell entscheidet, welche davon aufgerufen werden.
Dabei ergibt sich allerdings eine Problematik: Wenn wir sehr viele MCP-Server mit zahlreichen Tools registrieren, blähen wir den Prompt unnötig auf. Im Extremfall kann sich dies sogar negativ auf die Qualität der Ergebnisse auswirken. Darum die klare Empfehlung: Aktivieren Sie nur die Tools, die für die jeweilige Aufgabe wirklich benötigt werden.
Wir können dem KI-Modell aber auch explizit mitteilen, welches Tool es verwenden soll. Dazu nutzen wir die #-Syntax: Mit #<ToolName> lässt sich ein Werkzeug direkt referenzieren und dem Modell klar vorgeben, dass es dieses Tool nutzen soll. Bild 6 zeigt die Verwendung des Azure-MCP mit einer expliziten Referenz auf das #aks-Tool, um Informationen aus einem bestehenden AKS-Cluster auszulesen.
Azure-MCP mit expliziter Tool-Referenz zur Abfrage der Nodes in einem AKS-Cluster (Bild 6)
AutorFazit
Mit dem Model Context Protocol (MCP) lassen sich GitHub Copilot Agent Mode und Coding Agent gezielt erweitern:
- Tools einbinden: von Dateizugriff über Tests bis hin zu Cloud-APIs.
- Integration vereinfachen: durch standardisierte Konfiguration (mcp.json lokal, Repository-Einstellungen im Coding Agent).
- Sichere Secrets: via Inputs in VS Code oder Copilot-Environment in GitHub.
- Steuerung im Prompt: automatisch durch Kontext oder gezielt via #ToolName.
Damit eröffnen MCP Server die Möglichkeit, Copilot-Agenten nicht nur als reine Code-Vervollständiger zu nutzen, sondern als flexible Plattform für komplexe Workflows und Automatisierungen – im lokalen VS Code ebenso wie im GitHub-Coding-Agent.
