Was ist MCP?
Das Model Context Protocol (MCP) ist ein standardisierter Weg, um KI-Agenten mit externen Tools und Datenquellen über dedizierte Server-Prozesse zu verbinden. Anstatt Tools inline im Agenten-Code zu definieren, führt MCP einen separaten Server aus, der Tools über ein strukturiertes Protokoll bereitstellt.
MCP vs. Reguläre Tool-Aufrufe
Ein Modelltoolaufruf beschreibt eine beabsichtigte Aktion; der Host führt sie aus. Er kann eine lokale Funktion, eine CLI, eine entfernte API oder einen MCP-Server aufrufen. MCP standardisiert Erkennung und Kommunikation, nicht den Toolaufrufmechanismus des Modells.
Reguläre Tool-Aufrufe
Hostdefinierte Tools können lokal oder entfernt laufen. Integration und Lebenszyklus hängen von der Anwendung ab.
const tools = {
get_weather: (location) => {
return fetchWeather(location)
}
}
// Direct function call
result = tools.get_weather("Tokyo")MCP-Server
Server bieten ein gemeinsames Protokoll über lokales stdio oder Streamable HTTP. Serialisierung und Prozessgrenzen erzeugen Aufwand; stdio braucht keine Netzwerkverbindung.
// Separate server process
const client = new MCPClient()
// Discover tools via protocol
tools = await client.listTools()
// Call over network
result = await client.invoke(
"get_weather", { location: "Tokyo" }
)Wann MCP sinnvoll ist
MCP glänzt in spezifischen Szenarien, in denen sich seine zusätzliche Komplexität auszahlt.
Multi-Sprachen-Teams
Deine Tools sind in Python geschrieben, aber dein Agent ist in TypeScript, oder umgekehrt.
Gemeinsames Tool-Ökosystem
Mehrere Agenten in verschiedenen Projekten müssen auf dieselben Tools zugreifen.
Enterprise-Integration
Du musst bestehende interne Dienste als Agenten-Tools bereitstellen, ohne sie zu modifizieren.
Tool-Marktplatz
Du möchtest von der Community gepflegte Tools nutzen, ohne Code in dein Projekt zu kopieren.
Wann MCP übertrieben ist
Für viele Anwendungsfälle fügt MCP unnötige Komplexität hinzu.
Einsprachige Projekte
Wenn deine Tools und dein Agent in derselben Sprache sind, sind Inline-Funktionen einfacher und schneller.
Einfache Agenten
Ein Chatbot mit wenigen Tools braucht nicht den Overhead, separate Server-Prozesse auszuführen.
Schnelles Prototyping
Bei schneller Iteration verlangsamt die Indirektion von MCP die Entwicklung.
Latenz-kritische Apps
Entfernte Transporte verursachen Netzwerklatenz, lokales stdio Prozess- und Serialisierungsaufwand. Miss den vollständigen Toolpfad vor der Integrationsentscheidung.
Die drei Kernbausteine
MCP-Server können drei Arten von Fähigkeiten an Clients bereitstellen. Die meiste Dokumentation konzentriert sich auf Tools, aber Resources und Prompts sind ebenso wichtig.
Tools
Funktionen, die das Modell aufrufen kann, um Aktionen auszuführen. Tools werden vom LLM aufgerufen, um mit externen Systemen zu interagieren—Datenbanken abfragen, APIs aufrufen, Code ausführen.
query_database, send_email, create_fileResources
Daten, die der Server als Kontext bereitstellen kann. Resources sind schreibgeschützte Inhalte, die der Client abrufen kann—Dateien, Datenbankeinträge, API-Antworten—die die Antworten des Modells informieren.
file://config.json, db://users/123, api://weather/todayPrompts
Vordefinierte Prompt-Vorlagen, die der Server anbietet. Prompts sind wiederverwendbare Interaktionsmuster mit Parametern—wie "fasse dieses Dokument zusammen" oder "überprüfe diesen Code".
summarize_document, code_review, translate_textServer-Lebenszyklus
MCP-Verbindungen folgen einem strukturierten Lebenszyklus mit Fähigkeitsaushandlung beim Start.
Initialisieren
Client sendet Initialize-Anfrage mit Protokollversion und Client-Fähigkeiten. Dies ist immer die erste Nachricht.
Fähigkeitsaustausch
Server antwortet mit seinen unterstützten Fähigkeiten (Tools, Resources, Prompts) und Protokollversionsvereinbarung.
Initialisiert
Client sendet Initialized-Benachrichtigung, um zu bestätigen, dass die Einrichtung abgeschlossen ist. Normale Operationen können nun beginnen.
Betrieb
Client und Server nutzen Protokollmethoden wie tools/list, tools/call, resources/list, resources/read, prompts/list und prompts/get.
Beenden
Beide Seiten können die Verbindung schließen. Server sollten Ressourcen bereinigen (Datenbankverbindungen, Datei-Handles).
Echte MCP-Server
Das MCP-Ökosystem umfasst offizielle Referenz-Server und Community-erstellte Integrationen für beliebte Plattformen.
Dateisystem
Sichere Dateioperationen mit konfigurierbaren Zugriffskontrollen. Dateien innerhalb festgelegter Verzeichnisse lesen, schreiben und verwalten.
GitHub
Repository-Verwaltung, Issues, Pull Requests und Code-Suche. Erfordert einen persönlichen Zugriffstoken.
Slack
Kanal-Verwaltung, Messaging und Workspace-Interaktionen. Nachrichten posten, Verlauf lesen, Threads verwalten.
PostgreSQL
Datenbankabfragen mit Nur-Lesen- oder Lese-Schreib-Zugriff. SQL ausführen und Schema erkunden.
Memory
Wissensgraph-basierter persistenter Speicher. Strukturierte Informationen über Konversationen hinweg speichern und abrufen.
Git
Git-Repositories lesen, durchsuchen und manipulieren. Commits, Diffs, Branches und Historie anzeigen.
Beispiel einer Hostkonfiguration. Ersetze den Platzhalter durch einen Ordner, den du freigeben möchtest. Der Dateisystemserver kann erlaubte Dateien ändern; prüfe Paket und Hostberechtigungen vor der Aktivierung.
Konfigurationsbeispiel
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/path/to/approved-folder"
]
}
}
}Wie MCP funktioniert
MCP definiert eine Client-Server-Architektur, bei der der Agent der Client ist und Tools von Servern bereitgestellt werden.
Entdeckung
Der Agent verbindet sich mit einem MCP-Server und erhält eine Liste der verfügbaren Tools mit ihren Schemas.
Aufruf
Wenn das LLM entscheidet, ein Tool zu verwenden, sendet der Agent eine Anfrage an den MCP-Server.
Ausführung
Der MCP-Server führt das Tool aus und gibt Ergebnisse in einem standardisierten Format zurück.
Integration
Ergebnisse fließen zurück zum Agenten und in den LLM-Kontext, genau wie reguläre Tool-Ergebnisse.
Praktische Ratschläge
Richtlinien für die Entscheidung, ob du MCP in deinem Projekt verwenden solltest.
Beginne einfach: verwende Inline-Tool-Definitionen, bis du auf eine spezifische Einschränkung stößt.
Erwäge MCP, wenn du dich dabei ertappst, Tool-Code zwischen Projekten zu kopieren.
Schon eine nützliche Integration kann MCP rechtfertigen; vergleiche Wartungs- und Berechtigungsaufwand mit Alternativen.
Community-MCP-Server können die Entwicklung beschleunigen, fügen aber Abhängigkeitsrisiken hinzu.
MCP vs. CLI Tools
Viele Aufgaben, die MCP-Server übernehmen, lassen sich auch einfach über CLI-Tools (gh, git, curl, psql, etc.) aus der Shell des Agenten erledigen. So vergleichen sie sich.
MCP Server
// MCP: JSON-RPC: stdio / Streamable HTTP
{ "method": "tools/call",
"params": {
"name": "list_issues",
"arguments": { "repo": "org/app" }
} }- Strukturierte Protokollnachrichten; Toolinhalte müssen weiterhin geprüft und verarbeitet werden.
- Auffindbare Eingabeschemas; der Host muss Argumente weiterhin validieren.
- Persistente Verbindungen — zustandsbehaftete Sessions (z.B. DB-Connection-Pools)
CLI Tools (Shell Exec)
// CLI: shell exec
$ gh issue list --repo org/app
$ git log --oneline -10
$ curl -s api.example.com/data
$ psql -c "SELECT * FROM users"- Vorhandene Kommandozeilentools und deren Anmeldung wiederverwenden.
- Breites Angebot; die Verfügbarkeit hängt von der Ausführungsumgebung ab.
- Komponierbar — pipe, grep, jq, awk für komplexe Transformationen
Die pragmatische Einschätzung
Wähle nach Integrationsvertrag, Bereitstellung, vorhandenen Clients und Berechtigungsmodell. MCP standardisiert Erkennung und Transport; CLIs haben eigene Schnittstellen. Beide können lokal oder entfernt sowie eng oder weit berechtigt sein und brauchen geprüfte Ein- und Ausgaben.
Wichtige Erkenntnisse
- 1MCP ist ein Protokoll zur Bereitstellung von Tools über externe Server, kein Ersatz für reguläre Tool-Aufrufe
- 2Lokale Funktionen können für kleine Hosts einfacher sein; eine vorhandene MCP-Integration kann Implementierungsaufwand sparen.
- 3MCP glänzt in polyglotten Umgebungen und gemeinsamen Tool-Ökosystemen
- 4Greife nicht standardmäßig zu MCP—es ist eine Lösung für spezifische Skalierungs- und Interoperabilitäts-Herausforderungen
Transporte: stdio für lokale Unterprozesse und Streamable HTTP für entfernte Verbindungen. HTTP+SSE ist ein älterer Transport. Rechteumfang und Sandbox kommen vom Host und seiner Konfiguration, nicht von MCP selbst.