MCP: Ein (versehentlich) universelles Plugin-System

• USB-C ist nicht nur zum Laden oder für Dateiübertragungen da, sondern liegt sein Wert in seiner Universalität, da es sich für viele verschiedene Zwecke erweitern lässt
• MCP (Model Context Protocol) wurde ursprünglich für AI-Assistenten entworfen, kann in der Praxis aber zu einem universellen Plugin-System werden, das alle Datenquellen und Tools verbindet
• Wie das Beispiel NFT Base64 zeigt, können sich Protokolle über ihren ursprünglichen Zweck hinaus erweitern, indem sie reale Daten direkt speichern und nutzen
• Je mehr MCP-Server es gibt, desto einfacher können einzelne Apps vielfältige Funktionen übernehmen, ohne für jede Integration eine eigene Anbindung zu bauen
• Wie USB-C kann auch MCP zu einem „Möglichkeitsraum, in dem sich alles verbinden lässt“ werden und die Grundlage für unerwartete Innovationen schaffen

---

MCP: An (Accidentally) Universal Plugin System (Or: The Day My Toaster Started Taking Phone Calls)

USB-C und unerwartete Universalität

• Alle gingen davon aus, dass USB-C für Laden oder Dateiübertragung gedacht sei, doch seine Struktur erlaubt die Erweiterung auf viele verschiedene Einsatzzwecke
• Der Fall des Freundes des Autors, Rex, der einen Toaster an einen Monitor anschloss und dem Toaster damit HDMI-Ausgabe verlieh, zeigt das grenzenlose Potenzial von USB-C
• Das liegt daran, dass USB-C eine Struktur bietet, bei der man sich nicht um Strom- und Datenspezifikationen kümmern muss: Passt der Anschluss, kann grundsätzlich alles verbunden werden

Das Prinzip des Zigarettenanzünders im Auto

• Der Zigarettenanzünder im Auto war ursprünglich zum Anzünden von Zigaretten gedacht, wird heute aber als vielseitiger universeller Stromanschluss genutzt
• Wie beim Zigarettenanzünder schränkt ein Protokoll die Wahl der Nutzer nicht ein, sondern erlaubt verschiedene Verwendungsarten
• MCP besitzt eine ähnliche Erweiterbarkeit

Die Wiederentdeckung von MCP: zufällig ein universelles Plugin-System

• Üblicherweise gilt MCP (Model Context Protocol) als Mittel, mit dem AI-Assistenten wie etwa Claude Daten nutzen können
• Auch in der offiziellen Dokumentation heißt es, es verbinde „AI-Modelle standardisiert mit verschiedenen Datenquellen und Tools“
• Lässt man jedoch den AI-Bestandteil weg, wird MCP zu einem Mittel, um „beliebige Dinge“ mit unterschiedlichen Datenquellen und Tools zu verbinden
• Damit wird es unabhängig von seinem ursprünglichen Zweck zu einem universellen Verbindungsprotokoll

The NFT Base64 Revelation

• NFTs dienten ursprünglich dazu, auf Bilder zu verweisen, doch irgendwann wurde der Verweis selbst zu den Daten
• Während sich die eigentliche Absicht des Protokolls verschob, begann die Bibliothekskarte die Rolle des echten Buchs zu übernehmen
• So wandelte es sich zu einem Werkzeug, das reale Daten direkt verarbeitet und damit weit über die ursprüngliche Absicht hinausgeht

Ein Netzwerkeffekt, den niemand vorhergesehen hat

• Je mehr MCP-Server für AI entstehen, desto stärker tritt der Effekt auf, dass alle Apps ohne zusätzliche Entwicklung neue Funktionen erhalten können
• Wenn zum Beispiel jemand einen Spotify-MCP-Server baut, könnte eine Fitness-App über MCP automatisch Playlists erstellen
• So entsteht ein Netzwerkeffekt, bei dem sich Entwickler und Apps, die sich nicht kennen, ganz natürlich verbinden und alle davon profitieren
• Jeder MCP-Server kann als universelles Plugin wiederverwendet werden
• Ohne dass es irgendjemand geplant hätte, entsteht zufällig ein universelles Plugin-Ökosystem

