Entwurf vereint KI und App mit neuer Protokollschicht MCP

Ein einfacher Leitfaden für das Model Context Protocol (MCP) für Softwareentwickler In letzter Zeit taucht der Begriff Model Context Protocol (MCP) immer häufiger in der Softwareentwicklung auf. Aber was ist es genau und warum sollten Entwickler sich damit befassen? Dieser Artikel beantwortet drei Kernfragen: Was ist Model Context Protocol (MCP)? Warum benötigen wir es? Wie können Entwickler MCP verwenden oder implementieren? Was ist Model Context Protocol (MCP)? Das Model Context Protocol (MCP) ist eine Antwort auf die steigende Komplexität des Prompt Engineering. Während Entwickler daran arbeiteten, die Leistung großer Sprachmodelle (LLMs) zu verbessern, stellten sie fest, dass die Bereitstellung strukturierter und relevanter Kontextinformationen die Qualität der Antworten erheblich erhöht. Die Grundlagen: Vom manuellen Prompt zur MCP Um zu verstehen, warum MCP wichtig ist, müssen wir einen Schritt zurückgehen und uns ansehen, wie Kontext früher an große Sprachmodelle übermittelt wurde und wie dieser Prozess sich durch RAG und Funktionsaufrufe entwickelt hat, was schließlich zur Notwendigkeit von MCP führte. Vor MCP: Manuelle Prompts und Schmerzen Bevor Lösungen wie RAG oder Funktionsaufrufe existierten, war die Übermittlung von Kontext an ein Modell ein manuelles und fehleranfälliges Verfahren. Stellen Sie sich vor, Sie bauen einen Chatbot, der interne Unternehmensfragen beantwortet. Sie würden wahrscheinlich: Manuell die erforderlichen Informationen in den Prompt einfügen. Keine strukturierte Möglichkeit haben, woher die Informationen stammen oder wie verlässlich sie sind. Diese Methode funktioniert in einfachen Fällen, aber bei einem wachsenden Datenumfang und komplexeren, dynamischeren Aufgaben wird das manuelle Einfügen von Kontext: Zeitintensiv Fehleranfällig Skalierungsunfähig Sie schreiben praktisch einen benutzerdefinierten Prompt für jede Anfrage, und das System hat keine strukturierte Möglichkeit, die Herkunft oder Zuverlässigkeit der Informationen zu erkennen. Retrieval-Augmented Generation (RAG): Kontext aus Daten Um dieses Problem zu lösen, wurde RAG (Retrieval-Augmented Generation) eingeführt. RAG ermöglicht es dem Modell, dynamisch externe Informationen abzurufen, die zur Frage des Benutzers relevant sind. Anstatt alle erforderlichen Kenntnisse in den Prompt einzubauen, verwendet RAG ein Abrufmodell oder eine Suchfunktion, um: Die Absicht des Benutzers zu interpretieren. Eine vordefinierte Wissensbasis (z.B. Dokumente, Wikis, Datenbanken) zu durchsuchen. Die relevantesten Abschnitte zu extrahieren. Diese als zusätzlichen Kontext in den Prompt einzufügen. Beispielablauf: Benutzer: "Wie viele Urlaubstage habe ich?" System durchsucht HR-Richtliniendokumente. Findet den relevanten Absatz. Ergänzt: "Laut Firmenrichtlinien sind Mitarbeiter berechtigt zu 15 Tagen bezahltem Urlaub..." LLM generiert eine Antwort basierend auf diesen Informationen. Diese Technik verbessert die Genauigkeit und die Qualität der Antworten ohne das Modell neu zu trainieren. Allerdings bleibt es dabei ein schreibgeschützter Prozess – das Modell kann die Daten sehen, aber nicht mit Systemen interagieren oder Aktionen ausführen. Funktionsaufrufe: Vom passiven Wissen zum aktiven Verhalten Der nächste wichtige Schritt kam, als LLMs begannen, Tools und nicht nur Text zu verarbeiten. Dies wurde durch Funktionsaufrufe möglich, eine Funktion, die von Anbietern wie OpenAI und Google eingeführt wurde. Mit Funktionsaufrufen kann das Modell: Tools aufrufen, z.B. um den aktuellen Wetterbericht für eine Stadt abzurufen. Daten abrufen, z.B. aus einer lokalen Dateisystemstruktur. Aktionen ausführen, z.B. um eine Datei zu öffnen oder zu bearbeiten. Dies ermöglichte agentenähnliches Verhalten. Zum Beispiel konnte ein Modell: Benutzerprofile abrufen. Wetterdaten für eine Stadt holen. Beispiel für Funktionsaufruf: json { "function_call": { "name": "get_user_profile", "arguments": { "user_id": "123456" } } } Wieder einmal war dies ein großer Schritt nach vorn. Allerdings hatten wir jetzt ein neues Problem: Jedes Plattform hatte seinen eigenen Ansatz, und Funktionsdefinitionen waren nicht standardisiert. Entwickler mussten neuen Verbindungscode schreiben, um Modelle, Tools und Datenquellen zu verknüpfen. MCP: Ein gemeinsames Sprachrohr zwischen Apps und LLMs Im November 2024 stellte Anthropic das Model Context Protocol (MCP) vor, ein vorgeschlagenes Standardprotokoll, wie Anwendungen und LLMs strukturierten Kontext austauschen können. MCP definiert eine konsistente und standardisierte Methode, wie Apps strukturierten Kontext an KI-Modelle liefern. Es fungiert als Zwischenschicht zwischen dem Modell und den Tools, Ressourcen, Datenbanken, Funktionen und Benutzerzuständen, die es verarbeiten muss. Ebenso wie USB-C die Art vereinheitlicht, wie wir Hardwaregeräte verbinden, zielt MCP darauf ab, die „Verbindung“ des Kontexts zu vereinheitlichen – wodurch die Integration einfacher, sauberer und konsistenter zwischen verschiedenen Systemen wird. Man kann sich MCP als „Middleware“ zwischen Ihrer App und dem LLM vorstellen – eine Brücke, die den strukturierten Kontext in einer vorhersagbaren, modellfreundlichen Weise organisiert und liefert. Was MCP ermöglicht Ohne MCP ist die Integration von Tools und Kontext oft fragmentiert und für jede App oder jeden Anbieter individuell angepasst. Jedes Modell stellt APIs unterschiedlich zur Verfügung, jedes Entwicklerteam erfindet das Rad neu, und Codebasen werden eng an spezifische Implementierungen gekoppelt. MCP löst diese Fragmentierung, indem es eine gemeinsame Sprache zwischen Apps und Modellen bietet, was fortgeschrittene Szenarien wie Agentenorchestrierung und dynamische Toolketten viel skalierbarer macht. Es schafft eine Middleware-Schicht, die Entwicklern ermöglicht, festzulegen, welcher Kontext erforderlich ist, woher er stammt und wie er verwendet werden soll – alles ohne jede Spezialfall-Logik zu hardcoden. MCP-Architektur Um zu verstehen, wie MCP in der Praxis funktioniert, müssen wir uns seine interne Struktur ansehen. Im Großen und Ganzen ist MCP nicht nur eine Hülle für Prompts oder Tools, sondern ein strukturiertes Protokoll, das definiert, wie Anwendungen Kontext liefern, Fähigkeiten offenlegen und mit Sprachmodellen interagieren. 1. Host Der Host ist die benutzerseitige Anwendung, die als Hauptumgebung für die Interaktion mit dem Sprachmodell dient. Er verwaltet Eingabe/Ausgabe und enthält den eingebetteten MCP-Client. 2. Client Der Client läuft innerhalb des Hosts und verwaltet die Kommunikation mit einem oder mehreren MCP-Servern. Er ist für die Dienstentdeckung, Fähigkeitsaustausch und Nachrichtenrouterung verantwortlich. 3. Server Der Server offenlegt Fähigkeiten an das Modell, einschließlich Tools (Funktionen), Ressourcen (Daten) und Prompts (Vorlagen). Jeder Server registriert seine Fähigkeiten während des Handshake-Prozesses, der als Fähigkeitsaustausch bekannt ist. Fähigkeitsaustausch Fähigkeitsaustausch ist ein Entdeckungsmechanismus, durch den der MCP-Client die verfügbaren MCP-Server abfragt, um herauszufinden, welche Tools, Prompts und Ressourcen sie unterstützen. Dieser Handshake-Prozess ermöglicht es dem LLM, die exakten Fähigkeiten zu verstehen, ohne Logik zu hardcoden. Datenformat und Protokoll MCP verwendet JSON-RPC 2.0 als Messaging-Protokoll, um die Struktur von Anfragen und Antworten zwischen Clients und Servern zu definieren. Nachrichten folgen einem strengen Format, das Methodennamen, Parameter und Ergebnis- oder Fehlerpayloads einschließt. Beispiel-POST-Anfrage: http POST /messages HTTP/1.1 Content-Type: application/json { "jsonrpc": "2.0", "method": "tools/list", "id": 1 } Serverantwort (über SSE): json { "jsonrpc": "2.0", "id": 1, "result": { "tools": [ { "name": "get_weather", "description": "Aktuelles Wetter für eine Stadt abrufen", "inputSchema": { "type": "object", "properties": { "city": { "type": "string" } }, "required": ["city"] } } ] } } Lebenszyklus des Toolaufrufs Toolentdeckung: Der Client sendet eine Anfrage (tools/list), um verfügbare Tools zu entdecken. LLM-Auswahl: Der Client fügt diese Tools in einen Prompt ein. Das Modell wählt ein Tool, indem es einen JSON-Block mit Toolnamen und Argumenten zurückgibt. Ausführung: Der Client parst die Antwort des Modells und führt das Tool über den Server aus. Ergebnishandling: Das Ergebnis wird an das Modell zurückgesendet, das es zur endgültigen Interpretation verwendet. Wie MCP funktioniert Hier ist ein hoher Überblick darüber, wie der MCP-Client, -Server und das LLM interagieren: Dieses Diagramm zeigt den Ablauf eines typischen MCP-basierten Anliegens: vom Sammeln des Kontexts bis zur optionalen Toolausführung und Rückgabe des Ergebnisses. Es verdeutlicht, wie MCP die strukturierte Kommunikation zwischen Ihrer App und dem Modell vereinfacht. Praktisches Szenario Lassen Sie uns ein praktisches Beispiel durchgehen: Benutzer: "Welche Dokumente sind auf meinem Desktop?" Host (Claude Desktop / Cursor) erhält die Benutzeranfrage. Host analysiert den Prompt und bestimmt, dass Zugriff auf das lokale Dateisystem erforderlich ist. Eingebetteter MCP-Client initialisiert eine Verbindung zum Dateisystem-MCP-Server. Client und Server führen Fähigkeitsaustausch durch. Server stellt eine Liste verfügbarer Tools bereit (z.B. list_txt_files). Client ruft das entsprechende Tool auf. Server gibt das Ergebnis zurück (Liste der Desktopdokumente). Host generiert eine Antwort. Host zeigt die finale Antwort an den Benutzer. Wie können Entwickler MCP verwenden oder implementieren? Eine der einfachsten Möglichkeiten, um heute mit MCP zu arbeiten, ist durch Cursor, eine entwicklerzentrierte AI-IDE, die MCP bereits nativ unterstützt. MCP in Cursor verwenden Cursor führt einen eingebetteten MCP-Client im Hintergrund aus. Wenn Sie der KI etwas fragen, wie: "Schreibe Unit-Tests für diese Funktion" "Auf was basiert dieser Code?" "Suche in meinem Projekt nach TODOs" Dann geschieht im Hintergrund Folgendes: Cursor sendet Ihre Anfrage an das LLM (wie Claude oder GPT). Es entdeckt automatisch verfügbare Tools und Kontext über MCP. Falls erforderlich, ruft es das richtige Tool auf (z.B. Dateianalysator, Abhängigkeitsbaum-Generator). Das Toolergebnis wird an das Modell zurückgesendet. Das LLM verwendet diese strukturierten Ausgaben, um eine genaue Antwort zu generieren. Eigene Tools mit MCP in Cursor erstellen Möchten Sie Ihre eigene Backendlogik in den AI-Workflow von Cursor integrieren? Sie können dies tun, indem Sie einen benutzerdefinierten MCP-Server mit Python erstellen. Hier ist, wie Sie vorgehen: 1. Voraussetzungen installieren Um einen benutzerdefinierten MCP-Server für Cursor zu erstellen, benötigen Sie ein Python-Projekt mit der mcp-Bibliothek. Ich empfehle Ihnen, uv zu verwenden, aber Sie können auch pip verwenden, wenn Sie das bevorzugen. Falls Sie uv noch nicht installiert haben, hier ist, wie Sie das machen: bash brew install astral-sh/astral/uv curl -Ls https://astral.sh/uv/install.sh | sh Schritt-für-Schritt-Einrichtung Neues MCP-Projekt initialisieren: bash mcp uv init mcp-demo Dies setzt eine grundlegende Projektschablone in einem Ordner namens mcp-demo auf. Projektordner betreten: bash cd mcp-demo Virtuelle Umgebung erstellen: bash uv venv Virtuelle Umgebung aktivieren: bash source .venv/bin/activate Die Aktivierung der Umgebung stellt sicher, dass alle Pakete isoliert von Ihrem System-Python installiert und ausgeführt werden. Kern-MCP-Paket hinzufügen: bash uv add mcp CLI-Utilities für den Bau und Betrieb von MCP-Tools hinzufügen: bash uv add 'mcp[cli]' 2. Code erstellen Nun bauen wir unser Tool. Wir teilen den Code in zwei Dateien auf, um Klarheit zu schaffen: server.py: ```python from mcp.server.fastmcp import FastMCP import os mcp = FastMCP() @mcp.tool() def list_text_files() -> list[dict]: """Listet alle .txt-Dateien im Projektordner.""" files = [] for root, _, filenames in os.walk("."): for fname in filenames: if fname.endswith(".txt"): full_path = os.path.join(root, fname) files.append({ "path": full_path, "name": fname }) return files @mcp.tool() def count_words_in_file(path: str) -> dict: """Zählt die Anzahl der Wörter in einer bestimmten Datei.""" if not os.path.isfile(path): return {"error": f"Datei nicht gefunden: {path}"} with open(path, "r", encoding="utf-8") as f: content = f.read() word_count = len(content.split()) return { "file": path, "word_count": word_count } ``` main.py: ```python from server import mcp if name == "main": mcp.run(transport="stdio") ``` 3. Server lokal ausführen (für Debugging) Um Ihr Tool lokal auszuführen und außerhalb von Cursor zu testen: bash uv run mcp dev main.py Dies startet den MCP-Server im Dev-Modus und druckt alle Toolaufrufe und Ergebnisse in Ihr Terminal. MCP-Inspector verwenden (für Debugging) Wenn Sie den Dev-Server ausführen, sehen Sie in Ihrem Terminal eine lokale URL wie diese: Inspector verfügbar unter: http://localhost:6274/?MCP_PROXY_AUTH_TOKEN=... Öffnen Sie diesen Link in Ihrem Browser, um auf den MCP-Inspector zuzugreifen – ein eingebautes Tool, um Ihre Server manuell zu testen und zu erkunden. Inspektor verwenden: Öffnen Sie die Inspector-URL in Ihrem Browser. Klicken Sie oben rechts auf Connect. Klicken Sie auf List Tools, um die von Ihrem Server offengelegten Tools anzuzeigen. Wählen Sie ein Tool wie list_text_files oder count_words_in_file aus. Geben Sie Beispieleingaben (z.B. Pfad zu einer .txt-Datei) ein und führen Sie es aus. Sehen Sie sich die strukturierten Ausgaben in Echtzeit an. 4. In Cursor aktivieren Sobald Ihr MCP-Server bereitsteht, können Sie ihn global in allen Cursor-Projekten verfügbar machen, indem Sie ihn in Ihre globale Cursor-Konfiguration hinzufügen: json { "mcpServers": { "word-counter": { "command": "uv", "args": ["run", "python", "{FILE_PATH}/mcp-demo/main.py"] } } } Dies informiert Cursor, Ihren MCP-Server automatisch zu starten und seine Tools dem in-Editor-Assistenten zur Verfügung zu stellen. 5. Cursor neu starten Sobald Ihr Server definiert ist, starten Sie Cursor neu. Es wird dann: Sie können nun Dinge wie "Liste alle Textdateien in diesem Ordner" oder "Zähle die Wörter in dieser Datei" eingeben. Cursor leitet die Anfrage über Ihren MCP-Server weiter, führt Ihr Python-Tool aus und gibt die Ergebnisse direkt im Editor zurück. Durch die Kombination von MCP und Cursor bauen Sie nicht nur Software, sondern intelligente, von KI erweiterte Entwicklertools, und das fast ohne Boilerplate-Code. Fazit Als Softwareentwickler verbringen wir viel Zeit damit, APIs zu verdrahten, Randfälle zu behandeln und Verbindungscode zu warten. MCP ändert das. Es bietet eine saubere und konsistentere Methode, um die alltäglichen Aufgaben, die wir ohnehin schon erledigen, zu handhaben – nun mit Sprachmodellen im Spiel. Mit AI als Teil des modernen Entwicklungsstacks ist das Lernen von Protokollen wie MCP nicht mehr optional – es ist der nächste Schritt, um intelligenter, schneller und wartbarere Systeme zu bauen.