Die Ankunft von Web 2.0 2.0: MCP

 (anildash.com)
2 Punkte von GN⁺ 2025-05-25 | 1 Kommentare | Auf WhatsApp teilen
  • Model Context Protocol (MCP) ist eine von Anthropic entwickelte Spezifikation, um LLMs mit externen Apps und Systemen zu verbinden. Nachdem OpenAI sie in ChatGPT unterstützt hat, verbreitete sie sich wie eine gemeinsame Schnittstelle über mehrere Plattformen hinweg.
  • Auch wenn eine Spezifikation locker und unvollständig ist, kann ein offenes Protokoll im realen Web an Bedeutung gewinnen, wenn mehrere Beteiligte schnell denselben Ansatz übernehmen.
  • Der ursprüngliche Wert von Web 2.0 lag weniger in geschlossenen Social Sites als vielmehr in einem Ökosystem aus Entwickler:innen und Nutzer:innen, das durch Open APIs und interoperable Tools entstand.
  • Die Erwartung an Interoperabilität, die geschwächt wurde, als große Plattformen wie Facebook und Twitter ihre APIs schlossen, könnte MCP im Zuge des Aufstiegs von AI-Coding-Tools wieder als programmierbare Plattform beleben.
  • MCP ist keine Universallösung, und die Intransparenz bei der Datenverarbeitung sowie Sicherheitsrisiken sind groß. Es kann aber ein neuer Anlass sein, Standardkonformität und Transparenz einzufordern.

Warum sich MCP wie ein Standard verbreitet hat

  • Das Model Context Protocol, kurz MCP, ist eine von Anthropic für Claude entworfene Spezifikation
    • Sie soll LLMs ermöglichen, Informationen von verschiedenen Apps anzufordern oder mit anderen Systemen zu interagieren
  • Als OpenAI vor einigen Monaten dasselbe Protokoll in ChatGPT unterstützte, etablierte sich MCP wie ein an vielen Stellen übernommener Standard
  • Auch Windows enthält MCP, was die Reichweite der Verbreitung zeigt
  • Entscheidend ist weniger die Vollständigkeit der Spezifikation als die Tatsache, dass mehrere Player schnell dieselbe Schnittstelle übernommen haben
  • MCP ist eher eine lose Spezifikation, ähnelt aber in dem Punkt dem Erfolgsmodell des Webs, dass es offen ist und funktioniert

Was Web 2.0 ursprünglich meinte

  • Web 2.0 bezeichnete nicht geschlossene, proprietäre Sites wie Facebook
  • Im Zentrum der frühen Web-2.0-Community stand die Bewegung, dass verschiedene Sites Open APIs bereitstellten und Entwickler:innen sowie Nutzer:innen Menschen und Daten miteinander verbinden konnten
  • Flickr, Del.icio.us und Upcoming waren repräsentative Sites einer Ära, die Funktionen wie Tags und Social Sharing voranbrachte
  • Auch Plattformen wie LiveJournal und Movable Type beeinflussten Arbeiten an offenen Standards rund um APIs und Protokolle
  • Die gemeinsamen Werte jener Zeit waren relativ klar
    • Tools, Technologien und Plattformen wurden auf offenen Daten und offenen Protokollen aufgebaut
    • Nutzer:innen hatten Kontrolle
    • Entwickler:innen interagierten mit Systemen über konsistente und interoperable Tools

Die Interoperabilität, die geschlossene Plattformen gekappt haben

  • Über eine Generation hinweg wurde es für Entwickler:innen schwieriger, Interoperabilität zwischen Apps und Plattformen als selbstverständlich zu erwarten
  • Hinzu kam die Kritik, große VCs und Führungskräfte der Tech-Branche hätten die Ära der Offenheit beendet
  • Tools zur Analyse von Aktivitäten in sozialen Netzwerken erlebten Fälle, in denen Produkte und nutzerbasierte Dienste eingestellt wurden, weil große Social-Network-Plattformen ihre APIs schlossen
  • Plattformen wie Facebook und Twitter zerstörten für viele die Web-2.0-Erwartung an offene Daten und interoperable Technologien
  • In der Folge wurde es alltäglich, dass Nutzer:innen ihre eigenen Netzwerke nicht so handhaben können, wie sie möchten
    • Eingebettete Instagram-Fotos sind in der Twitter-Timeline nicht zu sehen
    • Funktionen wie das Importieren und Exportieren von Followern, wie sie im Fediverse oder bei Bluesky möglich sind, lassen sich nur schwer nutzen
    • Es ist schwierig, das eigene Netzwerk mit der gewünschten App zu steuern