Die Bedeutung von USB-C und die Philosophie von MCP

• MCP wird oft mit dem USB-C der AI verglichen, doch das Besondere an USB-C ist nicht einfach der Port, sondern der Möglichkeitsraum, in dem sich alles verbinden lässt
• So wie USB-C Strom, Daten, Video und weitere unbekannte Funktionen aufnehmen kann, ist auch MCP nicht bloß „für AI“, sondern ein „gut gestaltetes Loch für Funktionalität“, an das jeder beliebige Funktionen anschließen kann

The Part Where I Tell You I'm Building Something

• Der Autor entwickelt derzeit eine Task-Management-App namens APM (Actions Per Minute)
• APM funktioniert als Plugin-System ausschließlich über MCP-Server
• Immer wenn Nutzer eine gewünschte Funktion hinzufügen wollen, müssen sie nur einen MCP-Server anbinden, etwa für Rechtschreibprüfung, automatische Kaffee-Bestellung oder Reaktionen von Spielfiguren
• Dadurch kann sich die App selbst in eine flexible und sehr unterschiedliche Form verwandeln

The Toaster Protocol Principle

• Alle großartigen Protokolle schaffen Innovationen dadurch, dass sie entgegen ihrer ursprünglichen Absicht für unerwartete Zwecke genutzt werden
  • HTTP: für wissenschaftliche Aufsätze → Infrastruktur der Zivilisation
  • Bluetooth: Freisprechen → Haustüren entriegeln usw.
  • USB: Eingabegeräte → tragbare Ventilatoren laden usw.
• MCP dient zwar ursprünglich der Übergabe von AI-Kontext, ist seinem Wesen nach aber ein Protokoll, das alles mit allem verbindet
• Es wird als Grundlage eines Plugin-Ökosystems hervorgehoben, das unvorhersehbare Innovationen hervorbringt
• Auch wenn es nie so geplant war, passt es perfekt in eine Zeit, in der Toaster und Monitore per HDMI verbunden werden

Schluss

• PS: Falls jemand einen Computer baut, der über einen MCP-Server den Duft von frischem Brot erzeugt, soll er sich unbedingt melden
• PPS: Der Early Access von APM ist veröffentlicht, und originelle Versuche sowie kreative Experimente sind ausdrücklich erwünscht
• (Irgendwo da draußen wird ein Protokoll tatsächlich für seinen ursprünglichen Zweck verwendet. Das ist höchst verdächtig.)

[a1eng0]

Die Antworten eines MCP-Servers sind häufig natürliche Sprache ohne festgelegtes Schema.

Diese natürlichsprachigen Antworten ohne LLM programmatisch zu verarbeiten, dürfte schwierig sein.

[winterjung]

Zur Info: Mit der neu hinzugefügten structured tool output in der Spezifikation vom 2025-06-18 für MCP ist es möglich geworden, Antwort-Schemata zu beschreiben. Die bereits existierenden MCP-Tools sind, wie Sie sagten, größtenteils unstrukturiert, aber für künftige MCP-Tools darf man wohl einiges erwarten.

[a1eng0]

Winter, schön, Sie hier wiederzusehen, haha.

Ich hatte es nicht geschafft, die Spezifikation vom 18.06.25 weiterzuverfolgen. Vielen Dank!

[GN⁺]

Hacker-News-Kommentare

• Ich denke, dass mir dieser Artikel und das MCP-Protokoll wirklich gefallen. Aber bei MCP muss ich irgendwie an Microservices und SOA denken. Ich frage mich, ob sich damit nicht der Albtraum wiederholt, neue Fehlerstellen zu schaffen. Andererseits gibt es auch die Erwartung, dass durch die Einführung von Agenten Zuverlässigkeitsverbesserungen natürlicher erreicht werden könnten

