Activepieces 0.93.0, publicado el 8 de noviembre de 2026, permite que un flujo se conecte a un servidor MCP protegido con OAuth 2.0 sin introducir manualmente el identificador y el secreto del cliente, siempre que el servicio exponga los metadatos necesarios. Quien configura la conexión solo introduce la dirección del servidor y aprueba el acceso. Este cambio simplifica la configuración de flujos y resulta especialmente útil para quienes quieren que un agente trabaje con herramientas externas. La actualización también modifica el entorno predeterminado en el que se ejecutan los pasos de código.
El lanzamiento está documentado en las notas oficiales de Activepieces en GitHub. La propuesta técnica del 22 de septiembre describe la función y muestra una prueba local con el servidor MCP de Aleph. Las dos fuentes cubren fases distintas: la implementación se integró el 18 de octubre y se distribuyó en la versión publicada el 8 de noviembre.
El cliente se conecta a servicios externos
MCP, sigla de Model Context Protocol, permite que un programa descubra e invoque herramientas expuestas por otro servicio. El cliente es el programa que inicia la conexión; el servidor es el que pone las herramientas a disposición. En esta actualización, Activepieces actúa como cliente. La conexión en sentido inverso, en la que un asistente externo utiliza las herramientas que Activepieces expone a través de su propio servidor MCP, es una función distinta.
Para entender la diferencia, conviene partir del tipo de acción que necesita el flujo. Con un servicio MCP, la automatización invoca una función declarada por el servidor, por ejemplo una búsqueda en un archivo de documentos. Un proyecto como agent-desktop de Vercel Labs aborda otro escenario: interactuar con la interfaz de una aplicación. En la versión de Activepieces, el objetivo es el acceso a herramientas ya expuestas por un servidor, sin pasar por la interfaz del servicio en cada operación.
De la dirección al consentimiento
La propuesta en GitHub describe un obstáculo concreto. Algunos servidores requieren OAuth pero no proporcionan al usuario un identificador y un secreto para copiar en la configuración del cliente. Activepieces ha añadido el descubrimiento automático de metadatos de autorización para cubrir este caso. Si la información necesaria está disponible, la dirección del servidor es el único dato que el colaborador tuvo que introducir manualmente en la prueba documentada.
El botón de conexión abre una ventana de autorización. Desde allí, el usuario puede conceder el acceso; según la especificación MCP, el cliente utiliza un token para las solicitudes al servicio protegido. Separar la identidad con la que parte la solicitud de las funciones que el servicio permite usar tiene una utilidad práctica. También en el caso del agente Gemini, la identidad operativa y el perímetro de permisos son dos aspectos distintos. Una conexión que requiere menos configuración deja abierta la elección de qué funciones autorizar.
Leer y modificar son permisos distintos
Imaginemos un flujo que busca un documento para responder una consulta interna. Para completar esa tarea necesita leer los contenidos relevantes. La posibilidad de modificar o eliminar documentos cambiaría el alcance de la conexión, aunque el procedimiento de configuración fuera idéntico. La especificación MCP permite a los servidores indicar los ámbitos de autorización: lo que se puede solicitar y obtener depende de cómo esté configurado el servicio.
Una forma de evaluar la actualización es comparar la tarea del flujo con las herramientas que quedan disponibles tras el consentimiento. En los test en los que Anthropic limitó el acceso a Internet, las herramientas concedidas eran una variable concreta del comportamiento observado. El contexto de Activepieces es diferente. La pregunta operativa es la misma: si la automatización toma una iniciativa inesperada, ¿qué operaciones puede ejecutar realmente? La respuesta depende también de los controles del servicio, además de las instrucciones dadas al agente.
La prueba documenta un caso compatible
En la prueba local con Aleph, el colaborador mostró la selección de OAuth 2.0, la apertura de la ventana de autorización y el posterior descubrimiento y llamada de las herramientas. La prueba documenta ese recorrido con un servicio específico. Las notas de lanzamiento no incluyen una lista de servidores verificados ni datos sobre los tiempos de configuración en entornos distintos. Una organización puede reproducir el caso de uso en sus propios servidores, incluidos los que requieren pasos de registro o configuraciones adicionales.
Esta distinción también importa al leer la documentación de otras herramientas. En el prototipo de agente para GitHub y Feishu, el punto de partida son las integraciones declaradas por el proyecto. Aquí el software se distribuye en una versión pública, mientras que el comportamiento de la conexión sigue dependiendo del servicio que se conecta. El dato más útil para quien gestiona varios flujos es saber qué endpoints llegan desde la configuración al primer uso sin pasos manuales adicionales.
Deno cambia el entorno predeterminado para los pasos de código
El changelog de Activepieces indica que los pasos de código pasan a usar Deno como entorno de ejecución predeterminado. El cambio afecta al punto en que un flujo ejecuta código personalizado. Puede ser relevante incluso para quienes no usan MCP: el nuevo valor predeterminado es una razón para revisar los scripts con independencia de las conexiones configuradas. Las notas también mencionan un ajuste para que el código CommonJS preexistente funcione bajo Deno; no publican una verificación de todos los scripts de los usuarios.
Para quien gestiona la instalación, una comprobación sensata es ejecutar los flujos más utilizados en un entorno de prueba y comparar los resultados. Conviene observar los imports, las dependencias y la forma en que aparecen los errores. Son controles sobre el software que ejecuta el flujo, distintos de la elección del modelo que guía un agente. Un resultado diferente tras la actualización debe rastrearse hasta el paso que lo produce, antes de atribuirlo al modelo o a la conexión.
Activepieces 0.93.0
- Confirmado: lanzamiento del 8 de noviembre con OAuth 2.0 en el cliente MCP y Deno como entorno predeterminado para los pasos de código.
- No indicado: una lista completa de servidores compatibles.
- A seguir: comportamiento de los flujos activos y permisos efectivamente concedidos por las nuevas conexiones.
La perspectiva más amplia
Básicamente, la ventaja de esta versión se mide en el momento en que una conexión pasa a ser reutilizable. Quien crea un flujo puede partir de la dirección de un servidor compatible y autorizarlo; quien gestiona el servicio conserva la responsabilidad de decidir qué herramientas exponer. Esta distinción gana peso cuando los agentes trabajan en segundo plano, porque una conexión puede invocarse también después de la primera interacción que la configuró, como ocurre en escenarios donde los agentes operan de forma autónoma.
Los próximos datos útiles son concretos: conexiones exitosas con servidores distintos al de la prueba, renovación y revocación de autorizaciones en condiciones de uso reales, y resultados consistentes de los scripts tras el cambio de runtime. Estos elementos ayudarían a entender cuánto trabajo de configuración se elimina realmente. Para quienes usan Activepieces, la prueba más informativa es el propio flujo: debe obtener los datos que necesita y conservar el perímetro de acceso previsto.
