Einführung in MCP: Von der Fragmentierung zu gemeinsamen Tool-Servern

Was wäre, wenn ein Sprachmodell in der Lage wäre, mit der realen Welt zu verbinden, zu kommunizieren und darauf zu handeln? MCP ist der Brückenschlag zwischen Intelligenz und Handlung.

ChatGPT wurde Mitte bis Ende 2022, am 30. November, eingeführt und beschleunigte den Einsatz von KI im Alltag – für Produktivität, tägliche Aufgaben und Problemlösung. Anbieter integrierten die KI anschließend in Produkte, die bereits im Einsatz waren: Produktivitätspakete, Chat-Apps, Suchfunktionen, IDEs und Unternehmenssoftware. Assistenten waren nicht mehr nur eigenständige Chatbots.

Dann trat ein schwierigeres Problem auf. Modelle können logisch denken und schreiben, doch sinnvolle Arbeit erfordert den richtigen Kontext, Daten, Werkzeuge und Systeme. Die Verknüpfung dieser Komponenten bedeutete in der Regel maßgeschneiderte Integrationen, APIs, Authentifizierungsmechanismen sowie kodenspezifische Lösungen. Dieser Zustand hat einen Namen: Fragmentierung.

Das Problem der Fragmentierung

Fragmentierung tritt auf, wenn Teams viele KI-Assistenten einsetzen, wobei jeder in seinem eigenen Ökosystem gefangen ist.

Stellen Sie sich einen Entwickler in VS Code vor. Der Assistent innerhalb des Editors versteht das Repository, in dem er sich befindet. Sobald sie außerhalb des IDEs auf GitHub Issues oder Confluence-Seiten angewiesen sind, verlassen sie den Assistenten, kopieren den Text, kleben ihn wieder ein und hoffen, dass das Modell genügend Kontext erhält.

Dieses ständige Wechseln der Tools sowie das manuelle Übertragen von Kontext führen zur Fragmentierung: Das Modell ist intelligent, kann aber nicht automatisch alle Systeme erkennen, die für eine Aufgabe benötigt werden.

Was „Kontext“ bedeutet

Kontext ist alles, was das Modell beim Beantworten wahrnehmen kann. Praktisch ausgedrückt: Alles, was das LLM verwendet, um eine Antwort zu strukturieren – meist die Chat-Geschichte sowie alles, was der Benutzer eingefügt hat.

Beispiel: Entwicklung einer Sicherheitsfunktion mit ChatGPT. Ein Entwickler könnte Folgendes tun:

1. JIRA – Anforderungen und Akzeptanzkriterien in den Chat kopieren.
2. GitHub – Verwandte Implementierungen und Repositorien einfügen.

MySQL – Systemdaten manuell abrufen und eingeben.

Google Drive – Dokumente, Sicherheitsrichtlinien sowie Architekturnotizen einfügen.

Teams/Slack – Undokumentiertes Wissen von Teamkollegen sammeln.

Nur dann stellen sie die eigentliche Frage. Das Modell antwortet besser – doch der Prozess ist aufwändig:

• Manuelles Kopieren und Einfügen zwischen Systemen ist langsam.
• Der Kontext wird zerstreut; Entwickler werden zu „menschlichen APIs“.
• Die Zusammenstellungsdauer kann die Entwicklungszeit überschreiten.
• Mehr Quellen machen den Prozess nicht skalierbar; reale Systeme sind größer als ein Einfügebuffert.

Genau dieser Aufwand hat Mitte 2023 die Entwicklung von Funktions-/Toolaufrufen vorangetrieben (OpenAI’s Arbeit).

Funktionsaufrufe

Durch Funktionsaufrufe kann ein Modell über Funktionen auf externe Ressourcen zugreifen und die Ergebnisse als Kontext nutzen. Chat allein machte Platz für die Automatisierung von Aufgaben: Das Modell wählt ein Tool aus, die App führt es aus und das Modell setzt fort.

Mit für JIRA, GitHub, MySQL, Drive, Slack und ähnliche Systeme definierten Tools kann das Modell auf Basis der Anweisung des Benutzers entscheiden, was ausgeführt werden soll, den Kontext abrufen und antworten – ohne dass ein Mensch ständig Inhalte eingeben muss.

Beschränkungen der Funktionsaufrufe pro Anwendung

Stellen Sie sich drei KI-Assistenten in einem Unternehmen vor. Jeder benötigt weiterhin eigene Funktionen/Integrationen für Datenbanken, GitHub, JIRA, Slack und ähnliche Systeme.

Falls Sie N Assistenten und M externe Ressourcen haben, besteht die Gefahr von N × M Integrationen. Zehn Assistenten × zwanzig Ressourcen ergeben etwa zweihundert maßgeschneiderte Verbindungen. Das Wachstum macht es teuer, dieses Netzwerk aufzubauen und am Laufen zu halten.

Falls jede App weiterhin jede Integration selbst verwaltet, verschiebt sich die Fragmentierung einfach: Die Schwierigkeiten bei der Zusammenstellung des Kontexts werden zu Integrationsproblemen.

Kann N × M auf N + M schrumpfen? Genau da kommt MCP ins Spiel.

Model Context Protocol (MCP)

MCP ist ein offenes Protokoll, das standardisiert, wie KI-Anwendungen mit externen Tools, Daten und Diensten verbunden werden.

Zwei Hauptrollen:

• MCP-Client – befindet sich in der KI-App/Agent, verbindet sich mit einem Server und entdeckt sowie nutzt bereitgestellte Tools/Ressourcen.
• MCP-Server – verbindet die KI-App mit GitHub, JIRA, einer Datenbank, Drive, Slack oder einem anderen Dienst.