• Ich stimme den Gedanken des Artikels zu, und ich finde es sehr interessant, dass der Autor MCP auf eine etwas zweckentfremdete Weise nutzt. Der eigentliche Kern dieses Denkansatzes ist nicht das Erscheinen eines Protokolls, das völlig neue Dinge ermöglicht. Wie andere Kommentare schon sagen, ist MCP an sich weder besonders neu noch besonders interessant. Wirklich spannend ist, dass durch den Boom der AI-Agenten Interoperabilität in den Fokus rückt und Vendor Lock-in als überholt betrachtet wird. Wie lange das anhält, weiß ich nicht, aber im Moment fühlt sich das gut an

  • Das erinnert mich an die Einführung von Winsock. Unter Windows nutzte früher praktisch jede netzwerkbezogene Software ihre eigene proprietäre Schnittstelle. Dann gab es wohl irgendwann den Moment, in dem mehrere Vendoren zusammenkamen und beschlossen, einen gemeinsamen Standard zu schaffen, der allen nützt. Siehe Winsock auf Wikipedia
  • Der Kernpunkt ist nicht bloß, dass Interoperabilität gerade im Trend ist oder dass sich Dinge leicht verbinden lassen. Die eigentliche Innovation ist, dass LLMs gelernt haben, mit Tools umzugehen. Wenn ich nur noch das Backend bauen muss, ist das Frontend nicht mehr mein Problem und die AI kümmert sich darum. Claude und Gemini können ebenfalls selbstständig Tools einsetzen, wenn man ihnen nur das Ziel vorgibt. Früher musste man immer Schritt für Schritt klar ausformulieren, wie man zum gewünschten Ergebnis kommt, aber jetzt passen sich LLMs an dynamische Situationen viel besser an als starre Programme — das ist ein gewaltiger Wandel
  • Die Erwartungen wirken überzogen. Aber aus meiner Sicht haben AI-Agenten definitiv einen Anreiz für Interoperabilität geschaffen. Früher war es für alle eine stabile Jobgarantie, in ihren eigenen Systemen langsam vor sich hin zu arbeiten, aber jetzt will plötzlich jeder alles miteinander verbinden. Es ist ein Wandel nach dem Motto: Selbst wenn der CEO beim Hackathon persönlich Pizza holen geht, ist das immer noch billiger. Agenten sind auf Integrationen angewiesen. Als jemand, der die frühere Welle der API-Integrationsinnovation direkt miterlebt hat, habe ich das Gefühl, dass die Welt erst jetzt aufholt. Hoffentlich hält diese Stimmung lange an
  • Der Hinweis, dass der AI-Agenten-Boom den Interoperabilitätstrend antreibt und Vendor Lock-in altmodisch macht, überzeugt mich nicht ganz. Selbst derzeit gehypte Tools wie Cursor nutzen MCP nur unidirektional und geben weder Gesprächsverläufe noch Kontext nach außen weiter. Ich mag Cursor, aber schon der Umstand, dass es ein nicht Open-Source VS-Code-Fork ist, und diese Haltung des „Nichts zurückgeben“ werden dem Vertrauen der Entwickler eher schaden. Am Ende bleibt Lock-in weiterhin sehr real
  • Ironischerweise sind die jüngsten Einschränkungen beim API-Zugang wegen AI-Trainingsdaten sogar noch härter geworden. Solche API-Lockdowns gab es zwar schon lange vorher, aber man kann auch skeptisch sein, dass sich alles schnell wieder schließt, wenn der neue Offenheitstrend die überhitzten Erwartungen nicht erfüllt

