Sixth workstream, and an explicit goal: our flow builder should be at least as usable from an AI agent as n8n's is.
n8n exposes three distinct things, and we should match all three:
- An MCP server for building flows — list, read, create, update and validate flows over MCP, so an agent can author automation the same way a person does on the canvas. n8n ships this and it is a large part of why n8n shows up in agent workflows at all.
- An MCP Client step — a flow step that calls an external MCP server's tools, making any MCP server reachable as a flow action. This is also the cheapest possible answer to the integrations question: every MCP server becomes usable without us writing a connector.
- An MCP Server trigger — expose a flow itself as an MCP tool, so an agent can invoke a flow as an action.
What we already have
OpenRegister has MCP tool providers (IMcpToolProvider, discovered by FQCN), and hermiq has MCP run infrastructure. The work is exposing the flow surface through them, not building MCP from scratch.
Why this matters strategically
If our flows are authored and invoked by agents as easily as n8n's, the "we already use n8n" objection weakens considerably — and (2) means choosing us costs a client no integration reach.
Depends on #2064.
Sixth workstream, and an explicit goal: our flow builder should be at least as usable from an AI agent as n8n's is.
n8n exposes three distinct things, and we should match all three:
What we already have
OpenRegister has MCP tool providers (
IMcpToolProvider, discovered by FQCN), and hermiq has MCP run infrastructure. The work is exposing the flow surface through them, not building MCP from scratch.Why this matters strategically
If our flows are authored and invoked by agents as easily as n8n's, the "we already use n8n" objection weakens considerably — and (2) means choosing us costs a client no integration reach.
Depends on #2064.