Activepieces 0.93.0, released on November 8, 2026, lets a workflow connect to an OAuth 2.0-protected MCP server without manually entering a client ID and secret, provided the service exposes the necessary metadata. The person configuring the connection enters the server URL and approves access. It's a meaningful shift in how flows are set up, particularly useful for anyone running agents that interact with external tools. The update also changes the default runtime environment for code steps.
The release is documented in Activepieces' official GitHub release notes. A technical proposal dated September 22 describes the feature and shows a local proof-of-concept using the Aleph MCP server. The two sources cover different phases: the implementation was merged on October 18 and shipped in the November 8 release.
The Client Connects to External Services
MCP, short for Model Context Protocol, allows one program to discover and invoke tools exposed by another service. The client is the program that initiates the connection; the server is the one that makes the tools available. In this update, Activepieces acts as the client. The reverse direction, where an external assistant uses tools that Activepieces exposes through its own MCP server, is a separate capability.
To understand the distinction, start from the type of action the flow needs to perform. With an MCP service, the automation calls a function declared by the server, for example a search across a document archive. A project like Vercel Labs' agent-desktop addresses a different scenario: interacting with an application's graphical interface. In the Activepieces release, the focus is on accessing tools already exposed by a server, without going through the service's interface for every individual operation.
From URL to Consent
The GitHub proposal identifies a specific obstacle. Some servers require OAuth but don't provide the user with a client ID and secret to paste into the client configuration. Activepieces added automatic discovery of authorization metadata to cover this case. Where the necessary information is available, the server URL was the only value the contributor had to enter manually in the documented proof-of-concept.
The connect button opens an authorization window. From there, the user can grant access; per the MCP specification, the client uses a token for subsequent requests to the protected service. Separating the identity behind the request from the functions the service permits is a meaningful design choice. Even in the Gemini agent case, operational identity and permission scope are two distinct concerns. A connection that requires less configuration still leaves the choice of which functions to authorize fully in the user's hands.
Read and Write Are Different Permissions
Consider a flow that searches a document to answer an internal query. Completing that task requires reading relevant content. The ability to modify or delete documents would change the scope of the connection, even if the setup procedure were identical. The MCP specification allows servers to declare authorization scopes: what can be requested and obtained depends on how the service is configured.
One practical way to evaluate the update is to compare the flow's intended task with the tools that become available after consent. In tests where Anthropic restricted internet access, the tools granted were a concrete variable in the observed behavior. The Activepieces context is different. The operational question is the same: if the automation takes an unexpected action, what operations can it actually execute? The answer depends on the service's own controls, not only on the instructions given to the agent.
The Test Documents a Compatible Case
In the local proof-of-concept with Aleph, the contributor demonstrated selecting OAuth 2.0, opening the authorization window, and then discovering and calling the available tools. The test documents that path with one specific service. The release notes do not include a list of verified servers or any data on configuration times across different environments. An organization can therefore reproduce the use case against its own servers, including those that require registration steps or additional settings.
That distinction matters when reading documentation for other tools as well. In the DeepSeek agent prototype for GitHub and Feishu, the starting point is the integrations declared by the project. Here the software ships in a public release, while connection behavior remains tied to the specific service being connected. For teams managing multiple flows, the most useful signal is knowing which endpoints reach first use from configuration without extra manual steps.
Deno Becomes the Default for Code Steps
The Activepieces changelog states that code steps now use Deno as the default execution environment. The change affects any point in a flow where custom code runs. It's relevant even for teams not using MCP: the new default is a reason to review scripts independently of whatever connections are configured. The release notes also mention a fix to make pre-existing CommonJS code run under Deno; they do not include a verified audit of all user scripts.
For anyone managing an installation, a sensible check is to run the most frequently used flows in a staging environment and compare outputs. Watch for differences in imports, dependencies, and how errors surface. These are checks on the software executing the flow, separate from the choice of model driving the agent. If an output changes after the update, trace it to the specific step causing it before attributing the difference to the model or the connection.
Activepieces 0.93.0 at a Glance
- Confirmed: November 8 release with OAuth 2.0 in the MCP client and Deno as the default for code steps.
- Not specified: a complete list of compatible servers.
- To monitor: behavior of active flows and permissions actually granted by new connections.
The Bigger Picture
The real value of this release becomes visible when a connection becomes reusable. Someone building a flow can start from a compatible server's URL and authorize it; the team managing the service retains responsibility for deciding which tools to expose. That distinction gains weight when agents run in the background, because a connection can be invoked again well after the initial interaction that set it up.
The concrete signals to watch for next are straightforward: successful connections with servers beyond the proof-of-concept, token renewal and revocation behaving correctly under real usage conditions, and consistent script results after the runtime switch. Those data points would show how much configuration overhead the update actually removes. For Activepieces users, the most informative test is the flow you already rely on: it should retrieve the data it needs and stay within its intended access boundary.