• Der Autor setzt große Hoffnungen auf die Allgemeingültigkeit von MCP, aber ehrlich gesagt frage ich mich, was das eigentlich vom Konzept einer API unterscheidet. Würde sich der Inhalt des Artikels stark ändern, wenn man MCP einfach durch REST ersetzt? Es gibt auch Ähnlichkeiten zu Betriebssystem-APIs, POSIX oder Unix-Pipes. Sicher, MCP ist deutlich einfacher und allgemeiner als all diese Dinge. Aber ist die eigentliche Lösung nicht eher, sich auf die Grundlagen zu besinnen und einfache Software zu bauen, statt ständig neue Abstraktionen zu schaffen?

  • MCP ist nicht dasselbe wie REST. Eher fühlt es sich so an, als wäre MCP ein Protokoll, das es erlaubt, REST-Endpunkte zur Laufzeit dynamisch zu entdecken und vom Nutzer konfigurieren zu lassen, welche REST-Endpunkte verwendet werden sollen. Wenn eine App zum Beispiel Songs auf Spotify abspielen soll, nutzt sie natürlich die Spotify-API. Wenn man später auch Titel von Sonofm unterstützen will, müsste man klassisch Code ändern, Bedingungen ergänzen, eine neue Version ausrollen und Updates ankündigen. Mit MCP kann man das zur Laufzeit konfigurieren, was deutlich skalierbarer wirkt
  • Der entscheidende Unterschied ist, dass MCP Selbstbeschreibung von Anfang an verpflichtend macht. Bei REST gibt es zwar OpenAPI, aber das wurde nachträglich aufgesetzt und wird auch nicht besonders konsequent standardisiert genutzt. MCP verlangt dagegen zuerst die Offenlegung der Beschreibung, und das verändert die Zugänglichkeit
  • Für mich wirkt MCP eigentlich nur in einem Punkt wirklich neu: Es macht die Bereitstellung eines Schemas auf Protokollebene verpflichtend. Natürlich ist eine konsistente Struktur von Requests und Responses auch für Libraries hilfreich, die dynamische Typen mit statischen Typen kapseln. Im Grunde haben alle bei APIs schon etwas sehr Ähnliches gemacht. Wir hatten uns nur nie auf diese Envelope-Form geeinigt. Gerade weil Schema-Bereitstellung Pflicht ist und AI-Modelle das sofort nutzen können, bekommt es jetzt so viel Aufmerksamkeit
  • Ein großer Unterschied zwischen MCP und REST ist das eingebaute Kommando list-tools. REST-APIs haben viele Wege, Ressourcen aufzulisten, aber MCP bietet dafür genau eine standardisierte Methode
  • Ein weiterer großer Unterschied ist, dass MCP Discovery direkt in das Protokoll eingebaut hat. Bei REST gibt es überhaupt keinen Mechanismus, der dem Client mitteilt, welche Ressourcen möglich sind oder welche API-Funktionen es überhaupt gibt

• Viele sagen, MCP sei großartig, aber ich habe noch nicht viele Beispiele gesehen, in denen wirklich etwas Beeindruckendes damit gebaut wurde. Es fühlt sich ein wenig an wie beim Blockchain-Hype. Am Ende ist MCP vielleicht nur eine Zwischenlösung, bis AI intelligenter wird. In zwei Jahren könnte sich das ganz natürlich dahin entwickeln, dass man statt MCP einfach die Dokumentation eines Tools oder OpenAPI direkt hineingibt und die AI den gesamten Kontext selbst verarbeitet

  • Zum Beispiel frage ich mich, wie es Claude helfen soll, direkt Musik zu machen, wenn man ihm bloß die Dokumentation von Ableton Live gibt
  • Egal wie gut Modelle werden: Ohne deterministischen Tool-Zugriff und direkte Informationen über den Zustand der Welt bleibt ihr Nutzen stark begrenzt. Und auch aus Sicherheitsgründen kann man ein Modell in Produktion nicht unkontrolliert beliebige Requests absetzen lassen. Der Hype um MCP ist aus meiner Sicht etwas überzogen, aber das hier beschriebene Problem ist trotzdem real und wichtig. Wenn dieses Protokoll Entwickler dazu bringt, Funktionen klar als API zu öffnen, wäre das eine sehr erfreuliche Entwicklung
  • Der Blockchain-Hype und MCP sind ziemlich unterschiedliche Dinge. Ich war anfangs auch skeptisch, aber wenn man selbst einmal einen kleinen MCP-Server implementiert, merkt man, dass es etwas ganz anderes ist. Wenn man dialogbasierte/sprachbasierte AI und aktuelle LLMs mit MCP sowie verschiedensten Tools und Funktionen mit APIs und privaten Daten/Services kombiniert, fühlt es sich an, als betrete man ein völlig neues Frontier. Es ist nicht zu 100 % perfekt, aber für fast alle praktischen Anwendungsfälle schon gut genug, und wahrscheinlich wird sich dadurch die Art, wie Apps gebaut werden, stark verändern
  • Ich wollte zum Beispiel wissen, was die Abgeordneten meines Bundesstaats diese Woche gemacht haben, und es gab keinen einfachen Weg, die relevanten Informationen zu finden. Dann hörte ich, dass MCP mit der congress.gov-API attraktiv sei, und habe deshalb selbst einen MCP-Server gebaut. Hier ist der Code. Ich nutze ihn inzwischen tatsächlich sehr gut, um Entwicklungen im US-Kongress in Echtzeit nachzuschlagen
  • Solange sich AI-Modellarchitekturen weiterentwickeln, dürfte eine zwischengeschaltete Middleware-Schicht — also MCP — nicht so leicht verschwinden

