# Elaichi vs native AI connectors: one plane, many clients

> Elaichi vs native AI connectors: what a second AI client costs in repeated authorization, provisioning, audit shapes and role models, and when native is still right.

**TL;DR** Elaichi is one organization-wide MCP endpoint that Claude, ChatGPT, Cursor, any MCP client, or the Elaichi Agent can be pointed at, so accounts, roles and the audit trail are configured once. A native connector system inside a single AI client is configured in that client, for that client's users, with that client's records. If you run one client for one team, native is less to own. The comparison starts to matter on the second client, when authorization, provisioning, records and role models all repeat.

## Elaichi vs native AI connectors: what is being compared

Support bought ChatGPT Enterprise in March. Engineering has run Cursor for a year. Legal now wants Claude. That is three admin consoles, three connector setups, and three sets of records to reconcile when something goes wrong.

Elaichi vs native AI connectors is a comparison of two shapes, not two feature lists. A native connector system lives inside one AI client, configured there, by that client's admins, for that client's users. Elaichi is one organization-wide MCP endpoint that every client points at. MCP is MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Think of it as the equivalent of OpenAPI for LLM tool-calling. The client discovers and invokes tools at runtime, instead of against a static spec. An endpoint is the single address a client connects to: `POST /mcp`, standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth. OAuth here means a delegated-authorization grant issued per person, revocable independently of any other person's grant. Not a shared token pasted into a config file that everyone on a team inherits.

With one client, the two shapes are close to equivalent: one admin console, one connector setup, one place to look when something breaks. The cost of the "many consoles" shape only shows up once a second client enters the picture, and it shows up in four specific places, detailed below. This is the general framework. it applies whether the second control plane is Elaichi or any other org-wide MCP gateway, not just this one.

*(Version note: specifics below. pricing, propagation timing, action-string counts, catalog size. reflect Elaichi's product as documented at time of writing. Treat any number here the way the post itself tells you to treat a competitor's admin console: verify it against the current changelog before repeating it as fact.)*

## What does a second AI client cost in repeated configuration?

Four things start repeating once per client rather than once per company. This is the generalizable part of the comparison. it holds regardless of which vendor's control plane you're evaluating against native connectors.

**Authorization.** Every place a SaaS account is connected is a place an authorization has to be created, consented to, and renewed on its own schedule. Two clients reaching the same Salesforce org is two authorizations to keep alive, not one. two refresh-token lifecycles, two places a revoked grant can silently go stale. Elaichi holds the account once. Credentials are not stored in Elaichi's application database; a separate credential service owns per-account secrets (AES-256-GCM at rest) and owns the refresh cycle. A failed refresh marks the connection `needs_reauth` rather than failing silently mid-task. An organization that wants to supply its own OAuth app per connector can do that. That path is gated on the `connector:manage` permission, rather than `connection:manage`. A person who can delete a connection does not automatically gain the ability to repoint the org's OAuth app to a different client ID.

**Provisioning.** Each client carries its own member list. Each list drifts from the identity directory at its own rate. [Someone offboarded in the HRIS on Monday can still hold a live Cursor seat on Friday](/blog/shadow-ai-contractor-offboarding/) if nothing propagates that change. Elaichi runs SAML and OIDC SSO in-house (no third-party auth vendor in the request path). SCIM v2 covers users and groups, with group-to-role mapping. SCIM is the standard an identity provider (Okta, Entra ID, etc.) uses to push joiner/leaver and group-membership events to a downstream app. Four onboarding paths exist: single-use invite links with role and team pre-assigned, verified-domain auto-join with a default role, SCIM provisioning, and just-in-time SSO.

**Records.** Two clients produce two record shapes. Correlating them by eye is the work you inherit. Different field names for "who," different timestamps, different definitions of what counts as an event. Elaichi writes one record shape for audit events and application logs both, with one log tenant per organization. one entry per tool-call attempt, succeeded or failed. That single-shape guarantee matters the first time somebody asks which of two Notion workspaces the agent wrote to. `actor_kind` is a recorded field on every row. It is not inferred later from a user-agent string. `ai_assistant` is one of its enumerated values. Argument *names* and *counts* are logged. Argument *values* never are, by design. That is a stated tradeoff. The audit trail proves an agent called `update_deal_stage` with two arguments, not what those arguments contained.