Die Möglichkeit, die MCP wieder öffnen könnte

  • Der Aufstieg von MCP fällt mit dem Trend zusammen, dass AI unter Coder:innen populär wird, und weckt die Erwartung, dass Plattformen nicht nur für LLMs, sondern auch für verschiedene Programmierzwecke geöffnet werden können
  • Entscheidend ist, dass andere Plattformen die von Anthropic erstellte Spezifikation unverändert übernommen haben
  • Wenn ein Protokoll eines anderen Unternehmens als zweite Implementierung gewissenhaft übernommen wird, kann das gesamte Ökosystem leichter auf dieselbe Weise funktionieren
  • Umgekehrt kann es dem Ökosystem schaden, ein Protokoll zu kopieren, zu erweitern und schließlich verschwinden zu lassen
  • Wenn eine wohlwollende Übernahme derselben Schnittstelle stattfindet, wächst der Spielraum dafür, dass mehrere Tools und Plattformen zusammenarbeiten

Warum es schwierig ist, Standards unverändert zu befolgen

  • Einen Standard unverändert zu unterstützen, ist schwieriger, als es aussieht
  • Auch beim Launch eines Semantic-Caching-Produkts für AI-Plattformen war es nicht leicht, Entwickler:innen davon zu überzeugen, einfach die normale ChatGPT API zu verwenden
  • Entwickler:innen denken leicht: „Wir können das besser machen“, doch sobald man vom Standard abweicht, kann es eher schlechter werden
  • Selbst bei einer schlechten Spezifikation mit vielen Inkonsistenzen kann es wichtiger sein, dass alle sie auf dieselbe Weise implementieren
  • Auch HTML war eine unvollständige Spezifikation, der vieles fehlte, aber das Web wurde darauf aufgebaut
  • Auch das gesamte Internet steht auf mehreren unvollständigen Spezifikationen

Forderung nach Standardkonformität und Transparenz

  • Eine neue Generation von Entwickler:innen erlebt die Kreativität und die Möglichkeiten, die entstehen, wenn ihre bevorzugten Tools und Plattformen dieselben Protokolle und Formate verwenden
  • Bewegungen wie RSS, Podcasting, OpenID, OAuth und OpenSocial führten später teilweise zu Ergebnissen wie dem Fediverse und ActivityPub
  • Entwickler:innen, Coder:innen, Tech-Enthusiast:innen und normale Nutzer:innen können von Plattformen Zugriff verlangen, um ihre Erfahrung per Code zu steuern
  • Beim Zugriff über offene Standards wie MCP sollte zugleich Transparenz darüber eingefordert werden, was eine Plattform tatsächlich tut
  • MCP ist flexibel, lässt aber mehrere Risiken bestehen
    • Es ist intransparent, wie Plattformen Nutzerdaten behandeln
    • Es ist schwer zu wissen, welche Aktionen bei Interaktionen über MCP ausgelöst werden
    • Die Sicherheitsrisiken sind sehr groß
    • Das Protokoll behandelt diese Bedenken nicht ausreichend