• Ich denke, dass Microsoft hier wieder die Strategie „Embrace, Expand, Extinguish“ anwendet. Unter Verweis auf Systemstabilität und Sicherheit ist das Risiko von Konflikten groß, wenn Agenten ohne Verwaltung dynamisch Tools entdecken. Es gibt Alternativen wie PydanitcAI, aber letztlich hat Microsoft MCP auf der „Build 2025“ offiziell gepusht und führt die Branche damit im eigenen Tempo. Anthropic hat einen Standard mit schwachen Tools und ohne Governance vorgelegt, also ist das Terrain für Microsoft leicht zu besetzen. Der nächste Schritt wäre, dass Microsoft seine eigene Registry zum Industriestandard macht und mit Windows-spezifischen Befehlen verknüpft. Am Ende könnte Microsoft dann „Sicherheits“-Kriterien zu seinem Vorteil definieren und Konkurrenten verdrängen

• Was wäre, wenn man den AI-Aspekt komplett herausnimmt? Wenn man direkt von AI-Middleware unabhängig auf MCP-Server setzt, droht man sofort in Abwärtskompatibilitätsprobleme zu laufen. Denn MCP-Server gehen davon aus, dass aufrufende Seiten ein AI-Algorithmus sind, sodass es bei Tools oder Ein-/Ausgabe-Schemata jederzeit zu Breaking Changes kommen kann

• Ich habe ähnlich gedacht, aber inzwischen frage ich mich, ob die meisten MCP-Server nicht einfach nur neue Clients für bestehende APIs sind. Der Kagi-MCP-Server ruft zum Beispiel lediglich die Kagi-API auf. Wäre es dann nicht besser, die API direkt zu verwenden? Außerdem würde das System dann mit jedem MCP-Server um einen weiteren Python-Interpreter wachsen. Ich frage mich, ob es künftig nicht Hosting-Services geben wird, die all das bündeln und über eine einzige Bridge bereitstellen

  • So wie ich es verstehe, bedeutet MCP im Grunde nur, einer bestehenden API noch einen Endpunkt /list-tools hinzuzufügen. Jeder Client fragt zuerst /list-tools ab, holt sich die Liste verfügbarer Tools und ruft danach die jeweiligen APIs auf
  • Mein Ansatz wäre: Wenn es bereits eine API mit OpenAPI-Spezifikation gibt, warum sollte man sie nicht einfach mit FastMCP wrappen? Ich habe das tatsächlich mit Goose ausprobiert, inklusive Authentifizierungsanforderungen, und am Ende lief es darauf hinaus, dass Goose lediglich curl-Befehle auf bestehende API-Routen schickt. Wenn die OpenAPI-Spezifikation gut genug ist, braucht man MCP vielleicht gar nicht zwingend. Wenn es noch keine bestehende API gibt, scheint es allerdings in die Richtung zu gehen, dass der MCP-Server selbst die Kernfunktionalität implementiert