**Role models.** Two clients rarely agree on what a role is, which makes "who can reach Stripe" a question with two different answers depending on which console you ask. Elaichi gives each member exactly one role, enforced by a unique index at the database level, so a role is a complete persona rather than a stack of independently-granted add-ons that can drift out of sync. Roles are built from roughly 38 discrete action strings (examples: `tool:execute`, `restriction:manage`, `audit:view`). Restrictions. the rules that decide which connectors and which individual tools a target may reach. can target a role or a specific user, but never an organization as a whole. The org default, absent any restriction, is allow-all. That default is worth stating plainly because it's the opposite of what a security-conscious admin would assume: connecting an account does not implicitly lock it down.

The same four items, side by side:

| What repeats | Native connectors, per AI client | Elaichi, per company |
| --- | --- | --- |
| Account authorization | One grant per client for the same account, each with its own refresh lifecycle | One connection; refresh owned by a dedicated credential service, AES-256-GCM at rest |
| Provisioning | Each client carries its own member list, drifting independently from the directory | SSO (SAML/OIDC), SCIM v2, and group-to-role mapping into one directory path |
| Records | One record shape per client, correlated by hand across inconsistent field names | One record shape, one log tenant per organization, `actor_kind` as a first-class field |
| Role model | Whatever each client's console defines a role to be, potentially disagreeing across clients | Exactly one role per member, enforced by a unique index; ~38 action strings compose it |

## How does one URL serve Claude, ChatGPT and Cursor?

One address, and the OAuth grant is what varies per person. There are no per-toolbox URLs, no embedded tokens in config files, and no MCP server to create, list, or revoke per user.

Elaichi is validated against four clients before every release, and the integration path differs by client because each client's admin surface differs:

- **Claude Desktop**. one URL entered under Settings > Custom Connectors, followed by an OAuth handshake per user.
- **ChatGPT Enterprise**. the same URL entered under Admin Console > Connectors. Non-Enterprise ChatGPT plans (Plus, Team) have no admin surface for org-wide connector configuration, so this shape is not supported on those plans. that's a plan-tier limitation of ChatGPT, not of Elaichi.
- **Cursor**. configured per workspace under Settings > MCP, with the org-wide endpoint living in the workspace's shared config file rather than per-user config.
- **Elaichi Agent**. a fourth option, a first-party chat UI, for teams that want this without adopting a third-party client at all.

Anything else speaking standard MCP over Streamable HTTP works against the same endpoint without a separate integration path.

Elaichi authors, maintains, and serves the 450+ connectors from its own infrastructure. Companies do not stand up or operate MCP servers. That is the operational difference between "one endpoint" and "one server per tool". It is a separate tradeoff covered in [the real cost of running them](/blog/self-hosted-mcp-servers-vs-control-plane/).

Past a threshold of 30 tools. counting control-plane operations and connected tools together. the connected half collapses behind two meta-tools, `search_tools` and `execute_tool`, rather than being listed flat in the model's context window. One connected app with a moderately-sized API is normally enough to cross that threshold, so collapse is the common case rather than the exception. The ranking behind `search_tools` is lexical (BM25-style term matching) with a relevance floor rather than a fixed top-K cutoff, described in [how the tool search floor was built](/blog/search-tools-ranking-floor-idf/).

**Gemini is explicitly out of scope here.** Google's Gemini is not one of the four clients Elaichi rehearses against as of this writing. If your company standardized on Gemini, treat its extension/connector system as a separate research question and read Google's own admin documentation on the day you decide. not a claim about it from a blog post, including this one.

## Where a single-client native connector is the right call

Native wins in more situations than a vendor comparison post usually admits. Three concrete cases:

**Single client, few accounts.** One client, one team, two or three connected accounts, no requirement to correlate activity across tools. A Claude-only legal team with one document system does not need an organization-wide plane to reach it. the coordination cost the four-item framework above describes doesn't exist yet, because there's nothing to coordinate. The same is true of a support team whose only AI client is ChatGPT Enterprise and whose only connected account is the help desk. Adding a control plane here is pure overhead: another system to patch, another OAuth app to register, another vendor relationship to manage, for a coordination problem you don't have.

**Coverage gaps.** If the resource you need exists only as a first-party connector inside one client. a proprietary internal tool a vendor built a bespoke integration for, for instance. no control plane conjures it into existence. Check the target client's own connector list first, before evaluating anything else, because this eliminates the comparison entirely in either direction.

