MCP Server: Das neue USB — mehr oder weniger

Erinnerst du dich, als USB kam und still und leise ein Jahrzehnt Peripherie-Chaos beendete? Vor USB bedeutete das Anschließen eines Druckers: IRQ-Konflikte, Parallel-Port-Treiber und ein stilles Gebet. USB sagte: ein Port, ein Standard, das Gerät erklärt sich selbst, der Host kümmert sich um den Rest. Kein Zauber — ein gut durchdachtes Protokoll, das die kombinatorische Explosion aus Gerät-Host-Paaren beherrschbar machte.

MCP (Model Context Protocol, von Anthropic Ende 2024 veröffentlicht) setzt eine ähnliche Wette für AI-Systeme. Ein Protokoll, strukturierte Tool-Deklarationen, typisierte Inputs und Outputs — damit ein AI-Client sich mit jedem MCP-kompatiblen Dienst verbinden kann, ohne für jedes Paar eigenen Glue-Code zu schreiben.

Das ist eine wirklich interessante architektonische Idee. Sie wird aber auch so übertrieben verkauft, dass unklar wird, wo MCP tatsächlich hilft und wo nicht.

Dieser Beitrag versucht, das auseinanderzuhalten. MCP ist kein Allheilmittel. Für viele Entwickler-Workflows ist ein gut gestaltetes CLI nach wie vor die richtige Antwort. Aber für einen spezifischen und zunehmend wichtigen Anwendungsfall — autonom operierende AI Agents — ist MCP die richtige Interface-Schicht. Und wer 2026 Software evaluiert, für den wird die Frage, ob ein Produkt einen MCP Server mitliefert, zu einem aussagekräftigen Signal über das architektonische Denken dahinter.

Schauen wir uns das genauer an.

Was MCP eigentlich ist

Model Context Protocol ist ein offener Standard, der definiert, wie AI-Clients (Claude Desktop, VS Code mit GitHub Copilot, eigene Agent-Frameworks) sich mit externen Tools und Datenquellen verbinden. Ein MCP Server stellt eine Menge von Tools bereit — jedes mit Name, Beschreibung, typisiertem Input-Schema und typisiertem Output — die ein AI-Client entdecken und aufrufen kann.

Der Client fragt: „Was kannst du?“ Der Server antwortet mit einem Manifest seiner Fähigkeiten. Der Client entscheidet dann, welche Tools er aufruft, übergibt strukturierte Argumente und erhält strukturierte Antworten. Fehler sind typisiert. Fähigkeiten sind introspektierbar. Die gesamte Interaktion ist darauf ausgelegt, von einer Maschine konsumiert zu werden, nicht von einem Menschen gelesen.

Anthropic hat die Spezifikation veröffentlicht, aber sie ist nicht proprietär — es ist ein offenes Protokoll, und die Adoption war schnell. Claude Desktop, VS Codes Copilot-Integration, Cursor und eine wachsende Zahl von Agent-Frameworks unterstützen MCP als Client. Das Server-Ökosystem wächst genauso schnell: Dateisysteme, Datenbanken, GitHub, Slack und Hunderte von Drittanbieter-Diensten liefern inzwischen MCP Server aus.

Die USB-Analogie — und wo sie trägt

Der USB-Vergleich ist nützlich, weil er das kombinatorische Problem einfängt, das MCP löst.

Vor USB bedeuteten N Geräte und M Hosts potenziell N×M individuelle Treiber-Implementierungen. USB reduzierte das auf N Gerätetreiber und M Host-Treiber — eine gemeinsame Protokollschicht in der Mitte. Der Vorteil wächst mit dem Ökosystem.

MCP macht dasselbe für AI-Integrationen. Ohne einen solchen Standard erforderte das Verbinden von Claude mit der internen Wissensdatenbank, den GitHub-Repos und dem CRM drei separate Custom-Integrationen — jede mit eigenem Auth-Flow, eigenem Error-Handling und eigenem Wartungsaufwand. Mit MCP baut man einen Server pro Dienst. Jeder MCP-kompatible AI-Client bekommt automatisch Zugriff.

