Why people search for pipedream mcp alternatives
The usual trigger is a change of scope. One developer wired Pipedream into their own AI client, it worked, and now ten people in support and finance want the same thing. At that point the questions stop being about connectors and start being about identity. Whose account does the call run as, who decided that person could run it, and where is the record afterwards? That is the shape behind most searches for pipedream mcp alternatives, and it is a different purchase from the one the developer made.
So this post does two things. It states what Pipedream's own pages say about its gateway product, with dates, and it says where Elaichi fits for a team that needs per-person access and an audit trail now. Elaichi is a governed MCP control plane: MCP is the Model Context Protocol, the way an AI client such as Claude, ChatGPT or Cursor discovers and runs tools.
What Pipedream's own pages say about Conduit
| Where connectors come from | How a person signs in | How access is restricted | What the audit record holds | How it is hosted | |
|---|---|---|---|---|---|
| Pipedream Conduit | Not on the pages we checked | OIDC single sign-on (Okta, Entra, Google, custom issuer) | Policies by workspace, group or user, down to one tool; enforced on every listing and call | Pages differ: "drill into the exact payload" on one, "no tool arguments or results" on another | Conduit Cloud, or self-hosted on your own infrastructure |
| Composio | Composio-managed app integrations, plus custom MCP servers | SSO verifies the user before any tool resolves | Permissions per user and per role, down to a single action | MCP Gateway page: metadata, not payloads; retention 7 days to 1 year | Composio Cloud, customer VPC, or fully self-hosted |
| Zapier MCP | Zapier's own apps and actions | OAuth from the client, or a connection token | App and action restrictions apply account-wide, not to MCP alone | Tool calls per user in the History tab and the account audit log | Zapier-hosted; data stored in AWS US-East 1 |
| Elaichi | Connectors Elaichi authors and runs, native MCP connectors, and your own remote MCP server | OAuth grant per person at one address, https://api.elaichi.ai/mcp | Role and member restrictions on connectors and tools, checked on every call | Person, tool, connector, connection, approval, surface, MCP client, outcome | Hosted; no self-hosted build |
The vendor cells come from each vendor's own pages, checked October 2026: pipedream.com/connect, pipedream.com/conduit, pipedream.com/docs/conduit/configure/access-control, pipedream.com/docs/conduit/configure/sso, pipedream.com/docs/conduit/cloud, composio.dev/mcp-gateway, composio.dev/enterprise, docs.zapier.com/mcp/overview/how-connections-work and docs.zapier.com/mcp/manage/security. Where a cell reads "Not on the pages we checked", those pages said nothing about it.
Pipedream's Connect page labels Conduit "For companies · Early access". It describes Conduit as a gateway that lets employees safely connect their apps to AI agents. The same description names SSO, access policies, per-user permissions and a full audit trail, managed in one place (checked October 2026, pipedream.com/connect). Early access is the vendor's own label, not a characterization. It is the first thing to put in front of a security reviewer, because it tells them what kind of commitment they are evaluating.
The Conduit documentation is specific about enforcement. Pipedream's access-control docs say "A user's allow set is the union of every policy that applies to them; a user no policy applies to has no access". The same page says "Policy is enforced on every tool listing and every tool call" (checked October 2026, pipedream.com/docs/conduit/configure/access-control). The Conduit page says "Policies grant connectors to the entire workspace, select groups, or individual users, down to the individual tool" (checked October 2026, pipedream.com/conduit).
Single sign-on is documented too. Pipedream's Conduit single sign-on docs say Conduit signs users in through any OIDC-compliant identity provider, naming Okta, Microsoft Entra, Google or a custom issuer (checked October 2026, pipedream.com/docs/conduit/configure/sso). On credentials, the Conduit page says "End-user credentials are held by the gateway and never exposed to the LLM or the client" (checked October 2026, pipedream.com/conduit).
That is a real feature set, described by the vendor. Read it as what Pipedream is building for, not as a gap list.
What else is usually on the same shortlist
Two other products are worth reading alongside Conduit, and both document their own shape.
Composio's MCP Gateway page gives each team its own MCP endpoint, one URL per team. That endpoint is scoped to the tools the team is permitted to use, with SSO verifying the user before any tool resolves (checked October 2026, composio.dev/mcp-gateway). Composio's Enterprise page says admins set permissions per user and per role, down to a single action. The same Enterprise page says those rules are evaluated in the request path before the model is involved (checked October 2026, composio.dev/enterprise). On audit, the MCP Gateway page says tool-call payloads are not stored, that audit records hold metadata rather than payloads, and that the retention window is configurable from 7 days to 1 year. Composio's Enterprise page states it differently, saying payload retention is configured per project (checked October 2026, composio.dev/enterprise). Ask Composio which page describes the build you would be on. If one endpoint per team is a problem for your client rollout, that is the other detail to weigh.
Zapier takes a different shape again. Zapier's connections page defines a Zapier MCP connection as one MCP client linked to one MCP server on the person's Zapier account. Each named MCP client gets its own server (checked October 2026, docs.zapier.com/mcp/overview/how-connections-work). Zapier's security page says app and action restrictions are not currently configurable for Zapier MCP alone: a restriction applies account-wide across Zapier features (checked October 2026, docs.zapier.com/mcp/manage/security). A side-by-side of those two sits in Composio vs Zapier MCP for company use.
Does Pipedream price Conduit?
Not on its pricing page. Pipedream's pricing page prices Connect usage: it says "Credits measure Connect API usage", that building is "Free to build. Pay when your integrations go to production", and it lists "100 users included, then $2 per user" on its Startup plan (checked October 2026, pipedream.com/pricing). Conduit pricing is not documented on that page.
There is a separate figure on the Conduit side. Pipedream's Conduit Cloud docs say "Conduit Cloud is free for up to 100 users" and "You can also self-host Conduit on your own infrastructure" (checked October 2026, pipedream.com/docs/conduit/cloud). If your finance team needs a line item for next year, that is the question to put to Pipedream directly rather than infer from the Connect meter.
One more detail worth catching before a reviewer catches it for you. Pipedream's Conduit page says its audit trail lets you "drill into the exact payload", while its access-control docs say "Usage stores no tool arguments or results" (checked October 2026, pipedream.com/conduit and pipedream.com/docs/conduit/configure/access-control). Ask which page describes the build you would be on.
What a team should check before choosing
Work through these in order. Each one has an answer in a vendor's own documentation or it does not, and "does not" is itself the finding.
- Maturity label. Is the gateway generally available or early access, in the vendor's own words? Write the label and the date into your evaluation.
- Whose identity runs the call. Does each employee authorize their own connection, or does one person's credential serve the team? This determines whether the app on the other end sees the right human.
- Where policy is evaluated. On the listing only, or on every call? A listing filter hides a tool; a call-time check refuses it.
- What the audit record holds. Actor, tool, app, account, client, outcome. Then ask about arguments and results explicitly, since vendors differ and pages within one vendor can differ.
- Retention. How long is history kept, and can you forward it to your own log service?
- Offboarding. When someone leaves the identity provider, what stops working, and when?
- Pricing surface. Which product does the published pricing meter, and is the gateway on it?
A team already comfortable with its single-developer setup, running one or two servers for one or two people, does not need any gateway yet. When you don't need an MCP gateway yet is the honest version of that case, and it is a common place to land.
Where Elaichi fits
Elaichi serves MCP at one address, https://api.elaichi.ai/mcp, the same string for every organization. Claude, ChatGPT and Cursor all sign in there with OAuth. Which organization, which person and which tools a client reaches comes from the OAuth grant behind its token, not from the URL. So there is no per-person or per-team address to issue, rotate or chase.
Each person connects their own client and approves their own grant on Elaichi's consent screen, and every call made with that grant's tokens acts as the person who approved it. Permissions are looked up on each request rather than frozen into the token. Where the app on the other end should see the employee, the tools run on that employee's own connections.
Access is governed in three layers that stay separate. Permissions say what a role lets a member do; Elaichi's catalog holds 58 of them, and a member holds exactly one role. Sharing says who may use a given connection, toolbox or template. Restrictions say which connectors and tools a role or a member may reach. They are enforced at every point a member can reach a tool, not only at listing. That covers browsing connectors, connecting an account, advertising tools to a client, executing a call, and the final outbound-request guard. Roles, Restrictions and ACLs in MCP walks the three layers in detail.
Every call that reaches execution is written to the organization's audit log. The row names the person, the tool, the connector, the connection it reached, how approval was given and the surface it came from. For an MCP client it names that client too. Elaichi keeps 90 days of audit history. For longer, forward it to your own log service: export to your own Datadog comes with the Black plan.
The trade-offs, stated plainly
Elaichi is hosted. There is no self-hosted build, so a team whose requirement is "runs inside our own VPC" should weigh Pipedream's self-host option, which its Conduit Cloud docs document, against that. MCP data residency: self-hosted vs managed sets out how to decide.
Elaichi has two plans, Gold and Black, and both are paid. An organization without an active plan is locked, and its MCP endpoint answers 403 until someone subscribes. Every new organization starts on a 14-day Black trial, no credit card to start. Buying Gold sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two, while buying Black charges immediately. A workspace that buys nothing moves to the free Personal plan.
Some things take a moment. A role, team, restriction or access-grant change reaches every point of presence within about two minutes. Revoking a grant, removing or suspending a member, revoking a share and disconnecting an account are all effective on the next call.
If you are still comparing
Put the same seven questions to every vendor on your list and record the answer with its date. Best MCP gateways for company-wide AI access covers the wider field, and What is an MCP gateway? separates the four shapes these products take, which is usually what makes two quotes look incomparable. If your next step is practical rather than comparative, the connector catalog shows what Elaichi already reaches.