**Cost crossover.** Native connectors are typically bundled into the enterprise-tier seat price of the AI client itself (e.g., ChatGPT Enterprise, Claude Enterprise/Team) with no separate line item. An org-wide control plane is usually priced as an additional per-seat cost on top. Both Elaichi plans are paid, Gold and Black. Gold is $15 per user per month or $120 per user per year, per the [pricing page](https://elaichi.ai/pricing/). 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. That additional cost only pays for itself once the four repeating costs above are being paid multiple times over. Roughly, once a second client and a second set of shared accounts both exist. Below that point, do the arithmetic before adopting anything. N clients by M shared accounts is the rough proxy for how much duplicate authorization, provisioning and record work you are currently doing by hand. For the wider version of this wait-and-see argument, read [when a gateway is premature](/blog/when-you-dont-need-an-mcp-gateway/).

## What to ask each client's admin console before you trust it

The governance ceiling of a native connector system is whatever its own admin documentation says it is on the day you read it. That documentation changes every quarter as vendors ship new admin features. This post will not characterize what Claude, ChatGPT, or Gemini currently exposes to admins. An undated claim of that kind becomes wrong faster than it gets corrected. The same standard applies to this post's own claims about Elaichi.

Take these seven questions into each console instead, and write down the answer with the date you checked it:

1. Can you restrict a single tool, or only a whole connected app?
2. Can one person hold two roles that disagree with each other (one granting, one denying the same action)?
3. When a person has two accounts of the same app connected, does the record name which one was reached?
4. Is "an AI did this" a recorded, queryable field. or something you'd have to infer afterward from a user-agent string or IP?
5. When you remove a person from the directory, when exactly does their live tool access stop. immediately, on next cache refresh, or on next login?
6. Are tool-call argument *values* written to the log, and who is permitted to read them?
7. Can a compliance reviewer read the audit trail without consuming a paid, tool-using seat?

Any of the seven is a fine reason to keep native if the answer satisfies your requirement. The point of the exercise is to have the answer written down rather than assumed. most teams have never actually asked their vendor these questions.

## What Elaichi's answers are, including the awkward ones

Restrictions reach individual tools, not just whole connectors. A rule is written against a connector-and-tool pair, and the canonical operation name is pinned against the catalog at write time. A **block** matches either the tool's advertised name or its pinned operation; an **allow** matches the pinned operation only. That asymmetry exists for a specific reason. A tool's advertised name is a label the *governed party* (the connected SaaS app) can change. A block that only matched a mutable label could be silently bypassed by a rename. An allow has the opposite failure mode, so it is pinned to the immutable identifier instead. This is unpacked in [why blocks match the name and allows match the operation](/blog/block-matches-name-allow-matches-operation/).

Precedence order: user override, then role rule, then org default. A user-level rule *replaces* the role's rules for that user rather than layering on top of them. This is a common source of surprise, since most RBAC systems layer rather than replace. Within whichever layer wins, blocks always beat allows. One real trap worth naming explicitly. the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. The system has switched from "default allow" to "default deny, plus this empty list of exceptions."

Arguments that should not be model-decided can be frozen per toolbox entry. Frozen keys are stripped from the tool's advertised schema entirely. The model never sees the field exists and cannot attempt to set it. Frozen values are merged over whatever the caller passed at execution time, after the model's turn is done. Passing the key anyway does not un-freeze it. The merge happens regardless. A compliance reviewer costs nothing. Auditor is a free read-only seat, as are Guest and Billing Admin. That is a direct answer to question 7 above.

Freshness is the fact most easily mis-stated. Here it is precisely. A role change or a restriction change takes effect about two minutes, via a 60-second cache plus edge propagation delay. This applies uniformly across MCP, the console, and REST. No path is faster or slower than the others. removing or suspending a member revokes every live grant in the same transaction as the membership change. A grant's revoked state is re-read from the org store on every single call, not cached for the session. Removing a member revokes their live grants in the same database transaction as the membership deletion. Not a subsequent, eventually-consistent step.

Three awkward ones, stated plainly rather than buried:

- The prompt-injection write-gate that guards the Elaichi Agent's chat window does **not** apply to `POST /mcp`, and structurally cannot. An MCP server never sees a user's natural-language prompt. Only structured tool calls. There is no prompt to inspect. What actually holds on the raw endpoint instead is RBAC per operation, the forbidden-tool classification, output redaction, OAuth scope limits, and full audit logging. These are different controls solving a different problem, not a weaker version of the same one.
- Region `eu` and region `us` are hard data residency guarantees. Region `apac` is a placement *hint* and best-effort only, not a contractual data-locality commitment. If your compliance program specifically requires the Asia-Pacific region as a locality (rather than a preference), confirm the current state directly with Elaichi before relying on it.
- Organization deletion tears down the workspace but has no path to purge the organization's log tenant. This is reported here by name rather than hidden, because it's the kind of gap a prospective customer with log-retention or right-to-erasure obligations needs to know before signing, not after.

## A rollout order that does not repeat per client

Connect accounts once, decide access once, then point clients at the URL last, per the [product overview](https://elaichi.ai/product/). Doing it in that order means adding a third client later is one line of configuration and zero new policy work.

1. Connect the accounts the team already uses, from the [connector catalog](/connectors/).
2. Give each member exactly one role, ideally mapped from an identity provider group rather than assigned by hand.
3. Write restrictions against roles rather than individual people, and reserve user-level overrides for genuine exceptions.
4. Freeze the arguments that should never be chosen by a model (destructive operations, financial fields, anything with compliance exposure).
5. Point Claude, ChatGPT Enterprise, and Cursor at the one endpoint, each authenticating over OAuth independently.
6. Read the audit trail after a week, filtered by `actor_kind`, and adjust restrictions based on what the agent actually tried to do versus what you assumed it would do.

If the alternative you're weighing is a per-member server inside an automation account rather than a native-connector system, the [one-endpoint-versus-one-per-user comparison](/blog/zapier-mcp-alternative/) covers that shape specifically. If it's servers your own team would operate and maintain, see [the real cost of running them](/blog/self-hosted-mcp-servers-vs-control-plane/). For team-by-team starting points, the [twelve team pages](/use-cases/) are the shortest route in, and the rest of the [side-by-side write-ups](/blog/category/comparisons/) sit together for broader context.

## FAQ

### Can Claude, ChatGPT and Cursor use the same MCP endpoint?

Yes. Elaichi serves one organization-wide MCP endpoint, `POST /mcp`, and every client points at that same URL and signs in over OAuth. Claude Desktop adds it under Settings, Custom Connectors. ChatGPT Enterprise adds it under Admin Console, Connectors; non-Enterprise ChatGPT plans have no admin surface for it. Cursor configures it under Settings, MCP in the workspace's shared config. There are no per-toolbox URLs and no embedded tokens.

### Does Elaichi support Google Gemini?

Gemini is not one of the clients Elaichi rehearses against before each release. The four validated surfaces are Claude, ChatGPT, Cursor and the Elaichi Agent, and anything else speaking standard MCP over Streamable HTTP with JSON-RPC 2.0 can connect. If Gemini is the client your company standardized on, check Google's own admin documentation for what its extension system exposes, on the day you decide.

### When is a native AI client connector the better choice?

When there is one AI client, one team and a small number of connected accounts. A native connector system inside that client is less to own, and a control plane maintained for a single team earns nothing. The other case is coverage: if the resource you need exists only as a first-party connector inside one client, no control plane creates it for you.

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

about two minutes. Role membership and restrictions resolve through a 60 second cache plus edge propagation, on MCP, the console and REST alike. Only three changes are effective on the next call: grant revocation, member removal and suspension. removing or suspending a member revokes every live grant in the same transaction as the membership change.

### Does a compliance reviewer need a paid Elaichi seat to read the audit trail?

No. Auditor is a free read-only seat in Elaichi, as are Guest and Billing Admin. Billable seats are Org Owner, Org Admin, People Admin, Team Admin and Member. The audit trail is append-only, newest-first, cursor-paginated, and filterable by free text, category, actor, action kind and time.

## Read next

- [When you don't need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/) — Per-user AI client connectors plus an SSO policy are enough for three kinds of company. Here is when you don't need an MCP gateway, and the two signals that end it.
- [Zapier MCP alternative: one endpoint, not one per user](/blog/zapier-mcp-alternative/) — A Zapier MCP alternative for teams: one organization endpoint with role restrictions and a per-call audit log, next to Zapier's per-member servers. What differs, and when Zapier fits.
- [Self-hosted MCP servers vs managed: the real cost](/blog/self-hosted-mcp-servers-vs-control-plane/) — Self-hosted MCP servers vs managed comes down to four recurring costs: credential storage, refresh, per-user auth and audit. Here is where each lands, and when self-hosting still wins.