Con Activepieces 0.93.0, pubblicato l’8 novembre 2026, un flusso può collegarsi a un server MCP protetto da OAuth 2.0 senza inserire a mano l’identificativo e il segreto del client, se il servizio rende disponibili le informazioni necessarie. Chi configura la connessione inserisce l’indirizzo del server e approva l’accesso. È un cambiamento nella configurazione dei flussi, utile a chi vuole far lavorare un agente con strumenti esterni. L’aggiornamento cambia anche l’ambiente predefinito in cui vengono eseguiti i passaggi di codice.
Il rilascio è documentato nelle note ufficiali di Activepieces su GitHub. La proposta tecnica del 22 settembre descrive la funzione e mostra una prova locale con il server MCP di Aleph. Le due fonti raccontano fasi diverse: l’implementazione è stata integrata il 18 ottobre e distribuita nella versione pubblicata l’8 novembre.
Il client si collega a servizi esterni
MCP, sigla di Model Context Protocol, permette a un programma di scoprire e richiamare strumenti esposti da un altro servizio. Il client è il programma che avvia il collegamento; il server è quello che rende disponibili gli strumenti. In questo aggiornamento Activepieces agisce come client. Il collegamento in direzione opposta, in cui un assistente esterno usa gli strumenti che Activepieces espone tramite il proprio server MCP, è una funzione distinta.
Per capire la differenza, si può partire dal tipo di azione che serve al flusso. Con un servizio MCP, l’automazione richiama una funzione dichiarata dal server, per esempio una ricerca in un archivio di documenti. Un progetto come agent-desktop di Vercel Labs affronta un altro caso: interagire con l’interfaccia di un’applicazione. Nel rilascio di Activepieces il punto è l’accesso a strumenti già esposti da un server, senza passare dall’interfaccia del servizio per ogni operazione.
Dall’indirizzo al consenso
La proposta su GitHub descrive un ostacolo preciso. Alcuni server richiedono OAuth ma non mettono a disposizione dell’utente un identificativo e un segreto da copiare nella configurazione del client. Activepieces ha aggiunto la scoperta automatica dei metadati di autorizzazione per coprire questo caso. Se le informazioni necessarie sono disponibili, l’indirizzo del server è l’unico dato che il contributore ha dovuto compilare a mano nella prova documentata.
Il pulsante di connessione apre una finestra di autorizzazione. Da lì l’utente può concedere l’accesso; secondo la specifica MCP, il client usa un token per le richieste al servizio protetto. È utile separare l’identità con cui parte la richiesta dalle funzioni che il servizio consente di usare. Anche nel caso del Gemini agent l’identità operativa e il perimetro dei permessi sono due aspetti distinti. Un collegamento che richiede meno configurazione lascia comunque aperta la scelta di quali funzioni autorizzare.
Leggere e modificare sono permessi diversi
Immaginiamo un flusso che cerca un documento per rispondere a una domanda interna. Per completare quel compito gli serve la lettura dei contenuti pertinenti. La possibilità di modificare o cancellare documenti cambierebbe la portata del collegamento, anche se la procedura per configurarlo fosse identica. La specifica MCP consente ai server di indicare gli ambiti di autorizzazione: ciò che si può richiedere e ottenere dipende da come è configurato il servizio.
Un modo per valutare l’aggiornamento è confrontare il compito del flusso con gli strumenti che risultano disponibili dopo il consenso. Nei test in cui Anthropic ha limitato l’accesso a Internet, gli strumenti concessi erano una variabile concreta del comportamento osservato. Il contesto di Activepieces è diverso, ma la domanda operativa è la stessa: se l’automazione prende un’iniziativa inattesa, quali operazioni può effettivamente eseguire? La risposta dipende anche dai controlli del servizio, oltre che dalle istruzioni date all’agente.
Il test documenta un caso compatibile
Nella prova locale con Aleph, il contributore ha mostrato la selezione di OAuth 2.0, l’apertura della finestra di autorizzazione e la successiva scoperta e chiamata degli strumenti. Il test documenta quel percorso con un servizio specifico. Le note di rilascio non forniscono un elenco di server verificati né dati sui tempi di configurazione in ambienti diversi. Un’organizzazione può quindi riprodurre il caso d’uso sui propri server, compresi quelli che richiedono passaggi di registrazione o impostazioni aggiuntive.
È la distinzione che conta anche quando si legge la documentazione di altri strumenti. Nel prototipo di agente per GitHub e Feishu, il punto di partenza sono le integrazioni dichiarate dal progetto. Qui il software è distribuito in una release pubblica, mentre il comportamento della connessione resta legato al servizio da collegare. Il riscontro più utile per chi gestisce più flussi è sapere quali endpoint arrivano dalla configurazione al primo uso senza passaggi manuali aggiuntivi.
Deno cambia il default per gli step di codice
Il changelog di Activepieces indica che gli step di codice passano a Deno come ambiente di esecuzione predefinito. La modifica riguarda il punto in cui un flusso esegue codice personalizzato. Può avere importanza anche per chi non usa MCP: il cambio di default dà un motivo per controllare gli script indipendentemente dalle connessioni configurate. Le note riportano anche un intervento per far funzionare sotto Deno codice CommonJS preesistente; non pubblicano una verifica di tutti gli script degli utenti.
Per chi gestisce l’installazione, un controllo sensato è eseguire i flussi più usati in un ambiente di prova e confrontare gli output. Vanno osservati gli import, le dipendenze e il modo in cui emergono gli errori. Sono controlli sul software che esegue il flusso, distinti dalla scelta del modello che guida un agente. Un esito diverso dopo l’aggiornamento va ricondotto al passaggio che lo produce, prima di attribuirlo al modello o alla connessione.
Activepieces 0.93.0 in sintesi
- Confermato: rilascio dell’8 novembre con OAuth 2.0 nel client MCP e Deno come default per gli step di codice.
- Non indicato: un elenco completo dei server compatibili.
- Da seguire: comportamento dei flussi in uso e permessi effettivamente concessi dalle nuove connessioni.
La lettura più grande
La nostra lettura è che il vantaggio della release si misuri nel momento in cui una connessione diventa riutilizzabile. Chi crea un flusso può partire dall’indirizzo di un server compatibile e autorizzarlo; chi gestisce il servizio conserva il compito di decidere quali strumenti esporre. La stessa distinzione acquista peso quando gli agenti lavorano in background, perché una connessione può essere richiamata anche dopo la prima interazione che l’ha configurata.
I prossimi riscontri utili sono concreti: collegamenti riusciti con server diversi da quello della prova, rinnovo e revoca delle autorizzazioni nelle condizioni d’uso reali, e risultati coerenti degli script dopo il cambio di runtime. Questi elementi aiuterebbero a capire quanto del lavoro di configurazione venga davvero eliminato. Per chi usa Activepieces, il test più informativo è il proprio flusso: deve ottenere i dati che gli servono e conservare il perimetro di accesso previsto.
