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 November 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 November 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 650+ 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 November 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 November 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 November 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.

Does Composio work as one MCP for setting up colleagues in Claude Desktop?

Composio offers two routes. Composio Connect is one shared MCP URL that a person adds to Claude Desktop as a custom connector, approving each app through an OAuth link (Connect docs, checked November 2026). Its homepage also offers one setup for a whole team (composio.dev, checked November 2026).

A thread on r/ClaudeAI asks whether Composio can be the single MCP a team hands to every colleague. Composio's Connect docs give the address as connect.composio.dev/mcp. They tell Claude Desktop users to find Composio under Settings > Connectors, marked with a CUSTOM badge. The first time an agent needs an app, Composio opens an OAuth link the person approves, and the connection persists after that (Composio Connect docs, checked November 2026).

Composio's homepage offers "One setup for your whole team", in which every teammate's AI gets the shared apps, skills and budget. Its FAQ says Claude Web and Cowork users connect Composio as a Claude connector (composio.dev, checked November 2026). For a company, its gateway page gives each team its own MCP endpoint (composio.dev/mcp-gateway, checked November 2026).

You may not need Elaichi here. The shared Composio URL fits a few colleagues who each connect their own apps. Once an admin owns the rules for a whole company, compare Elaichi with Composio's gateway on the address model: one organization-wide address, or one endpoint per team.

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. Elaichi's sign-in is written with Claude Desktop, claude.ai connectors and Cursor in mind.

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 MCP Gateway page says administrators can manage access by organization, team, user, agent or toolkit. It says they can block sensitive actions without turning off a whole toolkit (composio.dev/mcp-gateway, checked November 2026). Its Enterprise page describes a trace of each tool call to the user, connected account, action and outcome, and single sign-on over SAML and OIDC (composio.dev/enterprise, checked November 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 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. A restricted tool is left out of the tools Elaichi offers a client and cannot be called. Search still names it, flagged restricted, with no schema. Composio Connect reaches its apps through seven meta-tools (Composio Connect docs, checked November 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. In Elaichi, a call from an MCP client is recorded under the person who signed in, with surface mcp and the OAuth client named, 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 three plans: Personal, which is free, then Gold and Black. Gold lists at $15 per user per month in USD, or $10 per user per month billed annually, and the pricing page shows the price for your region. Every new workspace starts on a 14-day Black trial, no credit card to start. Buying Gold or Black during the trial keeps its remaining days rather than granting a fresh 14, so it is one continuous trial, and the seats are first charged when it ends. A workspace that buys nothing moves to the free Personal plan. 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 November 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 speaks to people who connect an AI assistant without writing code, and to developers building an agent or backend app. It says that when Composio is built into a team's own agent, "Your users connect their own accounts, and Composio runs every call" (composio.dev, checked November 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 (checked November 2026), 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.