Dieser Compounding-Effekt ist real. Ein Unternehmen, das heute einen MCP Server für sein Produkt ausliefert, bekommt Integration mit Claude Desktop, VS Code Copilot und jedem anderen MCP-Client — ohne eine einzige zusätzliche Zeile Integrationscode für jeden einzelnen schreiben zu müssen. Je größer das Client-Ökosystem wird, desto wertvoller wird dieser Server.

Die Analogie hat ihre Grenzen. USB ist ein physischer Standard mit harten Hardware-Constraints. MCP ist ein Software-Protokoll, und Software-Protokolle driften, forken und werden abgelöst. Die Spezifikation ist jung. Es wird Versionierungsschmerzen geben. Aber die architektonische Kernerkenntnis — eine gemeinsame Protokollschicht, die Clients von Servern entkoppelt — ist solide. Dieselbe Erkenntnis hat USB zum Erfolg gemacht.

Aber zuerst: CLIs verschwinden nicht

Bevor wir weitermachen, sollten wir ehrlich über etwas sein, das der MCP-Hype gerne übersieht: Für eine große Klasse von Entwickler-Workflows ist ein gut gestaltetes CLI schlicht besser als ein MCP Server.

CLIs lassen sich komponieren. Man piped Output von einem Befehl in den nächsten, leitet in Dateien um, verkettet mit &&, plant mit cron, führt in CI/CD-Pipelines aus. Sie brauchen keinen laufenden Server-Prozess, kein Port-Management, keine Auth-Token-Rotation. Sie sind mit Standard-Unix-Tools debuggbar — strace, grep, jq. Ein Shell-Skript, das ein CLI aufruft, ist oft robuster und wartbarer als ein äquivalenter MCP-basierter Workflow.

Die Unix-Philosophie — kleine Tools, die eine Sache gut machen, komponierbar über Standard-Interfaces — hat fünfzig Jahre überlebt, weil sie funktioniert. Wer als Entwickler eine Deployment-Pipeline automatisiert, Log-Dateien verarbeitet oder Batch-Operationen ausführt, findet in CLI plus shell-aufrufendem LLM oft die einfachere und besser nachvollziehbare Lösung. Man kann die Befühle lesen. Man kann sie wiederholen. Man kann sie versionieren.

Es gibt auch einen praktischen Punkt zu LLMs und Shell: Modelle wie Claude und GPT-4 sind ausgesprochen gut darin, Shell-Skripte zu schreiben. Gib ihnen ein gut dokumentiertes CLI, und sie produzieren korrekte, komponierbare Automatisierung. Dafür braucht man kein MCP.

Also: Niemand sollte behaupten, MCP mache CLIs obsolet. Sie bedienen unterschiedliche Anwendungsfälle, und für entwicklerbetriebene Automatisierung gewinnt das CLI oft durch Einfachheit und Debuggbarkeit. Die interessante Frage ist, was sich ändert, wenn der Operator kein Entwickler ist.

Wann MCP gewinnt: Der Client macht den Unterschied

Der Paradigmenwechsel, den MCP ermöglicht, betrifft nicht die Tools — sondern wer sie konsumiert.

Wenn ein menschlicher Entwickler ein CLI ausführt, bringt er enormen impliziten Kontext mit. Er versteht, was der Output bedeutet. Er bemerkt, wenn etwas falsch aussieht. Er erholt sich von Fehlern, indem er die Meldung liest, die Docs prüft, den Befehl anpasst. Er operiert in einer Feedback-Schleife mit dem System.

Wenn ein AI Agent der Client ist — autonom laufend, Dutzende von Tool-Aufrufen verkettend, ohne menschliche Aufsicht in der Schleife — verschwindet dieser implizite Kontext. Der Agent braucht ein Interface, das alles explizit macht, was der Mensch inferiert hätte.

Genau hier zahlen sich MCPs Design-Entscheidungen aus. Tools deklarieren ihre Fähigkeiten in maschinenlesbarer Form. Input-Schemas sind typisiert, sodass der Agent genau weiß, welche Argumente er übergeben muss. Output-Schemas sind strukturiert, sodass der Agent Ergebnisse parsen kann, ohne das Format zu erraten. Fehler sind typisiert und beschreibend, sodass der Agent Fehlermodi programmatisch behandeln kann, statt eine menschenlesbare Fehlermeldung zu parsen.

