MCP – wenn KI-Modelle aufhören zu fragen und anfangen zu handeln

Die Art und Weise, wie Systeme miteinander kommunizieren, verändert sich gerade grundlegend. Mit dem Aufstieg von KI-Modellen verändern sich auch die Anforderungen an Schnittstellen. Systeme müssen nicht nur Daten liefern, sondern auch Tools, Ressourcen und Kontext strukturiert bereitstellen.

Genau hier setzt das Model Context Protocol (MCP) an. Es schafft einen einheitlichen Standard, wo bestehende Lösungen oft fragmentiert und schwer erweiterbar sind. Doch warum brauchen wir diesen neuen Ansatz und wie funktioniert MCP eigentlich?

Warum wir über Protokolle reden müssen

Stell dir vor, du schickst eine:n neue:n Mitarbeiter:in ins Büro, ohne zu sagen, welche Tools die Person benutzen darf, welche Systeme existieren oder wen sie fragen kann. Genau das passiert mit KI-Agenten, wenn sie auf klassische APIs treffen.

Mit dem Aufkommen von Modellen wie GPT, Claude oder Gemini hat sich die Erwartung an Software fundamental verschoben: Systeme sollen nicht mehr nur Daten liefern, sondern eigenständig Entscheidungen treffen und Aktionen ausführen. Und genau hier kommen Protokolle ins Spiel. Sie schaffen eine gemeinsame Sprache zwischen KI-Agenten und den Systemen, mit denen sie arbeiten sollen, etwa JIRA, Slack oder internen Datenbanken.

Die Grenzen klassischer APIs

REST-APIs basieren auf einem einfachen Prinzip: Ein Client kennt einen Endpunkt, schickt eine Anfrage, bekommt eine Antwort. Das funktioniert hervorragend, solange der Workflow im Voraus klar definiert ist.

Für KI-Agenten ist das jedoch ein grundlegendes Problem. Ein Agent muss zur Laufzeit entscheiden, welche Aktion sinnvoll ist. Dafür braucht er zuerst eine Antwort auf die Frage: Was kann ich hier überhaupt tun?

Klassische REST-APIs können diese Frage nicht beantworten. Sie bieten keine standardisierte Möglichkeit zur sogenannten Tool-Discovery, also zur dynamischen Abfrage verfügbarer Funktionen.

Einstieg in MCP – das Model Context Protocol

Auf genau dieser Problematik baut das seit 2024 von Anthropic entwickelte Protokoll MCP (Model Context Protocol) auf. Es ermöglicht eine standardisierte Kommunikation zwischen KI-Modellen und externen Tools wie GitHub, Jira, Slack, Notion oder auch lokalen Anwendungen, ohne dass das Modell die zugrunde liegenden APIs kennen oder verstehen muss.

Ein konkretes Beispiel: Ein Agent soll automatisch aus einem GitHub-Issue ein Jira-Ticket erstellen. Mit klassischen APIs müsste der Agent die GitHub-API und die Jira-API kennen, beide Authentifizierungsflows verstehen und die Datenstrukturen manuell mappen. Mit MCP fragt der Agent einfach: „Welche Tools hast du?” und bekommt eine vollständige, strukturierte Antwort. Er weiß sofort, dass get_issues und create_ticket verfügbar sind, was sie tun und welche Parameter sie erwarten.

Wie MCP funktioniert - die Grundlagen

MCP stellt drei zentrale Bausteine bereit: 

Tools

Tools sind konkrete Funktionen, die ein KI-Modell aufrufen kann, bei JIRA zum Beispiel get_issues oder create_ticket. Jedes Tool enthält dabei:

• Einen eindeutigen Namen zur Identifikation
• Eine Beschreibung, die erklärt, wann und wofür das Tool sinnvoll ist
• Ein Parameter-Schema (meist JSON-Schema), das definiert, welche Eingaben erwartet werden
• Eine definierte Antwortstruktur, damit das Modell die Ergebnisse korrekt interpretieren kann

