Die Ankunft von Web 2.0 2.0: MCP

• Das Model Context Protocol (MCP) wird schnell übernommen und entwickelt sich zu einem neuen offenen Standard
• Der zentrale Wert von MCP liegt nicht in Perfektion, sondern in Offenheit und Interoperabilität
• Die eigentliche Bedeutung von Web 2.0 sind nicht geschlossene Plattformen, sondern offene APIs und Datenaustausch
• Es zeichnet sich eine Rückkehr aus dem früheren Zeitalter der Abschottung zu den Werten des offenen Webs ab
• Die Einführung von MCP könnte dazu führen, dass Entwickler Plattformkontrolle und Transparenz noch stärker einfordern

---

MCP: Das Entstehen eines neuen offenen Webs

In den vergangenen Monaten ist das Interesse unter Entwicklern am Model Context Protocol (MCP) explosionsartig gestiegen. Den Ausgangspunkt bildete Anthropic, das 2023 sein eigenes LLM-System (Claude) so entwarf, dass es mit verschiedenen Apps interagieren konnte. Danach unterstützte OpenAI dasselbe Protokoll in ChatGPT, wodurch es sich schnell als Standard etablierte. Inzwischen wird es auch von Windows übernommen und breitet sich damit auf wichtige Plattformen aus.

Interessant ist, dass die Stärke von MCP weniger in seiner Klarheit oder Vollständigkeit liegt als in seiner einfachen Nutzung und Geschwindigkeit. Anders als traditionelle, streng entworfene Standards ist MCP eine eher vage und locker definierte Spezifikation, deren großer Vorteil gerade darin besteht, dass sie in der Praxis gut funktioniert. Vor allem ist wichtig, dass es sich um ein offenes Protokoll handelt, das von allen genutzt werden kann.

Die wahre Bedeutung des offenen Webs

In der realen Webwelt entsteht echter Fortschritt dann, wenn unvollkommene und etwas lückenhafte Standards schnell übernommen werden. Aus genau solchen Entwicklungen sind Innovationen wie "Hören Sie überall dort, wo Sie Podcasts bekommen" entstanden.

Der Geist von Web 2.0 zielte auf ein offenes Ökosystem ab: offene APIs, Datenaustausch und mehr Kontrolle für Nutzer und Entwickler. Man sollte beachten, dass geschlossene Plattformen wie Facebook zu den Akteuren gehörten, die Web 2.0 zerstört haben. Früher prägten Flickr, del.icio.us, Upcoming und andere eine Kultur, die Teilen und Vernetzung in den Mittelpunkt stellte, und auf Plattformen wie Live-Blogs wurde lebhaft über offene Standards für APIs und Protokolle diskutiert.

Die Rückkehr des Offenen

Nach einer Generation steigen die Erwartungen an Interoperabilität erneut. In der Vergangenheit wiederholte sich immer wieder die Erfahrung, dass APIs durch die Abschottungspolitik großer Tech-Unternehmen blockiert wurden und Dienste verschwanden. So wurde etwa ein vom Autor aufgebautes Datenanalyse-Tool für soziale Netzwerke letztlich eingestellt, weil die Plattform die API sperrte. Solche Maßnahmen zerstörten die Vision von offenen Daten und Kompatibilität aus der Zeit von Web 2.0. Dadurch wurden Probleme wie nicht mehr einbettbare Inhalte und eingeschränkte Datenportabilität zum Alltag.

Mit dem Aufkommen von MCP gibt es jedoch die Erwartung, dass KI zum Auslöser für ein Wiedererstarken von Programmierbarkeit und Offenheit wird. Wenn mehrere Plattformen dasselbe Protokoll übernehmen, kann das einen positiven technologischen Kreislauf ermöglichen.

Wenn Plattformen das Protokoll so übernehmen, wie es ist, und die Standardisierung konsequent einhalten, entstehen positive Veränderungen für das gesamte Ökosystem. Es wird betont, dass der Entwicklerdrang, "es besser als den Standard machen zu wollen", paradoxerweise dem Ökosystem schaden kann. Auch HTML war keine perfekte Spezifikation, wurde aber letztlich zur Grundlage großflächiger Interoperabilität im Internet.

Die Bedeutung der Einhaltung von Standards

Eine neue Entwicklergeneration erlebt die Stärke von Innovation auf Basis derselben Protokolle und Formate unmittelbar. Diese Erfahrung dürfte erneut zu einer fast beharrlichen Orientierung an offenen Standards führen. Es entsteht eine Atmosphäre, die an die Zeit erinnert, in der offene Formate wie RSS, Podcast, OpenID, OAuth und OpenSocial den Nutzern tatsächlich mehr Macht gaben.

