Activepieces 0.93.0, veröffentlicht am 8. November 2026, ermöglicht es einem Workflow, sich mit einem OAuth-2.0-geschützten MCP-Server zu verbinden, ohne Client-ID und Client-Secret manuell einzutragen, sofern der Dienst die erforderlichen Metadaten bereitstellt. Wer die Verbindung konfiguriert, gibt die Server-URL ein und bestätigt den Zugriff. Die Änderung vereinfacht die Einrichtung von Workflows, die einen Agenten mit externen Werkzeugen koppeln sollen. Das Update ändert außerdem die Standardlaufzeitumgebung für Code-Schritte.
TL;DR: Activepieces 0.93.0 (8. November 2026) ergänzt den MCP-Client um OAuth-2.0-Unterstützung: Bei kompatiblen Servern reicht die URL für die Autorisierung. Deno löst die bisherige Standardlaufzeitumgebung für Code-Schritte ab.
Das Release ist in den offiziellen Versionshinweisen von Activepieces auf GitHub dokumentiert. Der technische Vorschlag vom 22. September beschreibt die Funktion und zeigt einen lokalen Test mit dem MCP-Server von Aleph. Beide Quellen schildern unterschiedliche Phasen: Die Implementierung wurde am 18. Oktober integriert und mit der am 8. November veröffentlichten Version ausgeliefert.
Der MCP-Client verbindet sich mit externen Diensten
MCP, kurz für Model Context Protocol, ermöglicht es einem Programm, Werkzeuge zu entdecken und aufzurufen, die ein anderer Dienst bereitstellt. Der Client ist das Programm, das die Verbindung initiiert; der Server stellt die Werkzeuge zur Verfügung. In diesem Update agiert Activepieces als Client. Die umgekehrte Richtung, bei der ein externer Assistent die Werkzeuge nutzt, die Activepieces über den eigenen MCP-Server bereitstellt, ist eine separate Funktion.
Um den Unterschied zu verstehen, hilft ein Blick auf die Art der Aktion, die ein Workflow benötigt. Bei einem MCP-Dienst ruft die Automatisierung eine vom Server deklarierte Funktion auf, zum Beispiel eine Suche in einem Dokumentenarchiv. Ein Projekt wie agent-desktop von Vercel Labs adressiert einen anderen Fall: die Interaktion mit der Benutzeroberfläche einer Anwendung. Beim Activepieces-Release geht es um den Zugriff auf bereits vom Server bereitgestellte Werkzeuge, ohne für jede Operation die Dienstoberfläche zu durchlaufen.
Von der URL zur Autorisierung
Der Vorschlag auf GitHub beschreibt ein konkretes Problem. Manche Server setzen OAuth voraus, stellen dem Nutzer aber keine Client-ID und kein Client-Secret zum Eintragen in die Client-Konfiguration bereit. Activepieces hat dafür die automatische Erkennung von Autorisierungsmetadaten eingeführt. Sind die notwendigen Informationen verfügbar, war die Server-URL das einzige Feld, das der Mitwirkende im dokumentierten Test manuell ausfüllen musste.
Der Verbindungsbutton öffnet ein Autorisierungsfenster. Dort kann der Nutzer den Zugriff erteilen; laut MCP-Spezifikation verwendet der Client danach ein Token für Anfragen an den geschützten Dienst. Es ist sinnvoll, die Identität, mit der eine Anfrage gestartet wird, von den Funktionen zu trennen, die der Dienst erlaubt. Die Trennung von Identität und Berechtigungsumfang ist dabei kein technisches Detail, sondern eine bewusste Designentscheidung. Auch im Fall des Gemini-Agenten sind operative Identität und Berechtigungsrahmen zwei getrennte Aspekte. Eine Verbindung, die weniger Konfiguration erfordert, lässt dennoch die Wahl offen, welche Funktionen autorisiert werden sollen.
Lesen und Schreiben sind verschiedene Berechtigungen
Nehmen wir einen Workflow, der ein Dokument sucht, um eine interne Frage zu beantworten. Dafür benötigt er Lesezugriff auf relevante Inhalte. Die Möglichkeit, Dokumente zu ändern oder zu löschen, würde den Umfang der Verbindung erheblich erweitern, selbst wenn die Konfigurationsprozedur identisch wäre. Die MCP-Spezifikation erlaubt es Servern, Autorisierungsbereiche anzugeben: Was angefordert und erhalten werden kann, hängt von der Konfiguration des Dienstes ab.
Ein sinnvoller Bewertungsansatz ist der Vergleich der Workflow-Aufgabe mit den nach der Zustimmung verfügbaren Werkzeugen. Bei den Tests, bei denen Anthropic den Internetzugang eingeschränkt hat, waren die gewährten Werkzeuge eine konkrete Variable des beobachteten Verhaltens. Der Kontext von Activepieces ist anders. Die operative Frage bleibt dieselbe: Wenn die Automatisierung eine unerwartete Initiative ergreift, welche Operationen kann sie tatsächlich ausführen? Die Antwort hängt neben den Anweisungen an den Agenten auch von den Einstellungen des Dienstes ab.
Der Test dokumentiert einen kompatiblen Anwendungsfall
Im lokalen Test mit Aleph zeigte der Mitwirkende die Auswahl von OAuth 2.0, das Öffnen des Autorisierungsfensters und die anschließende Erkennung sowie den Aufruf der Werkzeuge. Der Test dokumentiert diesen Ablauf mit einem bestimmten Dienst. Die Release-Hinweise liefern keine Liste verifizierter Server und keine Daten zu Konfigurationszeiten in anderen Umgebungen. Eine Organisation kann den Anwendungsfall daher auf den eigenen Servern nachbilden, einschließlich solcher, die Registrierungsschritte oder zusätzliche Einstellungen erfordern.
Diese Unterscheidung ist auch beim Lesen der Dokumentation anderer Werkzeuge relevant. Beim Agenten-Prototyp für GitHub und Feishu bilden die vom Projekt deklarierten Integrationen den Ausgangspunkt. Hier ist die Software als öffentliches Release verteilt, während das Verbindungsverhalten weiterhin vom anzubindenden Dienst abhängt. Für Nutzer, die mehrere Workflows verwalten, ist die nützlichste Information, welche Endpunkte sich beim ersten Einsatz ohne zusätzliche manuelle Schritte konfigurieren lassen.
Deno wird Standard für Code-Schritte
Konkret: das Changelog von Activepieces gibt an, dass Code-Schritte auf Deno als Standard-Laufzeitumgebung umgestellt werden. Die Änderung betrifft den Punkt, an dem ein Workflow benutzerdefinierten Code ausführt. Sie kann auch für Nutzer relevant sein, die MCP nicht verwenden: Der Wechsel des Standards gibt Anlass, Skripte unabhängig von den konfigurierten Verbindungen zu überprüfen. Die Versionshinweise erwähnen auch eine Anpassung, damit bestehender CommonJS-Code unter Deno funktioniert; eine Prüfung aller Nutzerskripte ist darin nicht enthalten.
Wer die Installation verwaltet, sollte die meistgenutzten Workflows in einer Testumgebung ausführen und die Ausgaben vergleichen. Zu beobachten sind Imports, Abhängigkeiten und die Art, wie Fehler auftreten. Das sind Prüfungen der Software, die den Workflow ausführt. Sie sind getrennt von der Wahl des Modells, das einen Agenten steuert. Ein abweichendes Ergebnis nach dem Update sollte auf den verursachenden Schritt zurückgeführt werden, bevor es dem Modell oder der Verbindung zugewiesen wird.
Activepieces 0.93.0 in Kürze
- Bestätigt: Release vom 8. November mit OAuth 2.0 im MCP-Client und Deno als Standard für Code-Schritte.
- Nicht angegeben: eine vollständige Liste kompatibler Server.
- Zu beobachten: Verhalten der aktiven Workflows und tatsächlich gewährte Berechtigungen der neuen Verbindungen.
Die größere Einordnung
Der Vorteil dieses Releases zeigt sich in dem Moment, in dem eine Verbindung wiederverwendbar wird. Wer einen Workflow erstellt, kann von der URL eines kompatiblen Servers ausgehen und diesen autorisieren; wer den Dienst betreibt, behält die Aufgabe, zu entscheiden, welche Werkzeuge er bereitstellt. Diese Unterscheidung gewinnt an Bedeutung, wenn Agenten im Hintergrund arbeiten, da eine Verbindung auch nach der ersten Interaktion, die sie eingerichtet hat, erneut aufgerufen werden kann.
Die nächsten aussagekräftigen Rückmeldungen sind konkret: erfolgreiche Verbindungen mit anderen Servern als dem im Test verwendeten, Erneuerung und Widerruf von Autorisierungen unter realen Nutzungsbedingungen sowie konsistente Skriptergebnisse nach dem Laufzeitwechsel. Diese Erkenntnisse würden zeigen, wie viel Konfigurationsaufwand tatsächlich entfällt. Für Activepieces-Nutzer ist der aussagekräftigste Test der eigene Workflow: Er muss die benötigten Daten abrufen und den vorgesehenen Zugriffsbereich einhalten.
