Die Idee

Ein Coding-Agent kann mit den Dateien und Anweisungen arbeiten, die du ihm gibst. Eine Aufgabe hängt aber oft von Informationen außerhalb des Repositorys ab: einer Issue-Beschreibung, einem Support-Ticket oder interner Dokumentation. Diese Informationen in jeden Chat zu kopieren, kostet Zeit und kann veralten.

Das Model Context Protocol (MCP) ist ein offener Standard, um eine KI-Anwendung mit externen Datenquellen und Funktionen zu verbinden. Ein MCP-Client, etwa ein kompatibler Coding-Agent oder eine IDE-Funktion, verbindet sich mit einem MCP-Server. Der Server beschreibt, was er bereitstellen kann. MCP ist eine Verbindungsschicht. Es ersetzt weder deine Aufgabenanweisungen noch Projektdateien oder deinen Review-Prozess. GitHub beschreibt MCP als Möglichkeit, Copilot mit externen Datenquellen und Tools zu verbinden, und erklärt, dass MCP Prompts, Dateien und Anweisungen ergänzt. Quelle

Einfach gesagt: MCP ist eine standardisierte Brücke. Sie kann einem KI-Agenten den Zugang zu einem bestimmten externen System ermöglichen. Du entscheidest aber weiterhin, welche Brücke du verbindest und welche Zugriffe darüber möglich sind.

Die MCP-Spezifikation definiert drei Arten von Server-Funktionen, sogenannte Primitive. Ein Prompt ist eine nutzergesteuerte, wiederverwendbare Anweisung. Eine Resource ist anwendungsgesteuerter Kontext, also etwa Information, die ein Client bereitstellen kann. Ein Tool ist eine modellgesteuerte Funktion, die Informationen abrufen oder eine Aktion ausführen kann. Das sind getrennte Konzepte. Ein Tool ist nicht bloß zusätzlicher Text für das Modell, sondern eine vom Server bereitgestellte aufrufbare Funktion. Quelle

Stell dir MCP als Adapter vor, nicht als Intelligenz. Der Adapter kann einen Issue-Tracker verfügbar machen. Er entscheidet nicht, ob der Agent ein Issue richtig verstanden oder eine sichere Codeänderung vorgeschlagen hat.

Ein kleines Beispiel

Beispiel (hypothetisch): Dein Team verwaltet Fehlerberichte in einem Issue-Tracker. Du verbindest einen geprüften MCP-Server, der ein schreibgeschütztes Tool zum Nachschlagen von Issues anbietet.

Du schreibst: „Lies Issue DEV-42. Ermittle vermutlich betroffene Dateien in diesem Repository. Schlage eine Änderung vor, aber bearbeite keine Dateien.“

Der Prompt legt Ziel und Grenze fest: vorschlagen, nicht bearbeiten. Das MCP-Tool liefert die Issue-Daten. Dein Repository und die Projektanweisungen liefern weiterhin den Code-Kontext und die Arbeitsregeln. Anschließend gibt der Agent einen Vorschlag zurück, den du wie jede andere vorgeschlagene Änderung prüfst.

Diese Trennung ist nützlich. Wenn etwas nicht stimmt, kannst du gezielter fragen: War die Anweisung unklar, waren die externen Daten unvollständig, lieferte das Tool ein falsches Ergebnis, oder war der Vorschlag schlecht?

Die MCP-Unterstützung ist nicht überall gleich. Was ein Server anbietet und was eine bestimmte Client-Oberfläche unterstützt, kann sich unterscheiden. GitHub dokumentiert zum Beispiel unterschiedliche MCP-Unterstützung für verschiedene Copilot-Oberflächen. Prüfe die Dokumentation des Clients, statt anzunehmen, dass jeder Prompt, jede Resource oder jedes Tool verfügbar ist. Quelle

Probier es aus

Nimm dir fünf Minuten für eine kleine, risikoarme Prüfung.

  1. Wähle ein externes System, das du bereits nutzt, etwa einen Issue-Tracker oder eine Dokumentationsquelle.
  2. Frage dich, ob der Agent wirklich externen Zugriff braucht. Liegt die benötigte Information bereits im Repository, ist vielleicht keine MCP-Verbindung nötig.
  3. Falls ein MCP-Server verfügbar ist, liste die angebotenen Tools auf. Wähle für den ersten Test möglichst ein schreibgeschütztes Tool zum Nachschlagen.
  4. Prüfe Konto, Zugangsdaten und Berechtigungsumfang. Erteile nur Zugriff auf die Ressourcen, die du für diese eine Aufgabe benötigst.
  5. Teste die Verbindung und bitte dann um eine Zusammenfassung eines bekannten Eintrags. Vergleiche die Antwort mit der Quelle, bevor du sie für eine Coding-Aufgabe nutzt.

GitHub empfiehlt, Drittanbieter-Server zu prüfen, nur benötigte Tools zu aktivieren, Zugangsdaten eng zu begrenzen und die Konfiguration zu validieren. Quelle

Darauf solltest du achten

Ein MCP-Server ist Software und eine Vertrauensgrenze. Behandle einen Server nicht automatisch als sicher, nur weil sein Name bekannt ist oder die Verbindung funktioniert. Prüfe, was er bereitstellt, wer ihn betreibt, welches Konto er nutzt und ob er lesen, schreiben oder Aktionen auslösen kann.

Wähle den kleinsten nützlichen Berechtigungsumfang. Schreibgeschützter Zugriff ist oft ein sichererer Einstieg als Schreibzugriff. GitHub warnt außerdem, dass sein Copilot Cloud Agent konfigurierte MCP-Tools eigenständig und ohne Bestätigung vor jedem Aufruf verwenden kann. Das gilt speziell für diese Produktoberfläche, zeigt aber, warum der Umfang von Tools wichtig ist. Quelle

Zugriff bedeutet zuletzt nicht Korrektheit. MCP kann aktuelle externe Informationen oder aufrufbare Funktionen bereitstellen. Es kann nicht garantieren, dass ein Agent das richtige Tool auswählt, dessen Ergebnis versteht oder die richtige technische Entscheidung trifft. Prüfe Ergebnisse und geplante Änderungen, bevor du sie übernimmst.