Grenzen und Erwartungen an Offenheit im Stil von Web 2.0

  • MCP ist keine Universallösung, die alle Probleme des Entwickler-Ökosystems behebt
  • Es korrigiert auch nicht den Hype und die verzerrten Debatten rund um AI
  • Es besteht jedoch die Möglichkeit, dass jüngere Entwickler:innen, die die frühere Web-2.0-Ära nicht erlebt haben, MCP zum Anlass nehmen, das Web wieder näher an seine ursprüngliche Architektur heranzuführen
  • Das Web war nicht als proprietäre Struktur gedacht oder als etwas, das von einigen wenigen Personen in wenigen Großunternehmen kontrolliert wird
  • Das Web sollte durch grobe Spezifikationen, die alle eilig übernahmen, programmierbar sein; diese hackbare Freude gab es schon, bevor das Web eine Versionsnummer bekam

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-25
Hacker-News-Kommentare

  • Was viele bei MCP übersehen: Es passt gut zu Enterprise-Software.
    LLMs sind universelle Übersetzer und eignen sich daher als Klebstoff, um isolierte Systeme miteinander zu verbinden, die ohne eine einigermaßen lockere Zwischenschicht extrem schwer zu koppeln wären.
    Deshalb bringen B2B-SaaS-Anbieter MCP-Server heraus, und intern wird diskutiert, wie APIs und ihre Einschränkungen für veränderte Nutzungsmuster neu gestaltet werden sollten.
    Das Protokoll ist nach vielen Definitionen nicht „enterprise-ready“, aber wie der Autor sagt, ist das nicht allzu wichtig. Die Geschichte von Standards zeigt, dass auch chaotische und „schlechte“ Dinge breit übernommen werden, wenn sie zur richtigen Zeit bei den richtigen Leuten passen.

    • MCP ist nur RPC über eine langlebige Verbindung, meistens WebSocket. Meiner Meinung nach ist RPC einfacher einzurichten.
      Es gibt weniger Diskussionen darüber, ob das Ändern eines Felds eines User-Objekts nun ein PUT ist, der das ursprüngliche User-Objekt ersetzt, oder ein POST. Ich habe ziemlich viel Zeit mit REST-Verben verschwendet.
      Auch ein LLM muss die REST-Semantik einer API nicht verstehen. Es schaut sich die verfügbaren RPC-Methoden an und ruft auf, was passend wirkt. Im Kern ist es meiner Ansicht nach wirklich nicht mehr als das.
    • Das ist eine gute Struktur, um Geld zu verdienen. Bei jeder Datenanfrage steckt ein kostenpflichtiger LLM-Roundtrip drin.
      Es ist nicht so, dass Endpunkte untereinander ein Schema aushandeln, über das sie künftig günstig Abfragen stellen können.
    • Es gibt bereits REST und OpenAPI.
      Selbst damit sind Dinge wie Self-Discovery möglich.
      Wer MCP anbietet, wird ohnehin auch eine brauchbare API bereitstellen.
    • Stimme vollkommen zu. Große Unternehmen sind voll von Engineers, die von 9 bis 17 Uhr coole Dinge bauen und nach Feierabend bis zum nächsten Tag die Arbeit vergessen wollen.
      Welches Unternehmen möchte nicht während der Arbeitszeit die maximale Produktivität aus seinen Mitarbeitern herausholen?

  • Der Teil „verglichen mit der Zeit, als pingelige alte Unix-Typen Spezifikationen schrieben“ ist meiner Ansicht nach einer der vielen Gründe, warum das Semantic Web gescheitert ist. Das widerspricht auch nicht der Aussage des Autors, dass „schlechter besser ist“.
    Ich denke, die Leute haben sich zu sehr in das eXtensible von XML hineingesteigert, und es hatte sich eine gewisse Ermüdung eingestellt. XSL, XHTML, XSD, WSDL, XSLT, RDF, RSS und so weiter wurden einfach zu viel.
    Was die Welt damals brauchte, war ein einfaches Austauschformat, und JSON erfüllte diesen Bedarf; die XML-Seite dagegen war eher Architektur-Astronautik rund um Datenformate.
    Gleichzeitig glaube ich aber, dass jetzt die Zeit von XML gekommen ist. In geleakten System-Prompts von Anbietern wie Anthropic sieht man häufig XML. LLMs scheinen mit strukturierten Textformaten, besonders Markdown und XML, ziemlich gut zurechtzukommen.
    MCP halte ich allerdings für das falsche Modell. Statt das Modell anzuweisen, Kontext selbst „heranzuziehen“, sollten wir meiner Meinung nach Kontext in das Modell „hineinschieben“.

    • Interessante Beobachtung. Ich habe mich in letzter Zeit ziemlich für XML/XSLT interessiert, während ich eine JSON-Makro-Erweiterungssprache gebaut habe.
      Vier Makro-Tags (#=, #&, #?, #!) sollten sich jeweils durch das Ergebnis ihrer Makro-Expansion ersetzen: Zuweisung, Ersetzung, bedingte Verzweigung wie cond und Aufruf benutzerdefinierter Funktionen. Am Ende merkte ich, dass ich XSLT neu erfand.
      Was ich wirklich wollte, war XPath. Es beschreibt, wie man einen Graphen entlang verschiedener Achsen vorwärts und rückwärts durchläuft, und ist tatsächlich eine hervorragende Spezifikation.
      Dann fand ich BaseX https://basex.org/, das beliebige XML-Dokumente in eine abfragbare Datenbank importieren und mit XPath oder XQuery abfragen kann.
      Wenn man eine verlässliche Natural-Language-Schnittstelle zu Datensätzen ohne Halluzinationen bauen will, scheint mir der beste Weg zu sein, dem System-Prompt ein XML-Schema zu übergeben und das Modell Abfragen schreiben zu lassen, die die Daten holen.
    • Ich sehe nicht, wie „den Kontext hineinschieben, statt das Modell ihn selbst heranziehen zu lassen“ in den Fällen funktionieren soll, bei denen Leute wollen, dass ein Praktikant sie löst.
      Wenn man die Informationen vorher schon kennt, hätte man das Problem vermutlich selbst gelöst.
      Der Wert von MCP scheint mir eher zu sein: „Lass mich nicht lernen, wie ich 15 Quellen zusammenstöpsele, sondern führe für mich die passende Abfrage aus.“
    • XML-Tags funktionieren gut mit LLMs. Aber meistens sind es eben nur XML-Tags.
      Niemand™ füttert LLMs mit ordentlichem XML, das mit einer XML-Deklaration beginnt, und niemand nutzt Namespaces, XSLT, XML Schema oder Ähnliches.
      Es ist eher eine beliebige Sammlung von Tags im SGML-Stil.
    • In Hobby-Code arbeite ich manchmal mit XML als Quellformat für Dokumente, aber am Ende wende ich mich doch wieder davon ab, wegen der vielen Kleinigkeiten rund um die Syntax.
      XML ist eine große Spezifikation, die weit über spitze Klammern hinausgeht und versucht, alle Fälle abzudecken sowie Sicherheit und Zeichencodierung korrekt zu behandeln.
      Deshalb ist „Bearbeitung als normaler Text“ ziemlich wenig intuitiv. Wenn man so einen Absatz wie diesen eingibt, kann er im Kompatibilitätsmodus zwar geparst werden, aber möglicherweise nicht gültig sein.
      Als Austauschformat oder als Format, das in dafür entwickelte Anwendungen geladen wird, hat es mehr Potenzial, und LLMs werden es sicher problemlos verstehen; das ist also gut.
      Viele frühere Probleme kamen daher, dass Programmierer wenig Zeit hatten, Features schnell hineinquetschen wollten und eine stark strukturierte Spezifikation wie einen Knüppel benutzten. Wenn drei verschiedene Programme und drei Autoren jeweils „XML? Dafür nehme ich einfach Regex.“ machen, entsteht Chaos.
      Was dem, was ich persönlich wollte, tatsächlich nahekam, war BBCode. Als Quellformat für vieles ist es großartig. Im Grunde ist es immer noch eine Art spitze-Klammern-Format, aber mit genug Struktur und Flexibilität, um als allgemeine Frontend-Syntax gut zu funktionieren.
      Frühe Implementierungen waren zwar „dafür nehme ich einfach Regex“, aber nach Jahrzehnten Praxiserprobung gibt es heute auch elegantere Parser.
    • Das Semantic Web ist gescheitert, weil es keinen Weg gefunden hat, Werbung einzuschleusen.

  • Ich sehe es genau umgekehrt zu dem Satz: „Der Aufstieg von MCP gibt Hoffnung, dass KI, während sie unter Programmierern populär wird, andere Plattformen öffnen kann, damit LLMs sie nicht nur steuern, sondern für beliebige Zwecke programmierbar machen können.“
    MCP ist aus genau dem Grund zum Scheitern verurteilt, aus dem auch das Semantic Web gescheitert ist: Wenn etwas nicht eingeschlossen ist, verdient niemand Geld damit.
    Ich frage mich, wie viel von dem, was KI in unserem Namen im Web sucht — sorry, von der Funktion, die man „Deep Research“ nennt — sich auf bessere Weise hätte lösen lassen.
    Restaurants hätten ihre Speisekarten als Metadaten veröffentlichen können, und jeder hätte mit einem Python-Skript die billigsten Tacos in Texas finden können. Stattdessen sperren wir mit der einen Hand Daten hinter künstliche Barrieren und bauen mit der anderen, bis hin zu Rechenzentren, KI, um diese Barrieren zu umgehen. Makroskopisch betrachtet ist das einfach dumm.

    • Sehe ich auch so. MCP wirkt wie eine höher entwickelte Lebensform von robots.txt, ist aber immer noch eher: „Bitte beschreib deine Ressourcen, damit wir sie ausbeuten können.“
      Die frühere Agenten-Welle ist letztlich daran gestorben, dass alle begriffen haben, dass man eigenem Code, der auf einer Maschine läuft, mit der verhandelt wird, nicht trauen kann. Das war die Java-Geschichte der 90er.
      Zwischen interagierenden Agenten gibt es grundsätzlich ein absichtlich konstruiertes Problem asymmetrischer Information. Wenn man das beseitigt, hört ein großer Teil der Gesellschaft auf zu funktionieren.
    • Es geht nicht nur darum, dass man mit kostenlosen offenen APIs kein Geld verdient. Um solche APIs zu betreiben, braucht man praktisch unbegrenzte Ressourcen.
      Egal wie viele Ressourcen man auf das Problem wirft: Irgendjemand wird einen Weg finden, sie für einen winzigen Vorteil auszuschöpfen.
      MCP verschlimmert das Problem nur, weil KI-Agenten wie Heuschreckenschwärme über öffentliche MCP-Server herfallen werden.
      Die stabile Option dürfte eine RPC-Bepreisung pro Aufruf sein. Immerhin wird der Betreiber des Modells oder Agenten als Zahlungs-Clearingstelle fungieren, also hat das bessere Chancen als bei den Web-2.0-APIs.
      Die wahrscheinlich plausibelste Abrechnung wäre wohl, solche Kosten in Abo-Tarife einzupreisen. Das scheint die beste Ausrichtung der Anreize zu sein.
    • Anfang der 2010er war HATEOAS der Traum: API-Nutzung trivial machen. Am Ende kam man aber kaum über das Erzeugen von Swagger-YAML hinaus.
      Wer sich überhaupt den Namen HATEOAS ausgedacht hat, hat das Scheitern im Grunde schon vorbereitet.
    • Ich sehe die Popularität von MCP als Nebenwirkung der überhitzten Blase, die KI gerade nach oben treibt. Es ist nur eines der plausibel klingenden Dinge, die man mit KI machen kann.
      Wenn es einen „einfachen“ Wert darin gäbe, Daten in einem Standardformat zu veröffentlichen, wären interoperable Endpunkte viel stärker angenommen worden.
      Zum Beispiel über schema.org oder allgemeine gemeinsame Ontologien. In der Realität gibt es aber oft maßgeschneiderte Formate, die jedes Mal ein spezielles magisches SDK erfordern.
    • Text, den normale Menschen lesen können, ist keine „künstliche Barriere“. Er ist das Wesen unserer Welt.
      Die künstliche Barriere ist eher, Restaurants zu verlangen, ihre Speisekarten als Metadatenformat zu veröffentlichen.
      Genau darin liegt die Schönheit der neuen Natural-Language-Processing-Tools. Restaurantbesitzer müssen weder JSON lernen noch ein Softwarepaket kaufen, das JSON erzeugt.
      Wir können die Daten so verwenden, wie sie sind. Die Kosten, nützliche Tools zu bauen, gehen gegen null.
      Es wird ungenau sein, aber so ist menschliche Sprache nun einmal.

  • Wer glaubt, mit MCP werde man auf alles zugreifen können, tut mir leid.
    Diese Dinge werden hinter Dutzenden Schichten aus Zahlungsprüfung und Authentifizierung versteckt sein. Natürlich kommt auch eine Allowlist-IP dazu, und selbstverständlich wird es IPv4 sein.
    Alles, was ihr zu sehen bekommt, dürfte ERR 402; sein.

  • Was mich an MCP am meisten beunruhigt, ist weniger, dass das Protokoll schlecht gemacht ist, sondern dass Reparatur und Verbesserung allein von internen Teams bei Anthropic und OpenAI abhängen.
    Die Leute, die das Protokoll entwerfen, wirken nicht wie Engineers, die es auch wirklich implementieren.
    Es fühlt sich vage wie das Visa-Mastercard-Oligopol an.

  • Wenn LLMs jetzt API-Dokumentation lesen und sich anpassen können, ist es dann nicht weniger nötig als früher, einer Standard-API zu folgen?
    Der wichtige Vorteil für mich ist, dass die Erwartung entsteht, eine Site habe eine API, unabhängig davon, ob sie der MCP-Spezifikation folgt oder nicht.

    • API-Dokumentation kann miserabel geschrieben sein.
      Selbst bei guter Dokumentation kann ein LLM falschen Code für die Interaktion mit der API erzeugen. Wenn man den erzeugten Code korrigiert und das LLM diesen Code aufrufen lässt, um mit der API zu interagieren, ist man ohnehin schon auf dem Weg zu einer Zwischenschicht. Im Grunde baut man einen „MCP-artigen“ Server.
      Wenn man einem LLM direkten API-Zugriff gibt, gibt es außerdem Sicherheits- und Ressourcenallokationsprobleme. Ein LLM hat nur begrenztes Wissen darüber, wann die API zuletzt aufgerufen wurde. Es kann zu häufig aufrufen, und wenn die Kosten pro Aufruf hoch sind, entstehen unerwartete Infrastrukturrechnungen.
      Darüber hinaus gibt es viele potenzielle Schmerzpunkte, die sich lösen lassen, wenn man etwas dazwischen setzt.
      Ob dieses „Etwas“ MCP sein muss, können vernünftige Menschen unterschiedlich sehen. Im Moment scheint es gut genug zu funktionieren, um das zu erledigen, was die Leute erledigt haben wollen.

  • Jetzt können wir das Semantic Web bauen. Organisationen müssen nur ein kleines Protokoll schaffen, mit dem sie SQL-CREATE TABLE-DDL als statische Dateien teilen, die MCP-Apps lesen können. Als optionale Erweiterung von MCP reicht das aus.
    Dann kann man bereits existierende Tools nutzen, die KI-/LLM-Funktionsaufrufe mit SQL verbinden, um Daten zu verstehen und abzufragen — und das wäre dann das Semantic Web.
    Dieser Ansatz schließt das fehlende Glied, das das Semantic Web immer ausgebremst hat: Es gab keinen Anreiz für Unternehmen, statt proprietärer Datentypen standardisierte „Datentypen“ zu verwenden.
    Mit MCPQ, also MCP inklusive Abfragen, hätten Organisationen plötzlich einen Grund, auf der Ebene der Datenstrukturen zusammenzuarbeiten.

  • Wie sich herausstellt, war das „Semantic Web“ die ganze Zeit über ein syntaktisches Web — und vielleicht ist es diesmal wirklich so weit.

  • Ich frage mich, wie lange es dauern wird, bis jemand einen MCP-Server baut, der so etwas wie Kakerlaken steuert.
    Referenzmaterial:
    https://www.technologynetworks.com/informatics/news/robo-roa...
    https://www.sciencealert.com/scientists-turned-cockroaches-i...
    Und es gibt viele weitere Beispiele, die mehr als zehn Jahre zurückreichen.

  • Die Formulierung „als Spezifikationen noch von pingeligen alten Unix-Typen geschrieben wurden“ ist ziemlich witzig.
    Interessant, dass sich diese Generation die „alten Unix-Typen“ als pingelige Leute vorstellt. Unix war doch die ultimative move fast and break things-Rebellion gegen die MIT-Schule.
    Manche Dinge ändern sich wohl nie :-)