Pi.dev integriert MCP – trotz jahrelanger Ablehnung

Respekt an das Team, nicht nur, dass sie ihre Meinung von einer stark vertretenen Überzeugung geändert haben, sondern dass sie es sehr öffentlich machen und nicht verbergen, dass es eine Kehrtwende ist.

Der verlinkte Beitrag von Armin ist Gold wert:

"... wann immer man mit einer sehr starken Meinung zu einem Thema konfrontiert wird, beinhalten vernünftige Diskussionen über das Thema oft Argumente, die längst veraltet oder für die Unterhaltung nicht mehr streng relevant sind."

(https://lucumr.pocoo.org/2016/11/5/be-careful-about-what-you...)

Und das ist von 2016! Heutzutage, wenn man von einer Position aus argumentiert, die man noch vor einer Woche eingenommen hat, ist man möglicherweise schon nicht mehr auf dem neuesten Stand.

Das war die einfachste Entscheidung, und viele wie ich haben sie im März[0] getroffen, inmitten der ganzen Anti-MCP-Welle von Influencern, die es für tot erklärten (viele, viele prominente Leute in der Tech-Branche, einschließlich Garry Tan). Buchstäblich jeder Tech-Influencer in jedem Social Feed rief im März MCP für tot aus und krönte die CLI zum Sieger (und ignorierte dabei völlig jedes vernünftige Argument zu Sicherheit, Observability/Telemetrie, einfacher Bereitstellung und Betrieb usw.).

Ein direktes Zitat aus März 2026[1]:

> Wenn du immer noch nicht überzeugt bist, dass ein Großteil dieses Diskurses [über den Tod von MCP] Nuancen vermissen lässt und einfach nur Hype ist, herzlichen Glückwunsch, dass du in den aktuellen AI-Influencer-FOMO-Hype-Zyklus eingekauft hast; wir sehen uns in 6 Monaten, wenn die Influencer zur nächsten Offenbarung des Moments weiterziehen, um relevant zu bleiben und deine Aufmerksamkeit und dein Geld zu bekommen.

Es war ziemlich offensichtlich, warum MCP gebraucht werden würde, sobald AI-Engineering und -Akzeptanz über den Solo-Entwickler und den Single-Harness-Stack von "was für Mich funktioniert" versus "was für Mein Team funktioniert" hinausgehen, insbesondere im Unternehmenskontext. Der zentrale Fehler der Leute war, in Begriffen ihrer eigenen Workflows und lokalen Stacks zu denken, statt in Begriffen des Workflows eines Teams und des operativen Stacks eines Teams. Es gab auch Unkenntnis über MCPs zustandslosen HTTP-Modus (ja, das war im März bereits Realität; die Revision der Spezifikation vom 28.07.2026 priorisiert ihn nur als primären Fokus für die Zukunft) gegenüber lokalem `stdio`.

Meine größte Beschwerde im Moment ist, dass OpenAI sich immer noch weigert, die MCP-Prompts-Spezifikation[2] zu implementieren, und in g […]

Ich schätze ihre Zurückhaltung gegenüber MCP, aber /irgendetwas/ ist besser als nichts.

Es ist aus den vom Autor dargelegten Gründen suboptimal: aber das ist USB-C auch. NVME auch, HDMI auch.

Wir nutzen diese enorm erfolgreichen Technologien trotz ihrer Mängel, weil sie weit verbreitet kompatibel und für den Endnutzer einfach sind.

Deshalb ist MCP überall. Es mag nicht performant, robust und einheitlich sein, aber es WIRD mit der Zeit besser werden.

Und ich hätte viel lieber das breite MCP-Ökosystem, das wir jetzt haben, als sieben oder acht verschiedene "optimale" Wege, ein LLM an etwas Nützliches anzuschließen.

Ich empfinde genauso in Bezug auf die Notwendigkeit von Unterstützung für Sub-Agenten, die mir ziemlich grundlegend erscheinen.

Ich vermute, dass ein kluges Modell, das mehrere dümmere Modelle für Arbeit steuert und dann Sub-Agenten mit demselben klugen Modell für adversarial Review nutzt, ein ziemlich verbreitetes Muster sein wird.

Persönlich war ich etwas verwirrt darüber, dass Pi das meiste davon als Plugins hat, da ich mich daran erinnere, wie sehr Eclipse ein Chaos war, wo so viel nur lose zusammenpassende Plugins waren, und habe mich einfach für OpenCode entschieden, da es die meisten meiner Bedürfnisse out of the box abdeckt. Ich schätze, das könnte auch ein Zeichen dafür sein, dass ich älter werde, denn meine IDEs und Desktop-Umgebungen sind auch alle näher am Standard.

Wir müssen aufhören, Unternehmen nach Herr-der-Ringe-Lore zu benennen.

> Die Art und Weise, wie wir MCP an diesem Punkt gerne betrachten, ist, dass es viel näher an OpenAPI mit intelligenter Tool-Entdeckung sein sollte. Das bedeutet, Tools sollten strukturierte Daten zurückgeben und Tools sollten durch ihre Dokumentation und Beschreibung auffindbar sein.

OpenAPI ist "intelligente Tool-Entdeckung" (was auch immer das sein soll). OpenAPI "gibt buchstäblich strukturierte Daten zurück" und ist "durch ihre Dokumentation und Beschreibung auffindbar".

Nur einmal würde ich gerne sehen, dass jemand MCP in Begriffen erklärt, die darauf hindeuten, dass er irgendeine Ahnung hat, wovon er spricht.

Ich benutze mcporter[0], um MCP zu konsumieren, wenn geeignete CLIs nicht verfügbar sind. Es stellt MCPs als Shell-Befehle bereit. Agenten komponieren mit Standard-Shell-Primitiven. Tool gibt json zurück? Pipe in jq.

Ein weiterer Vorteil ist, dass es mir erlaubt, Tools auf genau dieselbe Weise auszuführen wie Agenten, anstatt MCP als spezielle Art des Aufrufs von Diensten zu behandeln. Extrem wertvoll beim Debuggen.

[0] https://mcporter.sh/

Ich verstehe MCP immer noch nicht? Was kann MCP, was ein Skill + CLI nicht kann? Ich benutze hax (https://usehax.dev) und habe Skills ehrlich gesagt überhaupt nicht vermisst.

Ich hatte keine Ahnung, dass Pi MCP nicht unterstützt! Ich bin ein neuer Nutzer, ich habe gerade erst angefangen, damit herumzuspielen. Ich war dabei, mein Tooling aufzusetzen, und habe versucht, eines meiner Datenbank-MCPs zum Laufen zu bringen (was im Nachhinein betrachtet etwas schmerzhaft erschien – aber ich ging wohl davon aus, dass es meine Verantwortung war, diese Verbindungen aufzubauen und zu pflegen).

Noch eine nachträgliche Anmerkung: "No MCP" scheint das erste Icon auf ihrer Startseite zu sein – ich bin nicht sicher, wie ich das übersehen konnte.

Stell dir meine Überraschung vor, als ich das gelesen habe!