The way enrichment fits into a workflow has changed. For most of the last decade, "connect your enrichment tool to your stack" meant one thing: build a Zap, set up a Make scenario, or write a webhook. You'd chain apps together, pass data between them, and your enrichment ran as one node in a larger automation.
This shift is usually framed as a rivalry, which misreads what's actually happening. AI-native tools like MCP and Clay's Sculptor get framed either as iPaaS (Integration Platform as a Service) replacements or dismissed as toys. Both miss the point. The same enrichment data is now flowing through two structurally different distribution channels, and which one matters more depends on who your customer is and where they look for tools.
That model still works, and millions of workflows run this way.
But a second model has emerged, and it's structurally different. When you give Claude or Cursor an MCP server, you're handing it a tool to call rather than configuring a pipeline to follow.
Two eras with the same goal, reached through very different paths to distribution.
Era 1: Workflow automation and built-in distribution
Zapier, Make, n8n, Workato, Pipedream, Activepieces, Node-RED. These platforms share a common model: triggers and actions. Something happens, something else follows. Enrichment fits in as an action: "when a lead is created, enrich their profile."
The workflow model also has an advantage that's easy to overlook: marketplaces are distribution channels. A listing in the Workato adapter library, a published app on Pipedream, a package on the n8n node registry. These go beyond technical endpoints. They're placements in ecosystems where your next customer is already browsing.
Each listing also brings backlinks, a category page, and a slot in the platform's internal search, so it accumulates credibility before a single user has touched the integration.
This is why iPaaS integrations punch above their weight early on. The marketplace does the distribution work. You show up where buyers are already looking, without needing to earn their attention from scratch.
Enrich Layer has live integrations across the major iPaaS platforms:
- native npm packages for n8n and Node-RED
- a community adapter on Workato
- and published apps on Pipedream and Zapier
Each one is a technical connection and a presence in a marketplace.
Era 2: AI-native tooling and emerging ecosystems
MCP (Model Context Protocol) is a different kind of integration. Instead of configuring a pipeline, you give an AI client a set of tools it can call. When Cursor or Claude needs a company profile mid-task, it calls the enrichment tool directly with no predetermined trigger or fixed flow.
Clay's Sculptor follows the same pattern: instead of writing a static formula, you describe what you want in natural language, and Sculptor recommends which enrichments to run and in what order.
OpenClaw extends this further. You install the Enrich Layer skill on an agent, and 25 enrichment tools become part of that agent's capability set via ClawHub.
The distribution here is earlier-stage but directionally the same. MCP registries, agent skill marketplaces, and npm packages for AI tooling are becoming the new discovery layer, the places developers look when they're equipping an agent. Being present in those ecosystems now builds the same kind of low-friction credibility that iPaaS marketplace listings built five years ago.
However, MCP-era discovery is still immature. Today, iPaaS marketplaces still drive most enterprise integration discovery. There’s no equivalent of "Zapier app of the week" in the MCP world yet. Agent skill hubs are smaller and lack the SEO surface of established platforms, and the registries themselves are inconsistent in how they curate or rank tools.
The distribution exists in principle. In practice, though, it's a wager on where developers will be looking in eighteen months — not a channel you can rely on for top-of-funnel today.
Why both eras matter, and why they're not competing
These two models serve different buyers through different channels. RevOps teams building outbound sequences find Enrich Layer in the Zapier app directory. Developers building AI research assistants find it in MCP registries or on npm. The data underneath is the same, and the discovery path and consumption pattern are different.
Treating them as competing paradigms is a mistake. All you need to ask is, "Where does enrichment need to happen in your workflow today, and where will your customers look for it when their stack shifts?"
In both eras, the integration that lives in a marketplace inherits the platform's existing user base as top-of-funnel, and that lift is hard to replicate from scratch. Whether the marketplace is Zapier's app directory or an AI agent skill hub, the distribution surface is most of the work, and the integration is just the artifact that occupies it.
It's tempting to assume the AI-native era will decentralize distribution the way it decentralized tooling. So far it hasn't. Discovery is concentrating in a handful of MCP registries and skill hubs that are already settling into the same gatekeeping role the iPaaS marketplaces have held for years. The technology is new, but the constraint is old: you still have to be found where your buyers already look, and a small number of platforms still decide who gets seen.
Enrich Layer is built for both
Enrich Layer's MCP server is a first-class integration alongside our other distribution channels, not a wrapper over a Zapier-shaped product. The same API that powers Zapier actions powers the MCP tools. The same credit system, rate limits, and data apply whether you're calling enrichment from a Zap or from a Claude tool call.
That cuts both ways for us. Today, the iPaaS side is where our distribution actually pays off. Our MCP server is ready and first-class, but MCP-era discovery is not yet a channel we can lean on for new demand either.
You can start with iPaaS today and benefit from the marketplace distribution that comes with it.