Heute ist ein Zeitpunkt erreicht, an dem nicht nur Großunternehmen das Sagen haben, sondern Entwickler- und Nutzer-Communities selbst Ansprüche geltend machen können. Alle sollten von Plattformen Kontrolle über ihre Erfahrung und Transparenz einfordern können, und bei der Einführung offener Standards wie MCP muss Transparenz über interne Abläufe und Datennutzung zwingend mitgeliefert werden. MCP ist offen, weist aber bei internen Abläufen und Sicherheitsfragen weiterhin Schwächen auf, sodass weitere Verbesserungen nötig sind.

Die mögliche Wiederbelebung des Geistes von Web 2.0

MCP ist keine Universallösung, die alle Probleme beseitigt, könnte aber zum Auslöser für die Wiederbelebung des offenen Ökosystems aus der Web-2.0-Ära werden. Grenzen wie die Übertreibung in der KI-Debatte und das Fehlen von Kritik bleiben bestehen.

Dennoch werden vor allem unter jungen Entwicklern die Werte eines programmierbaren Webs und der Abkehr von Geschlossenheit neu bewertet. Das Web war kein Besitz einiger weniger Großunternehmen, sondern ein offener Raum, den alle auf ihre eigene Weise nutzen konnten — und MCP könnte diese Philosophie wieder ins Bewusstsein rufen.

[GN⁺]

Hacker-News-Kommentare

• Viele übersehen meiner Meinung nach, dass der Kern von MCP darin liegt, dass es sich gut für Enterprise-Software eignet: Ein LLM kann als eine Art universeller Übersetzer fungieren und als flexible Zwischenschicht Systeme verbinden, die sich sonst nur schwer koppeln lassen. Tatsächlich werden MCP-Server auch in der B2B-SaaS-Branche bereits rege eingeführt, und auch intern wird zunehmend darüber diskutiert, Beschränkungen oder Strukturen an API-Nutzungsmuster anzupassen. Selbst wenn das Protokoll in vielerlei Hinsicht nicht „enterprise-ready“ ist, halte ich das nicht für besonders wichtig. In der Geschichte von Standards wurden oft unfertige, „holprige“ Spezifikationen übernommen, wenn sie den Bedarf des Marktes trafen.
  • Ich verstehe MCP als etwas wie RPC über langlebige Verbindungen, meist auf WebSocket-Basis. Persönlich finde ich RPC einfacher: Erstens vermeidet es unnötige Debatten aus dem REST-Endpoint-Design, etwa ob man mit POST alles ersetzt oder mit PUT nur einzelne Felder ändert. Zweitens muss das LLM keine REST-Begriffe oder -Semantik verstehen, sondern nur die RPC-Methoden sehen und kann sie direkt aufrufen. Diese beiden Punkte sind aus meiner Sicht die große Stärke.
  • Ich möchte darauf hinweisen, dass MCP aus Unternehmenssicht ein hervorragendes Erlösmodell ist. Jede Datenanfrage ist direkt mit einem kostenpflichtigen LLM-Lauf verbunden. Gleichzeitig ist es schade, dass es bei MCP keinerlei Optimierungen wie Schema-Aushandlung gibt, die zukünftige Queries günstiger machen könnten.
  • Es gibt bereits REST und OpenAPI, die selbst Discovery-Funktionen unterstützen. Ich glaube, dass Unternehmen, die MCP anbieten, ohnehin alle gute APIs bereitstellen werden.
  • Dem stimme ich wirklich zu: In großen Unternehmen gibt es viele Ingenieure, die von 9 bis 17 Uhr konzentriert großartige Arbeit leisten und danach keinen Gedanken mehr an die Firma verschwenden. Für Unternehmen ist es dann nur logisch, in genau diesen Arbeitsstunden die Produktivität der Mitarbeiter maximal zu steigern.
