MCP: Warum Einfachheit keine Architektur ist

Das Model Context Protocol (MCP) wird oft als Wegbereiter „agentischer" KI dargestellt – als ein leichtgewichtiger Weg für Large Language Models, externe Tools oder Datenquellen aufzurufen. Das Versprechen klingt überzeugend: Standardisieren Sie, wie Modelle APIs entdecken und aufrufen, und schon haben Sie ein Ökosystem, in dem jeder Dienst zu einer KI-zugänglichen Fähigkeit werden kann. Doch unter dieser eleganten Erzählung liegt eine harte Wahrheit: MCP löst ein Problem des Entwicklerkomforts, nicht die Herausforderung der Enterprise-Integration. Seine Einfachheit ist nützlich – doch genau diese Einfachheit macht es als architektonisches Fundament im großen Maßstab ungeeignet.

Was MCP wirklich ist

MCP definiert im Kern, wie ein LLM-Client (der „Host") verfügbare Tools bekannt macht und wie das Modell deren Nutzung anfragt. Ein Tool wird durch Name, Funktion und ein minimales JSON-Schema für Ein- und Ausgaben beschrieben. Der Host führt den Aufruf aus und speist die Ergebnisse an das Modell zurück. Mehr nicht.

Es gibt keinen semantischen Vertrag, keine geteilte Ontologie, keine Durchsetzung von Versionierung oder Zugriffskontrolle. MCP ersetzt weder APIs noch Service Meshes noch Datenplattformen – es verpackt sie lediglich in eine Form, die ein LLM verstehen kann. Es eine Architektur zu nennen, ist, als würde man eine Telefonnummer als Kommunikationsstrategie bezeichnen.

Wo die Grenzen beginnen

MCP erbt die Fragilität seiner Grundlagen. Es nutzt JSON-Schema für Tool-Definitionen – ausdrucksstark genug für Demos, aber bei Weitem nicht ausreichend für stark typisierte oder sicherheitskritische Systeme. Es gibt keine native Versionierung, was bedeutet, dass eine Schema-Änderung abhängige Tools stillschweigend zerstören kann. Es gibt kein Distributed Tracing, keine Correlation IDs und kein Konzept durchgängiger Observability über Multi-Tool-Workflows hinweg.

Authentifizierung und Autorisierung sind nachträglich angeflanscht. Ein Modell kann einen Host anweisen, „delete database" auszuführen, wenn dieses Tool freigegeben ist – und sofern keine zusätzlichen Governance-Schichten existieren, wird es das tun. In kontrollierten Unternehmensumgebungen sind solche offenen Befehlspfade inakzeptabel.

Architektonische blinde Flecken

Aus Unternehmenssicht führen die Zustandslosigkeit des Protokolls und der fehlende Governance-Rahmen zu strukturellen Risiken:

• Keine Lifecycle-Kontrolle. Tool-Definitionen sind flüchtig und lassen sich weder auditieren noch zertifizieren.
• Keine semantische Stabilität. JSON-Verträge beschreiben Syntax, nicht Bedeutung – was zu inkonsistentem Verhalten über Domänen hinweg führt.
• Keine Policy-Propagierung. Datenhoheit, Zweckbindung oder regulatorische Geltungsbereiche (DSGVO, ISO 27001) sind für das LLM unsichtbar.
• Kein Performance-Modell. Das Protokoll bewegt JSON-Payloads, keine Queries; im großen Maßstab führt das zu massiven Ineffizienzen und Netzwerk-Overhead.

Die Folge: Organisationen, die versuchen, all ihre Systeme „MCP-fähig" zu machen, bauen faktisch ein fragiles API-Mesh nach – nur ohne die Reife, die Sicherheit und das Tooling, die die API-Welt über Jahrzehnte bereits entwickelt hat.

Was MCP dennoch gut kann

Innerhalb dieser Grenzen ist MCP wertvoll – als Integrations-Verrohrung. Es ermöglicht das schnelle Prototyping von LLM-Agenten, die über verfügbare Aktionen schlussfolgern, klar definierte Endpunkte aufrufen und einfache Abläufe zusammenfügen können. Für isolierte Anwendungsfälle wie kontrollierte Datenexploration, interne Tool-Orchestrierung oder Hybrid-Cloud-Proof-of-Concepts funktioniert es. Doch es braucht ein architektonisches Rückgrat, das MCP selbst nicht liefert: eine semantische Informationsschicht, die Entitäten, Beziehungen und geschäftliche Bedeutung definiert; ein Data-Governance-Modell, das durchsetzt, wer was tun darf; und eine Ausführungsschicht, die Authentifizierung, Auditing und Performance handhabt.

Ein besseres Muster für Unternehmen

Das nachhaltige Modell sieht anders aus. Bauen Sie einen Knowledge Layer, der in Unternehmens-Ontologien verankert ist und die realweltliche Semantik von Daten und Prozessen ausdrückt. Stellen Sie ausschließlich semantische Fähigkeiten – nicht rohe APIs – als aufrufbare Tools bereit. Nutzen Sie MCP (oder ein ähnliches Protokoll) lediglich als Fassade, um diese Fähigkeiten für das LLM zugänglich zu machen. Behalten Sie Identität, Nachvollziehbarkeit und Versionierung in Ihrer eigenen Infrastruktur. Kurz gesagt: Lassen Sie MCP der Konnektor sein, nicht die Architektur.

Fazit

MCP ist eine kluge Idee, geboren im Kontext des Generative-AI-Labors – kein Bauplan für Unternehmen. Es vereinfacht Experimente, ignoriert aber vier Jahrzehnte an Lehren über verteilte Systeme, Verträge und Governance. Unternehmen sollten es erkunden, sich aber nicht darauf verlassen. Echter Fortschritt entsteht, wenn semantische Modelle, gesteuerter Datenzugriff und ontologiegestütztes Reasoning den Kern bilden – und Protokolle wie MCP bleiben, was sie sind: eine leichtgewichtige Leitung zwischen Intelligenz und Fähigkeiten, nicht die Architektur selbst.