The request usually arrives from one team. Support wants Claude to read Zendesk. Two weeks later finance wants ChatGPT near NetSuite, and legal has questions about both. You are now picking a shape you will have to defend in a year.
Elaichi vs Merge Agent Handler is a choice between two shapes, not two versions of one product. Elaichi is a governed MCP control plane. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps Merge Agent Handler is not in the dated vendor notes this blog is allowed to cite, so nothing here is stated as a fact about how it behaves. What follows are the three forks in the road, the Elaichi side of each in detail, and the questions to ask.
Elaichi vs Merge Agent Handler: what this post can state as fact
| Row | Elaichi | Merge Agent Handler |
|---|---|---|
| Address model (fork one) | One org-wide POST /mcp endpoint behind OAuth; every AI client points at the same address |
Put to the vendor: how many endpoints exist at 200 employees, and who creates each one |
| Credential shape (fork two) | Client holds an OAuth grant only; per-account secrets sit in a separate credential service, AES-256-GCM at rest | Put to the vendor: what the client stores, and whether any part of it is long-lived |
| Connector authorship (fork three) | Elaichi authors and serves 450+; custom or forked connectors via JSON config, with a review surface for upstream changes | Put to the vendor: who writes the connectors, and who fixes one when the upstream API changes |
| Audit | One row per call attempt names the connection actually reached; argument names and counts logged, values never; free read-only Auditor seat | Put to the vendor: is the record one entry per attempt, and does it name the connected account reached |
| Offboarding | Grant revocation effective on the next call; preflight refuses removal until personal connections are transferred or deleted | Put to the vendor: is removal effective by cache invalidation or by transaction, and what happens to personal connections |
| Pricing | Gold at $15 per user per month or $120 per user per year; 14-day trial with no card; free-seat roles excluded from the billable count | Put to the vendor: which billing unit (seats, tool calls or tasks) |
Nothing about Merge Agent Handler, as a statement of fact. A claim about a named vendor only appears in an Elaichi post when it comes from that vendor's own page, with the date the page was read. The checked set covers Zapier MCP, Composio, MintMCP, Lunar.dev, Tyk, Zuplo and Kong, all checked September 2026. Merge Agent Handler is not in it. Its product page is merge.dev/merge-agent-handler (checked September 2026), and nothing on it is restated here.
Borrow the same constraint for your own evaluation. Most comparison pages on this query were written by one of the two vendors, or by neither. Read the product documentation instead of the grid. A vendor whose docs answer the address question, the credential question and the connector-provenance question in plain language can be evaluated in an afternoon.
Fork one: is the address per user or per organization?
Elaichi gives the whole organization one address. Every SaaS account is connected once, and the tools those accounts expose are served through one organization-wide MCP endpoint, POST /mcp, standard MCP over Streamable HTTP and JSON-RPC 2.0, behind OAuth. There are no per-toolbox URLs and no embedded tokens. There is no MCP server to create, list or revoke per person. What varies between members is the grant, not the address.
That shows up at rollout and again at offboarding. Claude, ChatGPT and Cursor can each be pointed at the same URL through their own admin console. Adding a fourth MCP client is the same shape, not a fresh project.
The recognizable alternative is one server per member. Zapier documents that model and recommends it: "Give each user their own server and token rather than sharing one" (Zapier MCP rollout docs, checked September 2026). Composio's MCP Gateway page describes a per-team endpoint, SSO authenticated (Composio MCP Gateway, checked September 2026). Both are built for a different reader, and both multiply the number of things you track. The arithmetic of one endpoint against one per user is worked through on its own. Ask Merge Agent Handler how many addresses exist at 200 employees, and who creates each one.
Fork two: what does the AI client actually hold?
With Elaichi, the client holds an OAuth grant and nothing else. OAuth is the sign-in handshake that gives an application limited access without handing over a password. No token is embedded in a URL, and no secret sits in a client config file.
Revocation follows from that. The grant's revoked_at field is re-read from the organization store on every single call, with no cache. removing or suspending a member revokes every live grant in the same transaction as the membership change, so the next call is already blocked. Role changes and restriction changes work differently. They resolve through a short cache and take effect within about two minutes.
Connector credentials never live in Elaichi. A separate credential service holds per-account secrets, AES-256-GCM at rest, and owns refresh. A failed refresh marks the connection needs_reauth rather than failing quietly. A connect URL is a one-time session carrying no token, which is why it is safe to return over MCP. An organization can also supply its own OAuth app per connector, gated on connector:manage rather than connection:manage.
The contrast worth testing is a long-lived string in a config file. Zapier's own docs say a connection token is long-lived, tied to one server, and "grants whoever holds it the ability to run the server's tools" (how connections work, checked September 2026). Ask Merge Agent Handler what the client stores, and what happens to it when the holder leaves.
Fork three: who writes the connectors you depend on?
Elaichi authors, maintains and serves its connectors from its own infrastructure, 450+ today. Your company does not run MCP servers, and Elaichi does not wrap a registry of servers other people run. When a connector breaks, there is one party to fix it.
Custom work has a path. A connector can be authored from JSON config, or forked from a public connector, and a fork can pull upstream changes through a review surface that separates new tools, safe updates, config diffs, conflicts and upstream removals. Conflicts and destructive removals stay unchecked by default. connector:create is flagged high trust, because a custom connector can be pointed at any destination.
The trade-off, stated plainly: if the app you need is not in the catalog, somebody has to author or fork it. A vendor that lists servers other people publish may show that app on its site today, and whether it works next month depends on whoever publishes it. Pick the failure mode you would rather own. The managed versus run-it-yourself cost breakdown covers the third option.
Roles, restrictions and frozen arguments
Access in Elaichi is three layers, kept separate on purpose. Permissions are about 38 action strings grouped into roles, and a member holds exactly one role, enforced by a unique index. Sharing is one grant of view, use or edit on a resource to a user, a team or the whole organization, and a member sees only what they own or what was shared with them. Restrictions decide which connectors and which individual tools a target may reach.
Restriction targets are role or user only. restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. The organization default is the absence of any rule, which means allow everything. A rule on a user replaces the role rules for that user rather than adding to them Within the winning layer, blocks always beat allows, and an allow rule that names nothing denies everything. Blocks match the tool name or the pinned operation. Allows match the pinned operation only, because an advertised name is a label the governed party can edit. The name against pinned operation rule explains the asymmetry.
Frozen parameters handle the narrower case where one argument must not move. Frozen keys are stripped from the advertised schema, so the model never sees them, and frozen values are merged over caller arguments at execution. Passing the key cannot un-freeze it.
What the model sees, and in what order
Past a threshold of 30 tools, the connected tools collapse behind two meta-tools, search_tools and execute_tool. The threshold counts catalog operations and connected tools together, and the control-plane catalog alone is dozens of operations, so one connected app is normally enough to trip it. Control-plane operations stay listed individually. execute_tool is only a naming indirection and falls through the identical gates.
Ranking is lexical over tool name, description and connector label, with a relevance floor: a tool must account for at least half the query's own IDF-weighted mass. Without a floor a search always returns something, and something from an app you did not ask about is worse than nothing, because the model calls it. The reasoning behind the floor sets out the incident that produced it.
What the audit trail records after a tool call
one entry per tool-call attempt, succeeded or failed, and both name the account actually reached, taken from the execution rather than the intent. Argument names and counts are recorded. Argument values never are. actor_kind is a recorded field with values including ai_assistant, so an AI action is marked at the point of action instead of guessed later from a user agent.
Two error strings exist per failed call. The one returned to the caller is derived from the third party's response body and is never written anywhere else. The one written to the audit trail is never derived from the request or the response, because audit records are organization-visible and fanned out to whatever SIEM the customer configured. Export to Datadog is implemented; Splunk HEC and Microsoft Sentinel are accepted but not yet delivering. The trail is append-only and eventually consistent, so a row may take a moment to appear. The read-only Auditor seat is free, so a compliance reviewer does not consume a license.
One honest limit. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What holds on the endpoint is role checks per operation, the forbidden classification, output redaction, OAuth scope limits and full audit logging.
What happens when somebody leaves
removing or suspending a member revokes every live grant in the same transaction as the membership change, so the departing person's next call fails. The cleanup around it is the part that usually gets missed.
Elaichi runs an offboarding preflight. A personal connection referenced by a toolbox entry, where a toolbox is a named set of configured tools, has to be resolved first: transferred to the organization, a team or another member, or deleted. Otherwise the removal is refused. Unreferenced personal connections are cleaned up. A private connection is not transferable at all, because a credential only its owner could ever use does not become somebody else's. Delegated toolbox entries surface as a non-blocking warning, and re-pinning is the fix. The contractor offboarding sequence walks through a live case.
Residency, sign-in and the four onboarding paths
Elaichi has three regions, chosen at organization creation: eu, us and apac. The eu and us regions are hard residency, a Cloudflare Durable Object jurisdiction, so compute and storage both stay in that jurisdiction. The apac region is a placement hint (best-effort). Only eu and us are hard-residency. Region also selects which regional log instance holds the audit trail.
Sign-in covers Google, GitHub and Microsoft, email codes, TOTP MFA with single-use recovery codes, and passkeys. SAML and OIDC SSO are built in-house, with SCIM v2 for users and groups and group-to-role mapping. Onboarding has four paths: emailed single-use invite links with roles and teams pre-assigned, verified-domain auto-join with a configurable default role, SCIM provisioning, and just-in-time SSO.
Where a different shape is the better buy
Sometimes the other product wins, and saying so saves a procurement cycle. If the job is pulling your customers' data into your own product, that is a unified API problem rather than an employee access problem, and Elaichi is the wrong tool for it.
If your engineers need per-user sessions in application code, rather than employees working inside Claude, look at a developer-first product. Composio's homepage names both end users and developers building agents (composio.dev, checked September 2026), and there is a side-by-side with Composio here.
If two people in one team need one app, buy nothing yet. The case for holding off on a gateway is real, and a control plane over a single connection is overhead with a monthly bill. The two plans are Gold and Black, with a 14-day trial. Gold is $15 per user per month, or $120 per user per year, and the 14-day trial starts without a credit card.
Questions to put to Merge Agent Handler before you sign
Write these down and send them. The answers are more useful than any comparison table, this one included.
- How many endpoints exist for a 200-person company, and who creates each one?
- What does the AI client store, and is any part of it long-lived?
- When a person is removed, how long until their next tool call fails, and is that a cache or a transaction?
- Who authors the connectors, and who fixes one when the upstream API changes?
- Is the audit record one entry per tool-call attempt, and does it name the connected account reached?
- Can residency be pinned to a jurisdiction for compute and storage both?
- Is SSO over SAML and OIDC included, with SCIM provisioning and group-to-role mapping?
- What is the billing unit: seats, tool calls, or tasks?
A one-week evaluation two people can run
Pick one team and one app, then give it a week and two people, an IT owner and one person from that team. Support with Zendesk works. So does sales with Salesforce.
Run the same script against each vendor. The point is not to see whether a read call succeeds, because both will manage that. The point is to see what breaks when a person leaves, and what the record shows afterwards.
Where this leaves you
Three forks decide the outcome: one address or many, a grant or a stored secret, and connectors from the vendor or from a registry. Everything else is a feature list that will have changed by the time you renew.
The other vendor comparisons run the same structure against named products. Check the connector catalog for the apps your teams actually use, and the team use cases page for what a first rollout looks like.
