Activepieces: a TypeScript piece framework that doubles as an MCP server catalogue

The packaging model is the actual product

Most automation platforms treat integrations as rows in a vendor database. Activepieces treats them as TypeScript npm packages. The README states that pieces are npm packages written in TypeScript, published to npmjs.com under the @activepieces scope, and that the repository holds the integration source. That single decision changes what you can do with an integration: you can read it, fork it, pin a version, and run it locally with hot reloading during development, which the README lists as a feature for local piece development. The README also states that around 60% of pieces are contributed by the community, which is a statement about governance rather than a quality metric. The audience here is a team with at least one TypeScript developer who is tired of waiting on a vendor's integration backlog. A non-technical operator gets the no-code builder, but the escape hatch when a connector misbehaves is code, and that escape hatch only exists for people who can open the package.

How a piece becomes an MCP server

The README makes a specific claim: when you contribute pieces to Activepieces they become automatically available as MCP servers that you can use with LLMs through Claude Desktop, Cursor or Windsurf. It describes the collection as the largest open source MCP toolkit and puts the count at 280+ pieces in one place and roughly 400 MCP servers in the repository description. Those two numbers do not agree, and the README does not explain the gap, so treat the figure as approximate. The mechanism implied by the material is that the piece definition is the single source of truth: one TypeScript package declares an action, and the same declaration is surfaced both to the visual builder and to an MCP client. That is a coherent design, because it means an integration author writes the action once. What the README does not describe is the transport, the authentication handshake between the MCP client and a self-hosted instance, or how credentials for a piece are supplied when the caller is an LLM rather than a flow. Those are the questions to answer before pointing an agent at a production instance.

Builder features and the human-in-the-loop pieces

The builder checklist in the README covers loops, branches, auto retries, an HTTP step, a code step with NPM, and versioned flows. Two entries deserve attention. First, the code step runs with NPM, which means a flow can pull dependencies at runtime; that is convenient and it is also a supply chain surface you now own. Second, the README frames human-in-the-loop as ordinary pieces rather than a special subsystem: delay execution for a period of time or require approval, and it notes that you can build many pieces like that on top of the piece framework. Built-in human input triggers named in the README are a Chat Interface and a Form Interface. Treating approvals as pieces is the more interesting choice, because it means an approval gate is versioned and reviewable like any other integration rather than being a platform setting you cannot inspect. The README also mentions an ASK AI option inside the code piece, aimed at non-technical users cleaning data without writing code.

Deployment and what the README does not pin down

The README links to a deploy page at activepieces.com/docs/install/overview and states that the platform is self-hosted and can be network-gapped. It does not contain install commands, a docker compose file, or environment variable names, so this review cannot give you a copy-pasteable setup. What it does give you is the shape of the thing: a TypeScript monorepo with a packages directory, a separate packages/ee directory for enterprise code, and pieces distributed through npm. The practical consequence is that upgrades are not a single button. You are tracking a repository whose recent releases include both a stable line and an unstable line, and the supplied release list shows hotfix builds alongside a version explicitly tagged Unstable. If you self-host, you are choosing which of those lines you follow, and you are the one reconciling a piece version bump against a flow that depends on it. The README's claim of frequent releases is consistent with that release list; it is also the reason a pinned version matters more here than on a hosted product.

Licensing is split, and the split is the constraint

The repository metadata reports a NOASSERTION licence, while the README states that the Community Edition is released under the MIT license and that enterprise features are released under a Commercial License, pointing at packages/ee/LICENSE. Both statements can be true at once: the top-level licence file may not be machine-classifiable, and the project is deliberately dual-licensed by directory. For anyone evaluating this, the directory boundary is the thing to inspect. If the capability you need lives under packages/ee, MIT does not cover it, and the README points to a pricing page for the feature comparison rather than listing the split inline. This is not legal advice and the licences themselves are the authority; the point is that a single licence badge on a README does not describe a repository with two licences inside it. Budget review time for that boundary before a procurement conversation, not after.

Where a self-hosted builder is the wrong tool

The README leans on self-hosting and network-gapping as security properties, and for some organisations that is exactly right. It is the wrong choice in three situations. If nobody on the team will own a TypeScript monorepo, the extensibility that justifies the project becomes dead weight, and you have taken on upgrade work in exchange for a feature you never use. If your integrations are the long tail of internal, undocumented systems, the 200+ public pieces do not help you and you are writing pieces anyway, at which point you are maintaining a framework and an automation platform simultaneously. If you need a vendor to answer for an outage in a connector, a community-contributed npm package is not that. The README's own framing, that developers set up the tools and anyone in the organisation can then use the no-code builder, quietly assumes the first group exists. Without it, the second group has no one to call when a piece breaks.

How this differs from n8n

The repository topics list n8n-alternative, and n8n is the obvious comparison. The difference in approach is where integrations live. n8n ships nodes inside its own repository and its own release cycle, so a connector arrives when the project ships it. Activepieces pushes each integration out as a separately versioned npm package, which the README says is published directly to npmjs.com upon contribution. That means an integration can be updated, pinned or forked without waiting for a platform release, and it means the integration surface is a dependency graph you manage. The trade-off runs the other way too: a node bundled in a platform release is tested against that release, while a piece version is something you align yourself. The README's hot reloading claim for local piece development is the developer-experience payoff of that model. If you would rather not think about package versions at all, the bundled approach is less work.

Who should adopt it, and what to check first

Adopt Activepieces if you have TypeScript engineers who want to own their integrations as code, and if self-hosting is a requirement rather than a preference. The MIT Community Edition plus a separately licensed packages/ee directory is a workable arrangement for a team that reads licences before it deploys. Do not adopt it if you want a hosted product with a support contract covering every connector, or if the MCP angle is the only reason you are here, because the README describes the MCP exposure in a paragraph and leaves the operational detail to the docs site. Before you commit, do three things: confirm which capabilities sit under packages/ee rather than the MIT tree, check that the specific pieces you need exist as published @activepieces packages on npmjs.com, and decide whether you are tracking the stable release line or the one tagged Unstable, because that choice determines your upgrade cadence and the README does not make it for you.

Editorial conclusion

Adopt Activepieces if you want automation logic expressed as versioned npm packages and you are willing to run the stack yourself; the README positions the Community Edition under MIT and the enterprise features under a separate commercial licence in packages/ee/LICENSE, so check which package you are actually deploying before you plan a rollout. Skip it if you need a vendor to hold the pager for your integrations. Verify first that the pieces you depend on are published on npmjs.com under the @activepieces scope and that the MCP surface you intend to expose to an LLM is one you can audit.

Official sources

1. activepieces/activepieces on GitHub
2. Issues
3. Project website
4. README
5. Releases