Ressourcen

Neben Tools können MCP-Server auch Ressourcen bereitstellen. Dazu zählen zum Beispiel Dokumentationen, Konfigurationswerte, Wikis oder andere strukturierte Inhalte, die ein Modell als zusätzlichen Kontext nutzen kann. Der Server beschreibt jede Ressource so, dass das Modell weiß, wo sie liegt, wie sie geladen werden kann und in welchem Format sie vorliegt. 

Prompts

Prompts sind vordefinierte Eingabevorlagen für wiederkehrende Aufgaben, zum Beispiel ein standardisiertes Bug-Report-Template, ein Merge-Request-Schema oder eine Deployment-Checkliste. Das Modell muss das Rad nicht jedes Mal neu erfinden, sondern greift auf bewährte Vorlagen zurück. 

Architektur hinter MCP

MCP folgt einem klaren Client-Server-Modell:

• Der Host (z. B. Claude Desktop oder VS Code) stellt die Umgebung bereit.
• Das KI-Modell kommuniziert über JSON-RPC 2.0 mit einem MCP-Client.
• Der MCP-Client übernimmt Tool-Discovery und Aufrufe.
• MCP-Server verbinden sich mit externen Diensten wie GitHub, Slack oder Jira.

Funktionsweise

Das folgende Diagramm zeigt einen exemplarischen Ablauf für die Verwendung von MCP, um Issues aus GitHub abzufragen. 

1. Der/die Nutzer:in stellt eine natürlichsprachliche Frage: „Welche Issues sind in meinem GitHub-Repository?” Gleichzeitig stellt der MCP-Server dem Modell alle verfügbaren Tools bereit – inklusive Beschreibungen und erwarteten Parametern.
   
2. Das Modell analysiert die Anfrage und wählt eigenständig das passende Tool aus. Es generiert einen vollständigen MCP-Call mit den korrekten Parametern, ohne dass ein:e Entwickler:in diesen Mapping-Schritt manuell programmieren muss.
   
3. Je nach Implementierung und Sicherheitskonfiguration wird der/die Nutzer:in vor der Ausführung um eine explizite Bestätigung gebeten. Gerade bei schreibenden oder destruktiven Aktionen ist dieser Schritt empfehlenswert.
   
4. Der MCP-Client nimmt den Aufruf entgegen und leitet die Anfrage strukturiert an den zuständigen MCP-Server weiter.
   
5. Der MCP-Server übersetzt den Aufruf in einen konkreten GitHub-API-Request und schickt diesen an die GitHub-API.
   
6. Die GitHub-API verarbeitet die Anfrage und liefert die angeforderten Issues zurück.
   
7. Der MCP-Server gibt die Ergebnisse an den MCP-Client zurück.
   
8. Der MCP-Client übergibt die Informationen als strukturierten Kontext an das LLM.
   
9. Das Modell verarbeitet die Daten und formuliert eine verständliche, natürlichsprachliche Antwort für den/die Nutzer:in: „Aktuell existieren 2 Issues zu folgenden Themen: …” 

MCP in der Praxis

Der größte Mehrwert von MCP zeigt sich jedoch nicht bei einfachen Abfragen wie „Wie viele Issues sind noch offen?”. Solche Abfragen wären auch mit klassischen APIs lösbar. Der Vorteil zeigt sich dort, wo Informationen aus mehreren Systemen gleichzeitig gefragt sind. Ein Beispiel hierzu: „Welche JIRA-Tickets sind aktuell in Bearbeitung, und wie ist der zugehörige Fortschritt auf GitHub?”. Ohne MCP würde das bedeuten: zwei separate API-Anfragen und manuelles Zusammenführen der Ergebnisse.

Das eröffnet auch ganz neue Möglichkeiten abseits der reinen Entwicklungsarbeit. Neue Mitarbeitende könnten interne Fragen direkt an einen Agenten stellen: „Wo finde ich den Code für Projekt X?” oder „Wer ist für die neuesten Tickets in JIRA zuständig?”. Der Agent weiß die Antwort, da er alle angebundenen Systeme kennt und zur Laufzeit entscheiden kann, wo er suchen muss. 