• Ich frage mich, wie lange es dauert, bis Experimente auftauchen, bei denen mit einem MCP-Server kakerlakenartige Lebewesen gesteuert werden. Tatsächlich gab es in den letzten mehr als zehn Jahren viele Beispiele wie RoboRoach-Experimente und Cyborg-Kakerlaken.
• Früher verfassten Unix-Entwickler äußerst gründliche Spezifikationen, aber die Zeiten haben sich geändert. Ich würde sagen, dass genau diese Strenge und die Ermüdung durch „eXtensible“-Ansätze einer der Gründe für das Scheitern XML-basierter Architekturen waren. Damals war die Architektur mit XSL, XHTML, XSD, WSDL, RDF, RSS usw. übermäßig komplex, und genau deshalb wurden einfache Formate wie JSON populär. In letzter Zeit beobachte ich allerdings wieder einen Trend hin zu mehr XML-Nutzung. Gerade in System-Prompts von LLMs wie bei Anthropic werden strukturierte Texte wie XML oder Markdown häufig verwendet. Trotzdem halte ich das MCP-Modell für falsch: Statt dem Modell zu sagen, es solle Informationen „holen“, ist ein „Push“-Ansatz besser, also Kontext vorab bereitzustellen.
  • Interessant ist, dass ich beim Erstellen einer JSON-basierten Makro-Erweiterungssprache gemerkt habe, dass ich im Grunde XSLT oder XPath neu erfinde. Dabei war ich beeindruckt, wie gut die XPath-Spezifikation für Graph-Traversal geeignet ist. Mit Tools wie BaseX kann man beliebiges XML in eine DB laden und mit XPATH/XQUERY abfragen, was sehr nützlich ist. Wenn man für ein LLM eine belastbare Datenschnittstelle gegen Halluzinationen bauen will, halte ich es für die beste Lösung, ein XML-Schema in den System-Prompt zu packen und dann Datenausdrücke generieren zu lassen.
  • Ich frage mich, wie weit ein „Kontext-im-Voraus-pushen“-Modell in der Praxis überhaupt Probleme abdecken kann. Wenn ein Nutzer die Informationen schon im Voraus kennt, würde er das Problem einfach direkt lösen. Der größte Teil der MCP-Nachfrage fühlt sich eher an wie: „Bearbeite einfach meine Query, ohne dass ich lernen muss, wie ich 15 verschiedene Quellen anbinde.“
  • LLMs kommen gut mit XML in Tag-Form zurecht, aber in der Praxis nutzen die meisten gar keine echten XML-Blöcke mit <?xml version="1.0" encoding="UTF-8"?>, Namespaces, Schemas usw., sondern eher lose Sammlungen von SGML-artigen Tags.
  • Ich möchte betonen, dass der eigentliche Grund für das Scheitern des Semantic Web darin lag, dass sich Werbung oder die Anbindung an Geschäftsmodelle nicht erfolgreich integrieren ließen.
  • Ich stehe dem „Kontext-Push“-Ansatz kritisch gegenüber. Die Kontextkapazität von LLMs (context window) ist sehr begrenzt, daher ist es optimal, nur die tatsächlich benötigten Informationen minimal zu übergeben. Wenn einzelne Modelle den benötigten Kontext selbst gezielt per Pull auswählen können, ist die Chance größer, diese Grenze zu überwinden.
• MCP weckt durch die Popularität von AI zwar die Hoffnung, dass verschiedenste Plattformen für beliebige Zwecke programmierbar werden, aber ich glaube eher, dass es zum Scheitern verurteilt ist. Denn auch das Semantic Web ist letztlich daran gescheitert, kein tragfähiges Erlösmodell aufzubauen. Dasselbe gilt für „Research“-Funktionen, bei denen AI das Web tiefgehend anstelle des Menschen durchsucht. Man hätte zum Beispiel Restaurantmenüs als Metadaten publizieren können, um Automatisierung wie „Finde die günstigsten Tacos in Texas“ zu ermöglichen. In der Realität sehen wir jedoch eher Data Lockdown und einen Infrastrukturkampf, in dem AI-Crawler solche Barrieren umgehen. Im großen Bild ist das aktuelle System einfach ineffizient.
  • MCP ist am Ende nur eine weiterentwickelte Form von robots.txt. Im Kern ist es ein Modell nach dem Motto: „Wenn du meine Ressourcen gut beschreibst, werde ich sie nutzen.“ Schon agentenbasierte Java-Systeme der 90er sind an Informationsasymmetrien zwischen Agenten gescheitert, und es gibt die Sorge, dass die Beseitigung dieser Designgrenze das gesamte soziale und geschäftliche Gefüge zum Stillstand bringen könnte.
  • Offene APIs scheitern nicht nur an der Frage des Geldverdienens. Praktisch ist es so, dass man ohne den Einsatz quasi unbegrenzter Ressourcen irgendwann durch Wellen von Request-Bots für AI-Agenten die eigenen Ressourcen erschöpft und bankrottgeht. Langfristig halte ich ein RPC-Pay-per-Call-Modell für die stabile Alternative. Betreiber von Modellen und Agenten würden dann als Clearingstelle für Zahlungen fungieren und die Kosten in Abonnements oder Ähnliches einpreisen.
  • Das Ideal einer REST-Architektur wie HATEOAS war Anfang der 2010er ein großer Hype, ist aber außer in Automatisierungstools wie Swagger-YAML praktisch ohne echte Weiterentwicklung verschwunden. Schon die Terminologie war so schwierig, dass sie ihr eigenes Scheitern begünstigte.
  • Ich widerspreche der Ansicht, dass von Menschen lesbarer Text eine künstliche Barriere sei. Eher ist es eine künstliche Barriere, von Restaurants JSON-Produktionsfähigkeiten oder den Einsatz von Software zu verlangen. Dank NLP-Tools lassen sich vorhandene Daten heute direkt nutzen, wodurch die Entwicklungskosten fast auf null sinken. Sprachliche Ungenauigkeit bleibt zwar, aber das ist eine grundlegende Eigenschaft menschlicher Sprache und für mich kein großes Problem.
  • Vorsichtig gesagt, obwohl das im Kontext der Kritik am Semantic Web steht: Ein Restaurantbesitzer, der das wirklich will, kann jederzeit Metadaten publizieren, und das könnte Käufer und Verkäufer leicht zusammenbringen. Bei WordPress-Plugins gibt es bereits Unterstützung für Metadaten wie schema.org/Restaurant, Menu, MenuItem und Offer. Daher vermute ich, dass die größte Hürde am Ende eher Gatekeeping durch Dienste wie Cloudflare ist. Das ist in der Praxis auch ein echter Hemmschuh für Python-Automatisierungsideen.
