MCP (Model Context Protocol)

Intermediate

MCP verstehen: wann externe Tool-Server sinnvoll sind und wann sie übertrieben sind.

Zuletzt aktualisiert: 29. Jan. 2026

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_file

Resources

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/today

Prompts

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_text

Server-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.

01

Entdeckung

Der Agent verbindet sich mit einem MCP-Server und erhält eine Liste der verfügbaren Tools mit ihren Schemas.

02

Aufruf

Wenn das LLM entscheidet, ein Tool zu verwenden, sendet der Agent eine Anfrage an den MCP-Server.

03

Ausführung

Der MCP-Server führt das Tool aus und gibt Ergebnisse in einem standardisierten Format zurück.

04

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
MCP
CLI
Setup
Config + Server-Prozess
Bereits installiert
Latenz
Protokoll-Overhead
Direkte Ausführung (~ms)
Sicherheit
Sandboxed, granulare Berechtigungen
Voller Shell-Zugriff ⚠️
Ökosystem
~3K Server (wachsend)
~100K+ Tools (ausgereift)
Debugging
Inspector-Tools, Logs
Einfach den Befehl ausführen

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