Was MCP jetzt schon kann

MCP bietet eine Vielzahl an Funktionen, die speziell für KI-Modelle einen enormen Vorteil gegenüber klassischen APIs bieten.

Ein zentrales Merkmal ist die dynamische Tool-Discovery: Ein MCP-Client muss nicht im Voraus wissen, welche Funktionen ein System anbietet. Er fragt einfach beim Server nach und bekommt eine vollständige Liste aller verfügbaren Tools, Ressourcen und Prompts zurück, inklusive aller Beschreibungen und Schemata. Das macht eine enge Kopplung zwischen Client und Server überflüssig.

Hinzu kommt die Plattformunabhängigkeit. Egal ob GitHub, Slack, Jira, Notion, interne Microservices oder lokale Tools, MCP bietet eine einheitliche Schnittstelle für alle. Das KI-Modell muss nicht wissen, welche Technologie dahintersteckt, und kann trotzdem zuverlässig mit jedem angebundenen System interagieren.

Nicht zuletzt punktet MCP mit seiner unkomplizierten Anpassbarkeit. Wenn sich ein API-Endpunkt oder die Logik hinter einem Tool ändert, muss nur der MCP-Server aktualisiert werden. Beim nächsten Verbindungsaufbau erhält das Modell automatisch die neuen Informationen, ohne dass Anpassungen auf Client-Seite notwendig wären. 

Grenzen von MCP – wo das Protokoll (noch) nicht perfekt ist

So mächtig dieser Standard bereits wirkt, es ist erst der Anfang. MCP existiert erst seit 2024 und ist noch nicht so ausgereift wie etablierte Web-Standards. Viele Implementierungen sind noch experimentell, Best Practices entstehen gerade erst.

Dazu kommt: MCP funktioniert nur so gut wie das KI-Modell, das es nutzt. Verwendet man ein LLM, das Tool-Aufrufe schlecht generiert oder Schemata falsch interpretiert, hilft auch der beste MCP-Server wenig. Das Protokoll sorgt nicht automatisch dafür, dass ein Modell sinnvoll mit den bereitgestellten Fähigkeiten umgeht.

Reasoning-fähige Modelle sind für komplexe MCP-Workflows klar im Vorteil, kosten jedoch deutlich mehr Tokens, was je nach Anwendungsfall die Kosten spürbar in die Höhe treiben kann. 

Ein kurzer Einschub zur Sicherheit

MCP-Agenten führen echte Aktionen in echten Systemen aus, weshalb hier strengere Anforderungen als bei klassischen Read-Only-APIs gelten.

Principle of Least Privilege: Ein MCP-Server sollte nur die Funktionen anbieten, die tatsächlich gebraucht werden. Ein Server für GitHub-Issues braucht keinen Write-Zugriff auf das Repository.

Human-in-the-Loop für destruktive Aktionen: Operationen wie delete_branch, send_email oder create_ticket sollten eine explizite Bestätigung des/der Nutzer:in erfordern, bevor der Agent sie ausführt.

Audit-Logging: Jeder Tool-Aufruf sollte mit Zeitstempel, Parametern und Ergebnis geloggt werden. Nicht für Compliance, sondern weil unkontrollierte Agenten-Loops schwer zu debuggen sind.

Fazit

MCP ist kein Ersatz für klassische APIs. Es ist eine Ergänzung für eine neue Generation von Software, in der KI-Modelle nicht nur Daten abrufen, sondern aktiv handeln.

Der Standard steckt noch in den Anfängen, aber die Richtung ist klar: Systeme müssen ihre Fähigkeiten nicht mehr nur anbieten, sondern aktiv beschreiben. Wer heute mit MCP arbeitet, bekommt auf mcpservers.org einen guten Einstieg mit einer wachsenden Sammlung fertiger Server.

Seminarempfehlung