Nehmen wir VS Code mit GitHub Copilot als MCP-Client. Wenn Copilot die Codebasis abfragen, einen PR prüfen oder eine Abhängigkeit nachschlagen muss, führt er keine ad-hoc-Shell-Befehle aus und hofft, dass der Output parsebar ist. Er ruft typisierte MCP-Tools auf, die strukturierte Daten zurückgeben. Der Agent kann diese Aufrufe zuverlässig verketten, weil der Interface-Vertrag explizit ist.

Dasselbe gilt für Claude Desktop, das sich mit einem Datenbank-MCP-Server verbindet, oder für einen autonomen Agent, der über einen MCP Server mit einem CRM interagiert. Der Agent muss das zugrundeliegende System nicht verstehen — er braucht ein klar definiertes Interface, das ihm sagt, was möglich ist und was jede Operation zurückgibt.

MCP ist das richtige Interface, wenn der Konsument ein AI Agent ist. CLIs sind das richtige Interface, wenn der Konsument ein menschlicher Entwickler ist. Das sind keine konkurrierenden Antworten — es sind Antworten auf unterschiedliche Fragen.

MCP als architektonische Wette

Einen MCP Server für ein Produkt bereitzustellen ist nicht nur ein Feature. Es ist ein architektonisches Statement darüber, wie man erwartet, dass die eigene Software konsumiert wird.

Die Wette lautet: AI Agents werden zu First-Class-Konsumenten von Software-Interfaces. Nicht nur KI-unterstützte Menschen, die ein GUI bedienen, sondern autonome Agents, die APIs aufrufen, Operationen verketten und Aufgaben ohne menschliche Aufsicht bei jedem Schritt abschließen. Wenn das stimmt — und die Entwicklung von Agent-Frameworks, Copilot-Integrationen und autonomen Workflow-Tools legt das nahe — dann wird Software, die keine maschinenlesbare Interface-Schicht bietet, zunehmend schwerer zu integrieren sein.

Man denke daran, was mit REST APIs und Mobile passiert ist. Unternehmen, die 2012 gut dokumentierte REST APIs hatten, konnten Mobile Apps, Drittanbieter-Integrationen und Partner-Ökosysteme unterstützen, ohne ihre Backends neu zu bauen. Unternehmen, die nur Web-UIs hatten, mussten hektisch nachrüsten. Die Interface-Schicht, in die sie investiert hatten, wuchs im Wert, als das Client-Ökosystem sich diversifizierte.

MCP ist diese Interface-Schicht für die AI-native Ära. Einmal bauen, und jeder AI-Client, der das Protokoll unterstützt, bekommt Zugriff auf den eigenen Dienst. Heute bedeutet das Claude Desktop und VS Code Copilot. In zwei Jahren könnten es ein Dutzend dominante Agent-Frameworks sein, von denen man heute noch nichts gehört hat. Die Investition verzinst sich.

Einige Plattformen sind dieser Kurve bereits voraus. Branchly etwa liefert MCP-Integration von Haus aus mit — AI Agents können die AI-Schicht einer Website damit direkt programmatisch abfragen, durchsuchen oder mit ihr interagieren, ohne Custom-Integrationsarbeit auf einer der beiden Seiten. Das ist die Art architektonischen Denkens, die eine Plattform in einer agent-getriebenen Welt komponierbar macht.

Die Alternative — zu warten, bis AI-Agent-Adoption unbestreitbar ist, bevor man in MCP-Unterstützung investiert — ist derselbe Fehler, den Unternehmen beim Warten auf REST APIs oder auf Mobile-Responsive-Design gemacht haben. Wenn es offensichtlich ist, ist man bereits hinten.

Die Beschaffungsregel für 2026

Eine konkrete Empfehlung für alle, die dieses Jahr Software evaluieren.

2026 sollten Unternehmen, die neue Software evaluieren, MCP-Unterstützung — oder zumindest eine dokumentierte, AI-zugängliche API mit OpenAPI-Spec — als Baseline-Beschaffungskriterium behandeln. So wie man nach DSGVO-Konformität, SSO-Unterstützung oder Audit-Logging fragt. Kein Nice-to-have. Eine Baseline.

