# Merge Agent Handler alternatives for employee AI

> Merge Agent Handler alternatives differ on five things: sign-in, endpoint shape, tool-level rules, audit detail, and per-seat versus per-call pricing.

**TL;DR** Merge Agent Handler alternatives differ on five things: per-person sign-in, endpoint shape, tool-level restrictions, audit detail, and per-call versus per-seat pricing. Merge's own page describes Agent Handler as a platform for securely connecting AI agents to enterprise tools at scale. It is priced on usage and free to start. Elaichi is a governed MCP control plane for employees reaching their own company's apps, priced per seat.

## Why do people search for Merge Agent Handler alternatives?

Most people arrive at this comparison from the wrong direction. They read that Merge Agent Handler connects AI agents to enterprise tools. They are trying to connect their own employees' AI clients to their own company's apps. Those are not the same job. Most searches for Merge Agent Handler alternatives are really a search for the second one. Elaichi does that second job: one MCP address, each person signing in as themselves, and rules written on roles.

[Merge's own FAQ](https://merge.dev/merge-agent-handler) describes Agent Handler as a platform for securely connecting AI agents to enterprise tools at scale. It names production-grade connectors, built-in authentication and observability tooling (checked October 2026). The same page documents SCIM-based provisioning, DLP scanning and policy guardrails, and a searchable audit trail. It also documents installation as a remote MCP server with user-created Tool Packs, and usage-based pricing that is free to start (merge.dev, checked October 2026). Both products ship real controls. The difference is the job you are doing.

The job this post compares is the narrower one. A company hands its own staff one address and one set of rules for the tools that company itself runs. The identity on every call is an employee, not a customer tenant. Test each option against the five forks below, and put anything a public page does not settle to the vendor directly.

MCP, the [Model Context Protocol](https://modelcontextprotocol.io/), is the open standard that lets an AI client call tools on a server. Both products speak it. What matters is what sits behind it: identity model, endpoint topology, rule granularity, audit schema, and how the bill is computed.

## The five forks at a glance

Five things separate the two shapes: who the call acts as, how many endpoints exist, how finely a rule can bind, what an audit row holds, and how the bill is computed. The rows below map to the sections that follow, in the same order. Where a Merge cell reads "Ask Merge", put the question to Merge in a demo rather than assuming an answer either way.

| Fork | Elaichi | Merge Agent Handler |
| --- | --- | --- |
| Who the call acts as | One OAuth grant per person; permissions read on each request | SCIM-based provisioning documented ([merge.dev](https://merge.dev/merge-agent-handler), checked October 2026). Ask Merge who each call acts as |
| Endpoint shape | One address, `https://api.elaichi.ai/mcp`, for every organization | No URL or endpoint pattern published ([merge.dev](https://merge.dev/merge-agent-handler), checked October 2026) |
| Rule granularity | Allow/block rules naming a whole connector or a single tool, scoped to a role or a member | Policy guardrails and DLP scanning documented ([merge.dev](https://merge.dev/merge-agent-handler), checked October 2026). Ask Merge whether a rule names one tool |
| Audit | 90 days retained in product; Datadog forwarding on the Black plan | Searchable audit trail documented ([merge.dev](https://merge.dev/merge-agent-handler), checked October 2026). Ask Merge about row fields, retention and export |
| Pricing | Per seat, with a free Personal plan for one person | Usage-based, free to start ([merge.dev](https://merge.dev/merge-agent-handler), checked October 2026). Ask Merge for the per-call rate |

## Does one organization-wide MCP endpoint matter for employees?

For internal employee AI, one endpoint per organization decides how much setup work you own. Elaichi serves MCP at one address, `https://api.elaichi.ai/mcp`. The same string serves every organization. Which organization, which person, and which tools a client reaches comes from the OAuth grant behind its token, not from the URL.

Claude, ChatGPT, Cursor, Microsoft Copilot and any MCP client point at the same address, and the Elaichi Agent inside the app works beside them. An admin adds one URL in the client's own console. Each person then connects their client once and approves their own grant on Elaichi's consent screen. Clients register themselves through OAuth dynamic client registration, so nobody pastes a client ID or a secret. The endpoint is stateless, speaking MCP over the Streamable HTTP transport as JSON-RPC 2.0 messages.

The trade-off is real. One endpoint means one blast radius for configuration mistakes. A badly written allow rule on a role reaches every client that role's members use. A per-server deployment limits a mistake to that server. It also multiplies the places a mistake can live, and the offboarding work by the number of servers someone has to remember exist.

Merge's own page does not give a URL or endpoint pattern for Agent Handler connectors ([merge.dev](https://merge.dev/merge-agent-handler), checked October 2026). For the wider argument, [how many MCP endpoints a company actually needs](/blog/one-endpoint-vs-per-team-endpoint/) works through per-person, per-team and per-company cases.

## Who authors the connectors, and what can you govern?

The connector model is the second fork, with a practical consequence: who you contact when a tool breaks.

Elaichi's catalog holds 650+ connectors in two kinds. Most are connectors Elaichi authors and runs itself. The rest are native MCP connectors, where the vendor builds and runs its own MCP server. Elaichi handles sign-in, access and audit in front of it. Datadog, Linear, GitLab, PostHog and Miro are in the catalog as native MCP connectors. GitHub is not in the catalog at all. A team can bring GitHub's own remote MCP server in as a remote MCP connector instead.

The honest limitation on a native MCP connector is that Elaichi does not write, test or fix the vendor's tools. Reports about those tools go to the vendor's own support contact, shown on the connector's page. What Elaichi does is check restrictions and OAuth scopes before a call leaves. It records every call that runs in the audit log, and allows only a tool on that connection's own active list.

An organization on Gold can also add its own remote MCP server as a connector. An Org Owner or Org Admin creates it, and the server must speak MCP over Streamable HTTP on public HTTPS. It then sits behind the same restrictions, scopes and audit trail as everything else.

Merge's FAQ does not say which connectors Merge authors directly versus which are partner-built ([merge.dev](https://merge.dev/merge-agent-handler), checked October 2026). That distinction decides who you escalate to when a tool call fails. For why running a vendor's own server behind a control plane is defensible, see [vendor MCP servers through Elaichi](/blog/vendor-mcp-servers-through-elaichi/).

## How do AI clients find tools without listing hundreds?

In Elaichi, connected tools are never listed one by one, however few there are. The client's tool list holds Elaichi's own operations plus `search_tools`, `read_tool` and `execute_tool` for connected apps, and `run_code` where Code Mode is available.

When a model needs to act, it finds a connected tool with `search_tools` and runs it with `read_tool` (a read) or `execute_tool` (anything), or with `run_code` under Code Mode. Each search result says which of the two to use. The search is lexical, ranked with BM25F over the tool name, toolbox names, connector label and descriptions. A relevance floor returns nothing rather than a tool from an app the person never asked about. It searches only the tools the caller may run. It lists a restricted tool by name with a `restricted` flag and no schema, so the model can tell the user what to ask for.

`execute_tool` is only a naming indirection. It unwraps to the tool name and arguments and goes through the same gates as a direct call. `read_tool` unwraps the same way and meets the same gates, then refuses anything that is not a connected read. One consequence shapes client-side controls. No tool in the list names a connected app. Per-tool client permissions see Elaichi's connected tools as a few tool names (`execute_tool`, `read_tool` and `run_code`), so they cannot tell one connected app from another, and gating `execute_tool` alone leaves `read_tool` and `run_code`. Per-app and per-tool control has to live in Elaichi, as restrictions.

## Who does each AI call act as, and can a rule name one tool?

In Elaichi every call acts as one specific person. Over MCP that identity is the bearer token's OAuth grant, one grant per person. The person's permissions are looked up on each request rather than frozen into the token.

The credential sits behind that. A connected account's secrets live in a separate credential service, encrypted at rest with AES-256-GCM. They are fetched into memory only for the call that needs them. The AI client holds an Elaichi token and never the app's own key. The call reaches the third-party app as the account that connected it, so that app's own permissions apply on top. A connection shared with a team runs on its owner's account. Tools that should see each person's own data need each person's own connection.

On top of identity sit restrictions. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule is allow or block, and names a whole connector or a single tool. Within a layer every block beats every allow. A member's personal rules can only narrow what their role allows. The same clamp runs on every path that reaches a connected tool: `tools/call`, `execute_tool`, `read_tool`, toolbox execution, each step of a synthetic tool, and `run_code`.

Two traps matter before you write your first rule. An allow rule turns on the allowlist for its layer just by existing. So an allow rule that names nothing blocks every connector and tool for its target. See [the allow rule that blocks all tools](/blog/empty-allow-rule-denies-everything/) for the mechanics. The second trap is timing: a role, team or restriction change reaches every surface about two minutes. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

For arguments rather than tools, a toolbox entry can carry frozen parameters. These are values a caller cannot override on calls that run through that entry. The model can see that a key is frozen, and often its value. What it cannot do is change it.

Merge's page documents policy guardrails and DLP scanning ([merge.dev](https://merge.dev/merge-agent-handler), checked October 2026). Ask two questions in evaluation. Does a Merge rule bind to one tool or one whole connector? Does a deny always beat an allow?

## What does one audit row hold, and what reaches your SIEM?

Every vendor says it has logs. The useful question is what one row holds and what leaves the building.

In Elaichi, every connected-tool call that reaches execution over MCP writes an audit entry with the surface recorded as `mcp`. In Elaichi, one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Argument values are not recorded, with one exception. The one path argument that names the object is recorded as the target id. That answers "did this person touch record X" without storing payload contents.

Two things it does not do. A call refused at the MCP scope check writes no entry, because that refusal happens before any executor runs. And the console's "All time" range covers at most the last 400 days. Anything older needs the forwarded copy.

Retention in-product is 90 days. For longer history, an organization forwards events to its own log service with a logging destination, which comes with the Black plan. Three destination types are accepted; only Datadog delivers. The Splunk HEC and Microsoft Sentinel forwarders answer with a not-implemented response, and the console labels both "(coming soon)." If your SIEM is Splunk, plan around that today.

Merge's FAQ documents a searchable audit trail ([merge.dev](https://merge.dev/merge-agent-handler), checked October 2026). Ask Merge what one entry holds, how long it is kept, and where it can be exported. For the field-by-field version, [what an AI agent audit log must capture](/blog/what-an-ai-audit-log-must-capture/) lists what an auditor asks for. Elaichi's own SOC 2, ISO 27001, GDPR and HIPAA attestations live in the [Trust Center](https://trust.elaichi.ai).

## What happens on the day someone leaves?

Offboarding separates a control plane from a collection of connections. It is also where endpoint count turns into labor.

Elaichi supports SSO over SAML and OIDC on Gold and Black, with SCIM provisioning that maps directory groups to roles. A SCIM deprovision suspends the member rather than deleting them. Suspension revokes their MCP OAuth grants, API tokens and SCIM tokens, so their AI clients fail on the next call. Reactivating them does not restore the grants; they consent again from scratch.

A full removal is a separate admin action with a preflight. It returns the member's whole estate before anything changes: the connections they own, their toolboxes, templates, synthetic tools and custom connectors, plus the toolbox entries elsewhere that rely on them. Shared toolboxes, shared templates and every custom connector they own must be transferred or deleted before the removal goes ahead.

One detail deserves stating plainly. Transferring a connection rewrites only its owner field in Elaichi. The stored credential is unchanged, so the connection keeps acting in the third-party app as the account that was signed in when it was connected. Removing someone from Elaichi ends their reach through Elaichi. It does not deprovision their accounts in the apps themselves. [Offboarding AI access, contractors included](/blog/offboarding-when-the-agent-holds-access/) works through the rest of that checklist.

## Should you pay per seat or per call?

Merge prices Agent Handler on usage and says it is free to start ([merge.dev](https://merge.dev/merge-agent-handler), checked October 2026). Ask Merge for the per-call rate before you model a bill. Usage-based pricing fits a variable workload, where traffic rises and falls with behavior you do not control.

Internal employee usage has a different shape. The number of people is known in advance. The number of tool calls is not, and finance wants a number it can budget before the quarter starts.

Elaichi prices per seat. Personal is free, for one person. Gold lists at $15 per user per month in USD, or $10 per user per month billed annually, and includes sharing, custom roles, restrictions, custom connectors, SSO and SCIM. Black adds the Elaichi Agent, workflows, customer-managed keys and Datadog log forwarding. It also bills usage beyond a monthly allowance of 1,000 run minutes and 1 GB-month of storage. [The pricing page](/pricing/) shows the number for your own billing country. 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.

**A worked example.** Take a 100-person engineering org, each person connecting one AI client to three to five tools. On Elaichi Gold billed annually, the seat cost is flat for the year, whether the team runs 10,000 or 500,000 tool calls that month. Merge's usage-based model needs a rate before it can be computed the same way. Have one figure of your own ready: your expected tool calls per employee per month. Usage-based billing rewards low, spiky usage. It penalizes sustained high-frequency internal workflows, such as an engineer querying Jira dozens of times a day.

Seat counting has a detail to plan around. Guest, Billing Admin and Auditor are free seats, so adding a compliance reviewer as an Auditor adds no billable seat. A custom role is always billable, even one holding only view permissions.

The honest trade-off: per seat is worse if a handful of people make an enormous number of calls. Per call is worse if usage is unpredictable and you need a fixed number for a budget cycle. Neither is universally cheaper. Measure your call volume per employee before signing either contract. [MCP gateway pricing, per seat versus per call](/blog/mcp-gateway-pricing/) works the arithmetic through.

Consider Composio in the same evaluation. Its [Enterprise page](https://composio.dev/enterprise) says admins set permissions per user and per role, down to a single action, evaluated in the request path before the model is involved (checked October 2026). The same page describes per-call audit logging with the user, team, tool, action and outcome, and SAML and OIDC single sign-on with SCIM 2.0 group mapping. Its [pricing page](https://composio.dev/pricing) meters tool calls rather than seats, with a $0 Hobby plan and a $29-a-month Pro plan (checked October 2026). That puts Composio on the per-call side of this fork, like Merge.

## When Merge Agent Handler is still the right pick

There are clean cases where none of the above should move you.

The first is an agent that is not your employees' AI client at all. It serves your own customers, inside a product you run, and reaches many customers' instances of many systems. The identity on each call is a customer tenant rather than an employee. A per-seat control plane priced for your own staff does not solve that. Ask Merge whether Agent Handler fits that shape.

The second is traffic that is genuinely variable, where you want the bill to track it. Usage-based pricing matches a workload whose volume you cannot forecast a quarter out.

There is one more case: neither product. With a single app, a small team and one AI client, you do not need a control plane yet. The native connector built into Claude or ChatGPT will do. [When you don't need an MCP gateway](/blog/when-you-dont-need-an-mcp-gateway/) sets out where that line sits: roughly once you have more than a handful of connected apps, more than one AI client in use, or any compliance requirement to show who touched what.

## What to ask in your evaluation

Five questions separate the shapes. Each has a factual answer you can get from a vendor's own page, a sales call, or a trial.

Does each employee sign in as themselves, and what happens to their access on the day they leave? Is there one address for the organization or one per server? Can a rule name one tool rather than one whole app, and does a block beat an allow by default? What does one audit row hold, how long is it kept, and where can it be exported? Is the price per seat or per call, and which matches your actual call volume per employee?

Answer those five and the choice usually makes itself. For the shorter version, [Elaichi vs Merge Agent Handler](/blog/elaichi-vs-merge-agent-handler/) takes three forks rather than five. The same five questions apply to [Composio and the tools in its category](/blog/composio-vs-zapier-mcp/). For the wider field, [the best MCP gateways for company-wide AI access](/blog/best-mcp-gateways/) covers other shapes. The [connector catalog](/connectors/) shows what is available to govern today.

## FAQ

### What does Merge's own page say about Agent Handler?

Merge's own FAQ describes Agent Handler as a platform for securely connecting AI agents to enterprise tools at scale, with production-grade connectors, built-in authentication and observability tooling (merge.dev, checked October 2026). The page also documents SCIM-based provisioning, DLP scanning and policy guardrails, a searchable audit trail, installation as a remote MCP server with user-created Tool Packs, and usage-based pricing that is free to start. Put anything the public page does not settle to Merge directly, such as the per-call rate or what one audit row holds.

### How does Elaichi differ from Merge Agent Handler for internal employee AI access?

Elaichi is a governed MCP control plane for a company giving its own employees access to its own apps. It serves one MCP endpoint, https://api.elaichi.ai/mcp, that Claude, ChatGPT, Cursor, Microsoft Copilot and any MCP client all sign into with OAuth, and each person approves their own grant so every call acts as that person. Pricing is per seat rather than per tool call, with a free Personal plan for one person; the pricing page shows the figure for your own billing country. Merge prices Agent Handler on usage and says it is free to start (merge.dev, checked October 2026).

### Can a restriction in Elaichi block a single tool rather than a whole app?

Yes. A restriction rule names whole connectors, single tools, or both, with each tool written as a connector and tool-name pair. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. Within a layer all allow rules merge into one allowlist and all block rules into one blocklist, and a block always beats an allow. The clamp runs on every path that reaches a connected tool, including tools/call, execute_tool, read_tool, toolbox execution, each step of a synthetic tool, and run_code. One trap: an allow rule that names nothing blocks every connector and tool for its target, because an allow rule turns on the allowlist for its layer just by existing.

### How long does Elaichi keep audit logs, and can they go to a SIEM?

Elaichi keeps 90 days of audit history. For a longer record, an organization forwards events to its own log service using a logging destination, which comes with the Black plan. Three destination types are accepted: Datadog, Splunk HEC and Microsoft Sentinel. Only Datadog delivers; the Splunk HEC and Microsoft Sentinel forwarders answer with a not-implemented response, and the console labels both as coming soon.

### How quickly does a restriction or role change take effect in Elaichi?

A role, team membership, restriction or access-grant change reaches every surface about two minutes. Revoking a grant, removing a member or suspending a member is different: those take effect on the client's next call, because every MCP request re-reads the OAuth grant. Revoking a share and disconnecting an account are also effective on the next call.

### Can a company add its own MCP server to Elaichi?

Yes. An organization on the Gold plan, which Black contains, can add a remote MCP server as its own connector, as long as that server speaks MCP over Streamable HTTP and is reachable over public HTTPS. Creating one needs the connector:create permission, which among the built-in roles only Org Owner and Org Admin hold. Its tools then pass through the same restrictions, OAuth scopes and audit log as any catalog connector.

## Read next

- [Elaichi vs Merge Agent Handler: three forks](/blog/elaichi-vs-merge-agent-handler/) — 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.
- [Composio alternatives for governed employee AI](/blog/composio-alternatives/) — How to compare Composio alternatives on per-person sign-in, tool-level restrictions, audit logs and pricing, and when Composio is still the right pick.
- [Best MCP gateways for company-wide AI access](/blog/best-mcp-gateways/) — The best MCP gateways come in four shapes: a hosted catalog, a gateway you run, a per-member server or a control plane. Pick the shape, then the vendor.