Elaichi vs Composio: who writes your connectors?

Elaichi vs Composio: what is the difference?

Elaichi vs Composio comes down to who writes your connectors and how many MCP addresses your company hands out. Elaichi writes, maintains and serves its own connectors. Every AI client reaches them through one organization-wide endpoint, and each member signs in with their own grant. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

Take twenty people who want Claude or ChatGPT to read the CRM, file tickets in Jira and pull invoices from Xero. Several products answer that request, and these two answer it with different designs.

Composio's docs describe Composio Connect as an MCP server at connect.composio.dev/mcp that gives an agent access to "1000+ apps". It does so through seven meta-tools rather than one listed tool per app action. Each app is approved through an OAuth link in the browser (Composio Connect docs, checked October 2026).

Its MCP Gateway page describes the shape Composio offers a company: "one gateway, every server", where "each team gets its own MCP endpoint carrying only the tools it is permitted to use". That page counts "1,500+ apps available" (Composio MCP Gateway, checked October 2026). These are two coherent designs for two different buyers, and neither is a strict upgrade of the other.

Who writes the connectors you depend on?

Elaichi writes most of them. Elaichi serves 600+ connectors, authors and maintains most of them on its own infrastructure, and your company runs no MCP servers of its own. When an app changes its API and one of those tools starts failing, there is one party to chase, and it is the party you pay. A native MCP connector is the exception: the app's vendor builds and runs its tools, and reports go to that vendor's support contact.

Breadth and authorship pull against each other. A catalog one vendor writes grows only as fast as that vendor writes connectors. Composio's Connect docs count "1000+ apps", well beyond the Elaichi catalog (docs.composio.dev, checked October 2026). That is a real gap in raw coverage, not a rounding error. If your teams depend on a long-tail app that Composio lists and Elaichi does not, that alone can decide the comparison. Check the five apps your teams actually name against the connector catalog before the argument turns abstract.

Who writes and maintains each of Composio's app tools is a question to put to Composio. Its gateway page describes "one gateway, every server" (composio.dev/mcp-gateway, checked October 2026). Ask which tools behind it Composio maintains, and which come from servers your team or somebody else runs.

If an app is missing from the Elaichi catalog, custom connectors are authored from JSON config. A connector can be forked from a public one, and a fork can pull upstream changes through a review surface. That surface separates new tools, safe updates, config diffs, conflicts and upstream removals. Conflicts and destructive removals stay unchecked by default, so someone has to look at them. The connector:create permission is flagged high trust, because a custom connector can be pointed at any destination.

One organization-wide address, or one endpoint per team?

Elaichi has one address: POST /mcp, standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth. The MCP specification defines Streamable HTTP as a transport in which each message is an HTTP POST to a single MCP endpoint (MCP transports). There are no per-toolbox URLs and no embedded tokens. There is no MCP server to create, list or revoke per person. The address is fixed, and the grant is what varies.

That shape decides what offboarding looks like, and offboarding runs at two different speeds. Revocation is a database write, not a hunt through client configs for URLs. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. A role change or a restriction change takes about two minutes to settle, through a short cache plus edge propagation rather than a config push to every client.

The same design has a cost. One address means one shared boundary. Isolation between teams on Elaichi is enforced by roles and restrictions inside the application, not by which URL a client happens to hold. Elaichi has no per-team endpoint. If your compliance model calls for a separate address per business unit, Elaichi does not offer one.

Composio's gateway page describes the per-team shape: "each team gets its own MCP endpoint carrying only the tools it is permitted to use" (composio.dev/mcp-gateway, checked October 2026). Per-team endpoints fit an organization where the team is the real unit of access. The cost is more addresses to track as the company grows. Ask any per-endpoint vendor how many addresses exist after a year, and who keeps client configuration in step with them. Ask whether a team's endpoint is its own boundary or a path on one shared gateway. And ask what an admin does at 5pm on a Friday when a laptop goes missing.

How do Claude, ChatGPT and Cursor connect to Elaichi?

Every client takes the same URL. An admin adds it once where the client allows that, and each member then connects and signs in with their own grant. Nobody is issued a personal URL or token, though each member still connects once.

