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
Reguläre Tool-Aufrufe sind Funktionen, die direkt in der Codebasis deines Agenten definiert sind. Der Agent ruft sie auf, sie werden ausgeführt und die Ergebnisse kehren im selben Prozess zurück. MCP trennt dies: Tools leben in externen Servern, mit denen der Agent über ein Protokoll kommuniziert.
Reguläre Tool-Aufrufe
Tools, die inline in deinem Agenten-Code definiert sind. Einfach, schnell und für die meisten Anwendungsfälle ausreichend.
const tools = {
get_weather: (location) => {
return fetchWeather(location)
}
}
// Direct function call
result = tools.get_weather("Tokyo")MCP-Server
Tools, die von externen Server-Prozessen bereitgestellt werden. Fügt Netzwerk-Overhead hinzu, ermöglicht aber sprachübergreifendes Tooling und gemeinsame Tool-Ökosysteme.
// 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
Netzwerkaufrufe zu Tool-Servern fügen Latenz hinzu, die Inline-Funktionen nicht haben.
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 tauschen Anfragen aus: list_tools, call_tool, list_resources, read_resource, list_prompts, get_prompt.
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.
Konfigurationsbeispiel
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/files"]
}{,
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "..." }
}
}
}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.
Der Overhead, MCP-Server auszuführen, macht nur in großem Maßstab oder in Enterprise-Umgebungen Sinn.
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 over stdio/SSE
{ "method": "tools/call",
"params": {
"name": "list_issues",
"arguments": { "repo": "org/app" }
} }- Strukturierter JSON Input/Output — kein Parsing nötig
- Typisierte Schemas mit Validierung — LLM kennt exakte Parameter
- 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"- Null Setup — wenn das CLI existiert, funktioniert es sofort
- Riesiges Ökosystem — tausende Tools auf jedem System bereits installiert
- Komponierbar — pipe, grep, jq, awk für komplexe Transformationen
Die pragmatische Einschätzung
CLI-Tools sind der pragmatische Standard: Sie sind überall vorhanden, Agenten können sie sofort nutzen, und die Unix-Philosophie komponierbarer Befehle passt überraschend gut zu LLMs. MCP glänzt, wenn man strukturierte Schemas braucht (weniger halluzinierte Argumente), persistenten State (DB-Verbindungen) oder plattformübergreifende Portabilität. In der Praxis nutzen die besten Agenten beides: CLI für schnelle System-Tasks, MCP für komplexe Integrationen, die von Type Safety profitieren.
Wichtige Erkenntnisse
- 1MCP ist ein Protokoll zur Bereitstellung von Tools über externe Server, kein Ersatz für reguläre Tool-Aufrufe
- 2Für die meisten Einzelprojekt-Agenten sind Inline-Tools einfacher und haben geringere Latenz
- 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