• Da LLMs API-Dokumentationen lesen und sich automatisch anpassen können, ist die Einhaltung standardisierter API-Spezifikationen vielleicht nicht mehr so zwingend wie früher. Unabhängig davon, ob sich die MCP-Spezifikation durchsetzt, ist schon die Erwartung, dass jede Site eine „API bereitstellt“, ein großer Wandel.
  • In der Praxis kann API-Dokumentation mangelhaft sein, sodass LLMs falschen Code oder fehlerhafte Aufrufe erzeugen. Wenn Nutzer das dann korrigieren und wieder an das LLM zurückgeben, endet das faktisch darin, dass man eine Zwischenschicht baut, also einen MCP-artigen Server. Gibt man dem LLM direkten API-Zugriff, entstehen außerdem Risiken bei Sicherheit und Ressourcenverwaltung, etwa explodierende Kosten durch übermäßige Aufrufe. Es gibt mehrere zusätzliche Pain Points, und einige davon werden gerade durch eine Architektur mit einer MCP-ähnlichen Schnittstelle in der Mitte gelöst. Ob dieser „Mittelsmann“ zwingend MCP sein muss, ist eine andere Frage, aber zum jetzigen Zeitpunkt ist es durchaus eine praktische Lösung.
• Was mir an MCP die größten Sorgen bereitet, ist nicht ein unzureifendes Protokollniveau, sondern dass Verbesserungs- und Korrekturmöglichkeiten auf Teams innerhalb von Anbietern wie Anthropic oder OpenAI konzentriert sind. Es entsteht auch die Sorge, dass die Spezifikation eher auf der Ebene von Brainstorming stehen bleibt als sich an tatsächlichen Entwicklern und Operatoren zu orientieren. Das wirkt ein wenig wie der Schatten eines Visa-Mastercard-Duopols.
  • Es gibt auch Fälle wie den Beitritt von Microsoft zum Steering Committee.
• „Semantic Web“ war letztlich eigentlich nur eine grammatische Struktur, und es gibt die Hoffnung, dass MCP erstmals echte praktische Umsetzbarkeit haben könnte.
• Es gibt die Wahrnehmung, dass „wichtige alte Unix-Entwickler übertrieben pedantisch waren“, aber ironischerweise war gerade Unix der Ursprung der Kultur des „schnell ausprobieren und Dinge kaputthauen“. Die Generationen mögen wechseln, aber das Wesen bleibt gleich.
• Es gibt die sehr reale Sorge, dass MCP wie Suchmaschinenoptimierung (SEO) missbraucht werden könnte, um Werbung und Spam in Richtung AI zu verbreiten.
• Man sollte sich davor hüten zu glauben, dass dank MCP nun jeder problemlos auf alle möglichen Daten zugreifen kann. In Wirklichkeit ist alles an mehrere Schichten von Zahlungsautorisierung, erlaubte White-List-IP-Adressen und andere Sicherheitsmechanismen gebunden, sodass beim echten Nutzer am Ende oft nur ein „ERR 402“ zurückkommt.