In Claude Team and Enterprise, an owner adds the connector under Organization settings > Connectors, and members connect it under Customize > Connectors. On Pro and Max, each person adds it under Customize > Connectors (Anthropic's custom connector guide). In Cursor, the admin MCP allowlist is Enterprise only. Cursor's docs say that adding a server to it "does not push it to users' machines", so each developer still adds the server in their own Cursor (Cursor's enterprise docs). ChatGPT has its own steps, covered in connecting Elaichi to ChatGPT. Any other client that speaks MCP over Streamable HTTP uses the same address. The Elaichi Agent is not one of them. It works inside the app and comes with the Black plan.

The test to run on any candidate is the number of steps a member performs before their first successful tool call. Setup repeated per person is the cost that shows up in month three rather than week one. It arrives when the fifth new hire asks how to connect Claude and nobody has written it down.

How does each one govern what the model can call?

Both products have governance, so compare its shape rather than its presence. Elaichi splits access into three layers. Permissions are 58 action strings grouped into roles, with exactly one role per member, enforced by a unique index. Sharing is a separate grant of view, use or edit to a person, a team or the whole organization. Nobody sees a resource unless they own it or it was shared with them. 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 aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. 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 catches a tool by its name or by the operation behind it, while an allow counts the operation only. The reasoning is in why a block matches the name and an allow matches the operation.

Composio's enterprise page states that permissions are "set administratively, per user and per role, down to the individual action". It says "every tool call is logged with the user, team, tool, action and outcome, denied calls included". Single sign-on is available over SAML and OIDC (composio.dev/enterprise, checked October 2026). On paper, that is a comparable depth of control.

Elaichi and Composio Connect both keep app tools out of the model's first look. In Elaichi, 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. A tool a restriction withholds is left out of the tool list and cannot be called. Search names it, flagged restricted, with no schema. Composio Connect reaches its apps through seven meta-tools (Composio Connect docs, checked October 2026). Ask Composio whether a restricted action disappears from what the model can discover, or is refused only when called. The answer decides how visible the boundary is to the model doing the planning.

On the Elaichi side, the audit trail keeps one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The account it names is the one the call actually reached. 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 logged at the point of action rather than guessed later. The trail records the one path argument that names the object, as the target id, and nothing else about the arguments, which trades some forensic detail for not storing sensitive payloads. A compliance reviewer can hold a free read-only Auditor seat, so audit access does not compete with billable headcount.

One limit on the Elaichi side, stated plainly. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. It cannot, because an MCP server never sees a user prompt. What holds on the endpoint instead is a permission check per operation, the forbidden classification, output redaction, OAuth scope limits and an audit row for each call that reaches execution.

What does each one cost once you need SSO and SCIM?

Elaichi has two plans, Gold and Black. Gold lists at $15 per user per month in USD, or $120 per user per year, and the pricing page 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. Suspended members and the free-seat roles (Guest, Billing Admin and Auditor) are not counted. SAML and OIDC SSO are built in-house, with SCIM v2 for users and groups and group-to-role mapping, and the pricing page lists all three on Gold.

Composio's pricing page bills on tool calls. It lists Hobby as free with 3 team members and Pro at $29 a month. SSO, SCIM and customer-managed keys sit under a custom Enterprise tier (composio.dev/pricing, checked October 2026).

The two bills move with different things. Take a 20-person team on Elaichi Gold: at the USD list price, that is 20 seats at $15, or $300 a month, however many tool calls anyone makes. A plan billed per tool call moves with usage instead, so the number that matters there is your team's monthly call volume. Light, occasional lookups and an agent that runs all day produce very different counts from the same twenty people. Run your own count against both pricing pages before assuming either one is cheaper.

When is Composio the better choice?

When the people holding the sessions are your customers rather than your employees. Composio's homepage addresses developers building agents and people who want an AI assistant to act in their apps. Its docs describe an SDK with per-user sessions and managed auth (composio.dev, docs.composio.dev, checked October 2026). That is the right shape for a product team putting tool access inside something it sells, where a seat does not map to an employee at all.

Elaichi assumes a workforce. Roles, billable seats, the offboarding preflight and SCIM all describe employees and contractors, not your end users. Bending Elaichi onto a consumer product would mean paying per seat for accounts whose churn you do not control. Three other cases point toward Composio:

• A team already building on the Composio SDK. Switching is real engineering work, not a preference.
• An app you depend on that Composio lists and the Elaichi catalog lacks. That blocks you until someone builds a custom connector.
• An organization that wants a separate endpoint per team. Composio's gateway page describes that shape, and Elaichi does not offer it.

When should you buy neither?

Three people, one connected app, read-only access, and an owner who can see every call: buy nothing. The case for waiting, and the signals that the wait is over, are in the piece on not needing a gateway yet. If you already run MCP servers in your own infrastructure, the comparison is a different one, and its cost side is set out in self-hosted servers against a managed control plane.

How do you test both in two weeks?

Run both against the same narrow task instead of reading feature grids, this comparison included. Pick one team, one app and one job that team does weekly. Then measure setup, revocation and the audit record directly.

1. Name the five apps the team needs and check each against both catalogs: the connector catalog for Elaichi, and the toolkits list in Composio's docs for Composio.
2. Add the endpoint to one AI client, as an admin where the client allows it, and count the steps a member performs before their first successful tool call.
3. Block one destructive tool for one role and time how long the block takes to reach a live client session, not just the admin panel.
4. Remove a test member and check what happens to their access and to any shared connection. Note whether access ends on the next call, at the next token refresh, or not until someone notices.
5. Export a week of tool-call records. Check whether each one names the actual account reached, not just "Salesforce", and note whether refused calls appear beside successful ones. Elaichi writes no row for a call refused before execution.

For a worked example of step three in a real team, read how a sales team gets governed Salesforce access through ChatGPT. The address-model argument in a different setting is in the per-member server comparison. Team-by-team starting points are on the use cases page, and more head-to-heads sit under comparisons.