# Elaichi vs Merge Agent Handler: three forks

> Elaichi vs Merge Agent Handler comes down to three forks: one address or many, a grant or a stored secret, and who authors the connectors.

**TL;DR** Elaichi vs Merge Agent Handler turns on three forks: the address your AI clients point at, what each client holds, and who writes the connectors. Elaichi answers with one organization-wide MCP endpoint behind OAuth, a grant per member, and 500+ connectors it authors itself. Merge's product page describes Agent Handler as a way to securely connect agents to thousands of third-party tools while managing and monitoring their interactions. Its answers to the three forks are questions to put to Merge, and this post lists them.

Elaichi vs Merge Agent Handler turns on three forks: the address, what the AI client holds, and who writes the connectors. Elaichi's answers are one organization-wide MCP endpoint, an OAuth grant per member, and connectors it authors itself. Merge describes Agent Handler as a way to "securely connect your agents to thousands of third-party tools, while managing and monitoring all tool interactions" ([merge.dev](https://www.merge.dev/merge-agent-handler), checked October 2026). Its answers to the three forks are not on record here, so this post puts each one to Merge as a question.

The request usually arrives from one team. Support wants Claude to read Zendesk. Two weeks later finance wants ChatGPT near Xero, 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: what can be compared?

Every Elaichi row below can be stated from the product itself. Every Merge row is a question. This blog states a named vendor's behavior only from that vendor's own page, with the date it was read. For Agent Handler that is one line on [Merge's product page](https://www.merge.dev/merge-agent-handler) (checked October 2026). Elaichi is a governed MCP control plane. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

| Row | Elaichi | Merge Agent Handler |
| --- | --- | --- |
| Address model (fork one) | One organization-wide `POST /mcp` endpoint behind OAuth; every AI client points at the same address | Ask Merge: how many endpoints exist at 200 employees, and who creates each one |
| Credential shape (fork two) | The client holds an OAuth grant only; per-account secrets sit in a separate credential service, AES-256-GCM at rest | Ask Merge: what the client stores, and whether any part of it is long-lived |
| Connector authorship (fork three) | Elaichi authors and serves 500+ connectors; custom or forked connectors via JSON config, with a review surface for upstream changes | Ask Merge: who writes the connectors, and who fixes one when the upstream API changes |
| Audit | Keeps one entry per tool-call attempt, succeeded or failed, naming the account reached; logs argument names and counts, and never argument values; free read-only Auditor seat | Ask Merge: is the record one entry per attempt, and does it name the connected account reached |
| Offboarding | Grant revocation effective on the next call; a preflight refuses removal until personal connections are transferred or deleted | Ask Merge: is removal effective by cache expiry or by transaction, and what happens to personal connections |
| Pricing | Per user: Gold lists at $15 per user per month in USD, or $120 per user per year ([pricing](/pricing/)); 14-day trial | Ask Merge: which billing unit, whether seats, tool calls or tasks |

Borrow the same rule for your own evaluation. Read each vendor's product documentation rather than a comparison grid, this one included. A vendor whose docs answer the address, credential and connector questions 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 its tools are served through one organization-wide MCP endpoint, `POST /mcp`, behind OAuth. It speaks standard MCP over Streamable HTTP and JSON-RPC 2.0. The MCP specification defines that transport as one HTTP POST per message to a single endpoint ([MCP transports](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports)). There are no per-toolbox URLs and no embedded tokens. There is no MCP server to create, list or revoke per person, so what varies between members is the grant, not the address.

That shows up at rollout. An admin adds the URL once where the client allows it, and each member then connects and signs in with their own grant. In Claude Team or Enterprise an owner adds it under Organization settings > Connectors, while on Pro or Max each person adds it under Customize > Connectors ([Anthropic's guide](https://support.claude.com/en/articles/11175166)). Cursor's admin MCP allowlist is Enterprise only and "does not push it to users' machines", so each developer adds it in their own Cursor ([Cursor's docs](https://cursor.com/docs/enterprise/model-and-integration-management)). ChatGPT's steps are in [connecting Elaichi to ChatGPT](/blog/connect-elaichi-to-chatgpt/). A fourth MCP client is the same shape, not a fresh project.

Other shapes multiply what sits behind the address. Zapier MCP gives every client the same endpoint, but "Each MCP client gets its own MCP server", so each member holds one server per client. For clients that use a connection token, Zapier says to "give each user their own server and token rather than sharing one" ([how Zapier MCP connections work](https://docs.zapier.com/mcp/overview/how-connections-work), checked October 2026). Composio's MCP Gateway page says "each team gets its own MCP endpoint carrying only the tools it is permitted to use" ([Composio MCP Gateway](https://composio.dev/mcp-gateway), checked October 2026). Both are built for a different reader, and both multiply the things you track. The [arithmetic of one organization server against one per member](/blog/zapier-mcp-alternative/) is worked through on its own. Ask Merge 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. The MCP authorization spec makes the server an OAuth 2.1 resource server, and it says access tokens "MUST NOT be included in the URI query string" ([MCP authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)). Elaichi embeds no token in its 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. In Elaichi, 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 and restriction changes work differently. They resolve through a short cache and take effect within about two minutes.

Connector credentials never live in Elaichi. Per-account secrets sit in a separate credential service, encrypted with AES-256-GCM at rest, and that service 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 to test is a long-lived string in a config file. For clients outside its supported list, and for code, Zapier MCP uses a connection token. Zapier's docs say that token is long-lived, tied to one server, and "grants whoever holds it the ability to run the server's tools" ([how connections work](https://docs.zapier.com/mcp/overview/how-connections-work), checked October 2026). Ask Merge what the AI 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, 500+ of them. 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. 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. The `connector:create` permission 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. Merge's page counts its tools in the thousands ([merge.dev](https://www.merge.dev/merge-agent-handler), checked October 2026). Ask Merge who writes them, and who fixes one when the upstream API changes. The [managed versus run-it-yourself cost breakdown](/blog/self-hosted-mcp-servers-vs-control-plane/) covers the third option.

## Who decides which tools each person can use?

Admins do, through three layers Elaichi keeps 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. Members see their own resources and the ones shared with them, and nothing else. Restrictions decide which connectors and which individual tools a target may reach.

In Elaichi, restriction targets are role or user only; the organization default is the absence of a 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. One trap: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. A block can catch a tool by its name or by the operation behind it. An allow counts only the operation, because a tool's displayed name is a label the governed party can edit. The [name against operation rule](/blog/block-matches-name-allow-matches-operation/) explains the asymmetry.

Frozen parameters handle the narrower case where one argument must not move. A frozen key is removed from the schema the model is shown, and its value is merged over whatever the caller sends at execution. Passing the key cannot unfreeze it. In Elaichi, a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself.

## Which tools does the model see?

Control-plane operations, such as managing members or connections, are listed individually. App tools are handled differently: connected tools are never listed one by one, however few there are. The model looks a tool up through `search_tools` and calls it through `execute_tool`, which is only a naming indirection. It unwraps to the same name and arguments and falls through the identical gates.

Ranking is lexical over tool name, description and connector label, with a floor on relevance. A tool must account for at least half of the query's weight, where rarer words weigh more. 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](/blog/search-tools-ranking-floor-idf/) sets out the incident that produced it.

## What does the audit trail record after a tool call?

Elaichi's trail holds one entry per tool-call attempt, succeeded or failed. The account on each entry is the one the call actually reached, taken from the execution rather than the intent. The trail logs argument names and counts, and never argument values. Each entry also records the surface, `mcp`, and the OAuth client, with Claude, ChatGPT and Cursor marked verified. The call is recorded under the person who signed in, so the client is known 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. In Elaichi, export to your own Datadog comes with the Black plan, which is launching soon. Splunk HEC and Microsoft Sentinel are accepted as destinations, but Elaichi delivers events only to Datadog. 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 a role check per operation, the `forbidden` classification, output redaction, OAuth scope limits and full audit logging.

## How fast does access end when somebody leaves?

On the next call. In Elaichi, 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. It is 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 cannot be transferred to anyone, 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 the entry is the fix. The [contractor offboarding sequence](/blog/offboarding-when-the-agent-holds-access/) walks through a live case.

## Where is data held, and how do people sign in?

Elaichi has three regions, chosen at organization creation: `eu`, `us` and `apac`. In each, the organization's data store and connector credentials stay in that region, encrypted at rest with AES-256-GCM. Every request and tool call runs there too, so the credential is read and the third-party app is called from inside the region.

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.

## When is a different product 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. Ask Merge whether Agent Handler is built for agents your own product ships, or for employees working in their own AI clients.

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 addresses developers building agents, and its docs describe an SDK with per-user sessions and managed auth ([composio.dev](https://composio.dev), [docs.composio.dev](https://docs.composio.dev), checked October 2026). There is a [side-by-side with Composio](/blog/elaichi-vs-composio/) here.

If two people in one team need one app, buy nothing yet. The case for [holding off on a gateway](/blog/when-you-dont-need-an-mcp-gateway/) is real, and a control plane over a single connection is overhead with a monthly bill. When the time comes, Gold lists at $15 per user per month in USD, and the [pricing page](/pricing/) shows the price for your region.

## What should you ask Merge before you sign?

Write these down and send them. The answers are more useful than any comparison table, this one included.

- Is Agent Handler built for agents your product ships to customers, or for employees working in Claude, ChatGPT and Cursor?
- 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 you choose a region that holds the data store, the credentials and the calls?
- 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?

## How can two people evaluate both in a week?

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](/blog/sales-team-chatgpt-salesforce-accounts/).

Run the same script against each vendor. The point is not to see whether a read call succeeds, because any working product manages that. The point is to see what breaks when a person leaves, and what the record shows afterwards.

## What decides the choice in the end?

Three forks decide it: 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](/blog/category/comparisons/) run the same structure against named products. Check the [connector catalog](/connectors/) for the apps your teams actually use, and the [team use cases](/use-cases/) page for what a first rollout looks like.

## FAQ

### What does Merge say Agent Handler does?

Merge's product page describes Agent Handler as a way to "securely connect your agents to thousands of third-party tools, while managing and monitoring all tool interactions" (https://www.merge.dev/merge-agent-handler, checked October 2026). That is the one statement about it this blog makes. Its address model, what an AI client stores and who authors its connectors are questions to put to Merge directly.

### How many MCP endpoints does Elaichi create for a company?

One. Elaichi serves every connected SaaS account through a single organization-wide MCP endpoint, POST /mcp, using standard MCP over Streamable HTTP and JSON-RPC 2.0, behind OAuth. There are no per-toolbox URLs, no embedded tokens, and no per-user MCP server to create or revoke. Claude, ChatGPT, Cursor, any MCP client, and the Elaichi Agent point at that one address, and each member connects once and signs in with their own grant.

### How quickly does revoking someone's access take effect in Elaichi?

It depends on what changed. Grant revocation, member removal and member suspension are effective on the next call, because the grant's revoked_at field is re-read from the organization store on every call with no cache, and removing or suspending a member revokes every live grant in the same transaction as the membership change. Role changes and restriction changes resolve through a short cache and take effect within about two minutes.

### Who writes the connectors that Elaichi serves?

Elaichi authors, maintains and serves them from its own infrastructure, 500+ of them. It is not a registry of MCP servers published by other people, and customer companies do not run MCP servers themselves. An organization can also author a custom connector from JSON config, or fork a public one and pull upstream changes through a review surface that separates new tools, safe updates, config diffs, conflicts and upstream removals.

### What does Elaichi cost, and is there a trial?

Elaichi has two plans, Gold and Black. Gold lists at $15 per user per month in USD, or $120 per user per year, and https://elaichi.ai/pricing/ shows the price for your region. Gold starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. Billable seats are active memberships with a minimum of one. Suspended members and the free-seat roles, Guest, Billing Admin and the read-only Auditor, are not counted.

## Read next

- [Elaichi vs Composio: who writes your connectors?](/blog/elaichi-vs-composio/) — Elaichi vs Composio: Elaichi writes its own connectors and serves them on one company-wide MCP endpoint. Composio covers more apps, with an endpoint per team.
- [Claude and ChatGPT connectors vs one MCP endpoint](/blog/elaichi-vs-native-ai-connectors/) — Claude and ChatGPT connectors fit one client and a few apps. Once a second client repeats the setup, one governed MCP endpoint costs less to run.
- [Lunar MCPX alternative: count your servers first](/blog/lunar-mcpx-alternative-governed-access/) — With no MCP servers to front, the Lunar MCPX alternative is a hosted server like Elaichi. With several, a gateway like MCPX still fits.