Die Frage an Anbieter ist einfach: „Wie interagiert ein AI Agent mit eurem Produkt?“ Wenn die Antwort „gar nicht“ oder „per Screen-Scraping“ oder „wir denken darüber nach“ lautet, ist das ein Signal. Nicht unbedingt ein Ausschlusskriterium für jeden Anwendungsfall, aber ein Signal dafür, wie der Anbieter über die Richtung der Branche denkt.

Software ohne AI-native Interfaces fehlt nicht nur ein Feature. Sie setzt eine architektonische Wette gegen die Richtung, in die sich der Markt bewegt. Diese Wette könnte aufgehen — Standards scheitern, Protokolle werden abgelöst, AI-Agent-Adoption könnte sich einpendeln. Aber die Asymmetrie ist ungünstig. Die Kosten für MCP-Unterstützung sind niedrig. Die Kosten, aus einem agent-getriebenen Integrations-Ökosystem ausgesperrt zu sein, sind hoch.

Die Frage stellen. Die Antwort gewichten.

Was das bedeutet, wenn man Software baut

Wer ein Produkt oder eine interne Plattform baut, für den ist die praktische Konsequenz klar: einen MCP Server neben den bestehenden Interfaces ausliefern, nicht statt ihnen.

Das CLI behalten. Die REST API behalten. Die Webhooks behalten. Sie bedienen echte Anwendungsfälle und echte Nutzer. Einen MCP Server als Interface-Schicht für AI-Clients hinzufügen. Der Implementierungsaufwand ist geringer als erwartet — das MCP SDK übernimmt die Protokoll-Mechanik, und wer bereits eine gut strukturierte API hat, muss sie für MCP-Tools hauptsächlich mit guten Tool-Beschreibungen und Schemas versehen.

Die Tool-Beschreibungen sind wichtiger, als die meisten Entwickler erwarten. Ein AI Agent entscheidet, welche Tools er aufruft, anhand der Beschreibung, nicht der Implementierung. Sie so schreiben, wie man Dokumentation für einen Junior-Entwickler schreiben würde, der nicht nur verstehen muss, was das Tool tut, sondern wann man es einsetzt und was man zurückbekommt. Diese Investition in Klarheit zahlt sich in Agent-Zuverlässigkeit aus.

Wer eine interne Plattform für eine größere Organisation baut, macht seine Integrationen mit MCP-Unterstützung zukunftssicher — unabhängig davon, welches AI-Tooling die Organisation künftig einsetzt. Man wettet nicht auf einen bestimmten AI-Anbieter, sondern auf die Protokollschicht. Das ist die deutlich sicherere Wette.

Fazit

MCP ist nicht das neue USB im Sinne von unvermeidlich, universell oder alternativlos. Es ist ein junges Protokoll von einem einzelnen Anbieter, und die Geschichte der Software-Standards ist voll von gut durchdachten Protokollen, die sich nicht durchgesetzt haben.

Aber das architektonische Problem, das MCP löst, ist real und wird nicht verschwinden. AI Agents brauchen strukturierte, introspektierbare Interfaces. Die kombinatorische Explosion aus Client-Service-Paaren braucht eine gemeinsame Protokollschicht. Irgendetwas wird diese Rolle übernehmen — MCP ist derzeit der beste Kandidat, und es hat spürbaren Adoptions-Schwung.

Für Entwickler: CLIs behalten. Sie verschwinden nicht, und für menschenbetriebene Automatisierung sind sie oft das richtige Werkzeug. Aber die eigene MCP-Geschichte für den Agent-Anwendungsfall durchdenken.

Für technische Entscheider: Anfangen, Anbieter nach AI-native Interfaces zu fragen. Es zum Beschaffungskriterium machen. Die Anbieter mit einer guten Antwort sind die, die klar darüber nachdenken, wohin sich Software-Architektur entwickelt.

Für alle, die 2026 Software bauen: Die Interface-Schicht, in die man jetzt investiert, ist die, die sich verzinst. Für die Clients bauen, die kommen — nicht nur für die, die schon da sind.