Client ↔ Server kommunizieren über MCP. Anstatt dass jeder Assistent eigene Adapter für jeden Anbieter entwickelt, entdecken und rufen Apps ihre Funktionen über ein einheitliches Format auf.

Funktionsaufruf versus MCP – Beispiel Wetter

1. Funktionsaufruf

Man definiert eine app-eigene Funktion, die mit der Wetter-API kommuniziert:

import requests

def get_weather(city):
    response = requests.get(
        "https://api.weather.com/current",
        params={"city": city}
    )
    return response.json()

Man registriert diese Funktion als Tool. Der Benutzer fragt „Wie ist das Wetter in Bengaluru?“ Das Modell kann dann get_weather("Bengaluru") aufrufen. Die App führt diesen Aufruf aus, gibt Daten zurück und das Modell erstellt anschließend die Antwort.

Das Entwicklerteam der App ist für die Definition und Wartung dieser Funktion sowie des dazugehörigen API-Interfaces verantwortlich.

2. MCP

Die Wetterdaten befinden sich auf einem MCP-Server, der mit der API kommuniziert und ein standardisiertes Tool bereitstellt:

@mcp.tool()
def get_weather(city: str):
    """Get the current weather for a city."""
    return weather_api.get_current_weather(city)

Die KI-App ist ein MCP-Klient, der get_weather entdeckt. Bei derselben Benutzerfrage wird dieses Tool über MCP entdeckt bzw. aufgerufen, und das Ergebnis wird in der Antwort verwendet.

Der Unterschied: MCP standardisiert den Austausch zwischen der KI-App und den verfügbaren Funktionen, sodass ein Server viele kompatible Clients bedienen kann.

Vorteile von MCP

Das ist der „Warum“. Spätere Abschnitte behandeln die Architektur, die Interna sowie die praktische Umsetzung.

Nochmals einen Blick auf die Sicherheitsfunktionen

Kehren wir zum Entwickler zurück, der eine Sicherheitsfunktion entwickelt. Ohne MCP oder entsprechende Tools ist die Arbeit wie eine Suche durch JIRA, GitHub, MySQL, Drive und Slack – bei jeder Übertragung muss der Kontext neu eingefügt werden. Mit Funktionsaufrufen werden diese Schritte zu benannten Funktionen, die vom Modell aufgerufen werden können – doch jeder Assistent im Unternehmen benötigt weiterhin seine eigene Kopie der Integrationen.

MCP beseitigt diese Doppelung. Ein Wetterserver, ein JIRA-Server und ein GitHub-Server können viele MCP-kompatible Clients bedienen. Das N×M-Gitter nähert sich dann eher N Clients plus M Servern an.

Entwurfsaspekte, die Teams übersehen

Betrachten Sie Toolbeschreibungen als Produkttexte: Klare Namen und Parameterdokumentationen führen zur richtigen Modellauswahl. Halten Sie Schreibwerkzeuge hinter einer Bestätigung auf und trennen Sie Server von nur zum Lesen geeigneten Katalogwerkzeugen. Protokollieren Sie Toolaufrufe mit Korrelations IDs, damit ein schlechtes Ergebnis auf eine fehlerhafte Abfrage zurückgeführt werden kann, anstatt dem „Modell“ im Allgemeinen die Schuld zugeschrieben zu werden.

Beim Vergleich von Funktionsaufrufen und MCP für ein neues System fragen Sie, wer das Integrationslifecycle verantwortet. Wenn die Antwort „jedes Produktteam für immer“ lautet, rechtfertigen sich MCPs gemeinsame Server durch sich selbst. Wenn die Antwort „eine vorübergehende Demo“ ist, reicht eine lokale Funktion aus.

Was kommt als Nächstes

Sobald die Motivation klar ist – Fragmentierung, Zusammenstellung des Kontexts und Probleme bei der Integration – geht es im nächsten Schritt um die Architektur: Wie entdecken Clients Tools, wie authentifizieren Server, wie streamen Sessions Ergebnisse und wie wird ein erster Produktivserver bereitgestellt. Zu diesen Themen gehören eigene ausführliche Analysen; die Aufgabe dieses Artikels bestand darin, das „Warum“ unbestreitbar zu machen und das Wetterbeispiel auf beide Weisen zu zeigen.

Fragmentierung als Budgetproblem

Zählen Sie die Stunden, die Ihr Team damit verbringt, Inhalte aus JIRA und GitHub in Chats einzufügen. Diese Arbeitszeit stellt eine Art Steuer für jeden von Ihnen eingesetzten KI-Assistenten dar. Funktionsaufrufe verkürzen die Einfügezeit, erhöhen aber den Code für Adapter. MCP zielt darauf ab, die Kosten auf gemeinsam genutzte Server zu lenken anstelle von Forks pro Assistent.

Schreiben Sie den Geschäftsfall in diesen Begriffen: Weniger Arbeitsstunden für menschliche API-Verwaltung, weniger doppelte Integrationen, klarere Prüfpunkte. Für die Finanzen sind Architekturdiagramme weniger wichtig als Tabellen in der Form N×M.

Zusammenfassung zu Wetterbeispielen für Reviewer

Auf dem Weg über Funktionsaufrufe befindet sich der Wetter-HTTP-Client in der App. Auf dem MCP-Weg befindet er sich auf einem Server, den andere Apps wiederverwenden können. Derselbe Benutzeraufruf, unterschiedliche Eigentumsverhältnisse der Integration. Wählen Sie den Server, wenn bereits ein zweiter Client in Planung ist; wählen Sie die lokale Funktion, falls das Experiment im nächsten Sprint eingestellt wird.