• In den Kommentaren gibt es viel Skepsis, und ich kann das nachvollziehen. Ich habe letzte Woche selbst einen MCP-Server implementiert, und ehrlich gesagt halte ich die Aussage, er sei „gut designt“, für übertrieben. Eines der Ziele von MCP ist zwar, dass es sich einfach umsetzen lassen soll, aber in der Praxis ist es gar nicht so leicht. Trotzdem ist entscheidend, dass sich gerade die Aufmerksamkeit unzähliger Entwickler auf einen Punkt bündelt. In so einem Momentum können Probleme sehr schnell gelöst werden. Außerdem braucht es eine kritische Masse, damit ein Ökosystem entsteht, und ich habe das Gefühl, dass dieser Wendepunkt jetzt tatsächlich erreicht wird. Ich wünsche allen Geduld und Glück

  • Wenn man nur die MCP-Python-Library nutzt, ist es wirklich einfach. Man muss einer Funktion nur einen Decorator geben, und schon ist ein Tool fertig. Ich kannte das MCP-Protokoll überhaupt nicht, aber auf diese Weise läuft es bei mir gut. Wenn man das Protokoll allerdings direkt selbst implementieren muss, könnte es natürlich anders aussehen
  • Ein MCP-Server muss letztlich nur „eine bestehende öffentliche oder halböffentliche API“ erneut verfügbar machen. Die Sichtweise, dass das mit minimalen Änderungen an den ursprünglichen Endpunkten möglich sein sollte, ist durchaus überzeugend
  • Solche Versuche gab es auch früher schon, aber nach ein paar Jahren sperren die Apps ihre Endpunkte wieder, sodass nur noch bestimmte Server wie chatgpt oder claude zugreifen dürfen. Interoperabilität ist letztlich auch Nutzerportabilität, und realistisch gesehen streben viele Tech-Unternehmen eher nach Lock-in und Monopolen als nach Portabilität

• Es wird betont, dass das Senken von Zugangshürden für die Einführung und Verbreitung von Technologien historisch immer eine wichtige Rolle gespielt hat. MCP steht in dieser Tradition und sollte nicht unterschätzt werden. Auch in unserem Team konnte jemand ohne jeden technischen Hintergrund selbst einen Agenten einsetzen, um Dateifreigaben zu automatisieren. Früher wäre so etwas nur mit Hunderten Programmiersprachen, Libraries und APIs möglich gewesen, aber dank MCP kann heute auch ein Nichtfachmensch so ein Problem direkt lösen, ohne sich darum kümmern zu müssen. In Bezug auf Performance ist das nicht die beste und auch nicht die optimalste Umsetzung, aber der Wert dieses neuen Ansatzes ist mit den heutigen Ressourcen und dem aktuellen technischen Stand beispiellos. Genau das ist der eigentliche Punkt

  • Ich halte die Geschichte, dass ein nicht technischer Teamkollege ganz allein die Ordnung bei Dateifreigaben hergestellt habe, für übertrieben. Wenn es nur um das Sortieren von ein paar Tausend Dateien ginge, vielleicht. Aber meiner Erfahrung nach scheitern fast alle Versuche, Dateifreigaben aufzuräumen, schon daran, überhaupt die Zusammenarbeit der zuständigen Abteilungen zu bekommen. Selbst die Fachverantwortlichen wollen es oft nicht, weil es nicht ihre Aufgabe ist. Man muss teils obere Führungskräfte einschalten, um Zustimmung zu erzwingen, oder sich mit Leuten zusammensetzen und eine Stunde lang allein an der Ordnerstruktur feilen. 50 % der Arbeit sind Abteilungspolitik, 20 % Prozessanpassung, 20 % Schulung, und nur 10 % sind technische Probleme. Ich habe große und kleine Katastrophen sowie endloses Chaos erlebt. Deshalb glaube ich nicht, dass die Realität plötzlich so einfach wird, nur weil AI-Tools sich leicht bauen lassen. Meine skeptische Prognose ist eher, dass in ein paar Monaten die Backup-Wiederherstellung ansteht

• Der Scherz „Ich wünschte, AI-Agenten würden in Warcraft 3 wie Peons Befehle annehmen und antworten“, worauf geantwortet wird, man würde lieber segeln gehen

  • Ich möchte nur anmerken, dass „I'd rather be sailing“ ein Spruch aus Warcraft 2 ist, während in Warcraft 3 die Antwort „I'd rather be flying“ lautet