539 Sterne, 25 Forks, zwölf Commits: das ist der öffentliche Stand des Repositories openai/mcp-extensions auf GitHub. Die Kurzbeschreibung dort lautet „Build plugins that feel like native, first-class features of ChatGPT“ – es geht also nicht um eine weitere Sammlung von Werkzeugaufrufen, sondern um die Frage, wie ein externer Dienst Teil der Oberfläche wird.
Wenn du heute ein ChatGPT-Plugin entwickelst, läuft alles über MCP, das Model Context Protocol. Damit kann ein Modell Werkzeuge aufrufen, Daten lesen, Aktionen auslösen. Was MCP nicht regelt, ist die Oberfläche: Wo taucht dein Dienst auf, wie öffnet sich ein Dokument, wie wählt jemand ein Bauteil aus einer Liste? Genau diese Lücke beschreibt das Repository von OpenAI, und dort entstehen Funktionen, die sonst nur das Produkt selbst hatte.
Wer nach OpenAI MCP Extensions auf GitHub sucht, landet in einem Projekt, das sich als Ergänzung versteht und nicht als Ersatz. MCP bleibt der Unterbau, die Extensions sind die Schicht darüber. Deshalb ist hier vieles offen und wenig abgeschlossen.
MCP als Mietvertrag, Extensions als Ladenfront
Stell dir ein Einkaufszentrum vor. MCP ist der Mietvertrag: Er legt fest, dass ein Laden Waren annehmen, Bestellungen aufgeben und Lieferungen auslösen darf. Das funktioniert und ist erprobt. Nur: Wer durch die Passage läuft, bemerkt diesen Laden möglicherweise gar nicht. Keine Tür zur Hauptachse, kein Schaufenster, kein Kassenband am Gang.
Die Extensions in openai/mcp-extensions sind diese Ladenfront. Sie ergänzen MCP um ChatGPT-spezifische Fähigkeiten, sodass ein Plugin an Stellen auftaucht, die sonst dem Produkt selbst vorbehalten sind. Der Begriff im Repository lautet „first-class“ – ein Plugin soll nicht als Gast erscheinen, sondern als Bewohner. Im Alltag ist der Unterschied deutlicher als in der Dokumentation.
Die Arbeitsteilung dahinter: MCP bleibt der neutrale Unterbau, den auch andere Clients nutzen können. Die Extensions sind die Schicht darüber, gebunden an eine konkrete Oberfläche. Du baust also zweimal – einmal unten, einmal oben – und nur die obere Schicht ist plattformspezifisch.
Vier Andockpunkte, an denen ein Plugin nativ wirkt
Das Repository zeigt die Erweiterungen als kurze Animationen statt als Liste von Funktionsnamen. Der Nutzen lässt sich so leichter zeigen als beschreiben. Der erste Andockpunkt sind Einstiegspunkte in der Seitenleiste: Nutzer öffnen die App direkt aus der Navigation, statt sie über eine Unterhaltung anzusteuern. Ein Dienst bekommt so einen festen Platz, nicht nur eine Erwähnung.
Der zweite Punkt betrifft Dateiendungen. Öffnet jemand eine Datei eines unterstützten Typs, kann das Plugin einen eigenen Betrachter rendern – im Beispiel ist es eine CAD-Datei, die in einer speziellen Ansicht erscheint. Der dritte Punkt heißt Composer Mentions: In der Eingabezeile lässt sich nach Ressourcen des Plugins suchen und ein Verweis in die Nachricht einfügen. Der vierte Punkt sind erweiterte Formulare, in denen die Auswahl über Vorschaubilder läuft statt über Textlisten.
An diesen vier Punkten entscheidet sich, ob ein Werkzeug benutzt oder umgangen wird. Ein Modell kann einen Tool-Aufruf erzwingen – es kann aber niemanden dazu bringen, ein Werkzeug zu mögen. Sichtbarkeit, Suchbarkeit und eine brauchbare Auswahloberfläche machen aus Erreichbarkeit tatsächliche Nutzung. Native ChatGPT-Features mit Plugins entstehen genau hier.
Bits & Bolts: der Referenzfall aus dem Repository
Alle Beispiele stützen sich auf ein einziges Plugin namens Bits & Bolts, in einer Remote-Variante. Wer es ausprobieren will, installiert es aus dem Plugin-Verzeichnis und öffnet anschließend die „Parts Library“ in der Seitenleiste – dort liegt die Bauteilbibliothek, mit der die weiteren Beispiele arbeiten. Eine Bauteilbibliothek mit Vorschaubildern, Dateiansichten und Suchfunktion zeigt jede der vier Erweiterungen in einem realistischen Zusammenhang.
Ein Beispiel, das alle Erweiterungen gleichzeitig verwendet, zwingt die Autoren zu einer konsistenten Schnittstelle und zeigt Entwicklern, wie sich die Teile zusammensetzen. Wer ein eigenes Plugin plant, kann sich an dieser Struktur entlanghangeln statt jede Entwurfsentscheidung allein zu treffen.
Das Beispiel ist kein Katalog von Endpunkten und keine Referenz aller möglichen Parameter. Das Repository bleibt beim Prinzip „zeigen statt auflisten“. Die Details liegen in der Spezifikation, auf die der letzte Abschnitt verweist.
SDKs, Registry und der Weg von der Idee zum Plugin
Der Einstieg ist in vier Schritte gegliedert, und der erste verlangt kein eigenes Projekt: erst ausprobieren, dann bauen. Für den Bau verweist das Repository auf die allgemeine Plugin-Dokumentation; sobald ein Plugin existiert, kommen die SDKs hinzu. Für TypeScript heißt das Paket @openai/mcp-extensions und ist für MCP-Server und Apps gedacht, für Python heißt es openai-mcp-extensions und richtet sich an Server.
Die Sprachverteilung im Repository passt dazu: rund 62,7 Prozent TypeScript, 30,6 Prozent Python, dazu kleinere Anteile CSS, JavaScript und HTML. Wer ChatGPT Plugins entwickeln will, findet also beide gängigen Wege vorbereitet. Die Releases für Node und Python stehen jeweils bei 0.1.0.
Für die Verteilung spielt die MCP Registry eine Rolle, jener Ort, an dem sich externe Tools integrieren und auffindbar machen lassen. Der Weg: Plugin bauen, SDK einbinden, über die Registry verfügbar machen, im Verzeichnis installieren. Wer täglich mit GitHub Copilot arbeitet, kennt das Muster Kontext, Werkzeug, Ausführung – hier in der Gegenrichtung. Nicht der Assistent greift auf deinen Code zu, sondern dein Dienst greift in die Oberfläche des Assistenten.
Version 0.1.0, Apache 2.0 und ein Blick in die Historie
Zwölf Commits, drei Releases, drei Mitwirkende: Das Repository ist jung, und die Historie verrät, woran gerade gearbeitet wird. Die jüngsten Einträge datieren auf den 29. und 30. September 2026. Der letzte Commit betrifft die Spezifikation: Die Abschnitte zu MCP Apps wurden an eine stabile Fassung gebunden, während der Entwurf gepinnt bleibt.
Die Autoren unterscheiden hier zwischen dem, was schon verlässlich ist, und dem, was sich noch bewegt – inklusive Sicherheitsarbeit an Dateiimporten und Grenzen für Speicherzuweisungen. Wer darauf plant, sollte die Spezifikation als Vertrag lesen, nicht als Handbuch.
Die Lizenz ist Apache 2.0, also offen und für kommerzielle Nutzung geeignet. Bei 539 Sternen und 25 Forks ist Aufmerksamkeit vorhanden, die Verbreitung aber noch überschaubar. So sehen Schnittstellen oft aus, wenn sie gerade erst definiert werden.
Was das konkret bedeutet
Für Entwickler ändert sich die Frage am Anfang. Statt „welche Funktionen stelle ich bereit?“ lautet sie nun „an welcher Stelle der Oberfläche soll mein Dienst auftauchen?“ Dieser Entwurfsgedanke entscheidet früh über den Erfolg eines Plugins – früher als jede API-Dokumentation.
Für Nutzer bleibt die Wirkung unsichtbar, bis sie plötzlich fehlt. Ein Plugin mit Seitenleisteneintrag, eigenem Dateibetrachter und durchsuchbaren Ressourcen fühlt sich nicht wie eine Erweiterung an, sondern wie ein Teil des Programms.
Wer heute baut, baut auf einer frühen Version. Die SDKs stehen bei 0.1.0, die Spezifikation unterscheidet stabil und Entwurf, und die MCP Apps Dokumentation wird laufend nachgezogen. Experimentieren lohnt sich, feste Zusagen gibt es noch nicht.
Quelle: github.com
