MCP Server
Was ist ein MCP Server?
Das Grundproblem: Jedes Large Language Model (LLM) braucht Zugriff auf externe Systeme — Datenbanken, APIs, Dateisysteme, interne Tools. Bisher bedeutete das: für jede Kombination aus Modell und Tool eine eigene Integration bauen. Das klassische N×M-Integrationsproblem. Das Model Context Protocol (MCP) löst es durch eine universelle Client-Server-Schnittstelle auf Basis von JSON-RPC 2.0, inspiriert vom Language Server Protocol (LSP) aus der IDE-Entwicklung. Ein MCP Server ist dabei die Serverseite dieser Architektur: eine Softwarekomponente, die spezifische Fähigkeiten oder Datenquellen — etwa Datenbankabfragen, Dokumentabruf oder API-Calls — kontrolliert für KI-Agenten freigibt. Der MCP Host (z. B. Claude Desktop oder VS Code) verbindet sich zur Laufzeit mit einem oder mehreren solcher Server, entdeckt deren Fähigkeiten dynamisch und koordiniert den Datenaustausch. Granulares Zugriffsmanagement und Auditierbarkeit sind dabei keine nachträglichen Features, sondern Teil des Protokolldesigns.
Wie funktioniert ein MCP Server?
Die Kommunikation läuft vollständig über JSON-RPC 2.0: Der Host sendet strukturierte Anfragen, der Server antwortet mit definierten Schemata. Ein zentrales Konzept ist die dynamische Tool-Discovery — der MCP Server exponiert beim Verbindungsaufbau seine verfügbaren Tools samt Parameterbeschreibungen als maschinenlesbare Schemata. Das Modell weiß so zur Laufzeit, welche Operationen es aufrufen darf, ohne dass diese fest ins Prompt oder den Code kodiert sein müssen. Neben Tools unterstützt das Protokoll auch Resources (strukturierte Datenquellen) und Prompts (vordefinierte Interaktionsmuster). Der Transport ist flexibel: lokal über stdio oder netzwerkseitig über HTTP mit Server-Sent Events (SSE). Authentifizierung ist protokollseitig bewusst ausgespart — die Verantwortung liegt beim Server-Implementierer, was Flexibilität schafft, aber auch Governance-Disziplin erfordert. SDKs existieren für Python, TypeScript, C# und Java.
MCP Server in der Praxis
GitHub setzt MCP konkret ein: Der Copilot-MCP-Server exponiert 43 Tool-Schemas — von Repository-Suche bis Pull-Request-Management — und erlaubt es KI-Agenten, direkt mit der GitHub-Plattform zu interagieren. Das erzeugt allerdings auch ein messbares Problem: Da bei jedem Aufruf alle 43 Schemas übertragen werden, entstehen erhebliche Token-Kosten, bekannt als Schema-Bloat. Ein zweites Praxisbeispiel kommt aus dem Security-Bereich: Der Kali-MCP-Server verbindet LLMs mit Kali-Linux-Tools und ermöglicht agentische Workflows für Port-Scans oder CVE-Analysen — ein Use Case, der die Skalierbarkeit des Protokolls jenseits klassischer Business-Integrationen zeigt. In Enterprise-Umgebungen laufen MCP Server zunehmend als Middleware zwischen AI-Agenten-Orchestratoren und bestehenden Unternehmenssystemen wie CRMs oder internen Wissensdatenbanken.
Vorteile und Grenzen
Der stärkste Vorteil von MCP Servern ist die Standardisierung: Ein einmal gebauter Server funktioniert mit jedem kompatiblen Host — egal ob Claude, ein OpenAI-Agent oder ein Custom-Framework. Das reduziert Integrationsaufwand massiv und macht Tool-Ökosysteme portabel. Die dynamische Tool-Discovery erlaubt flexible, zur Laufzeit zusammengestellte Agenten-Workflows. Die Grenzen sind jedoch real: Schema-Bloat bei tool-reichen Servern treibt Token-Kosten in die Höhe — GitHubs 43-Tool-Server ist hier ein warnendes Beispiel. Das Protokoll ist zudem authentifizierungsagnostisch, was in Multi-Tenant-Szenarien ernsthafte Governance-Arbeit auf Implementierungsseite verlagert. Und weil MCP noch jung ist, fehlen etablierte Patterns für Versionierung, Fehlerbehandlung unter Last und Schema-Kompression — Lücken, die die Community gerade aktiv schließt.