Two shapes on the table when 200 people ask for AI access
Support wants the ticketing system inside Claude. Finance wants the ledger inside ChatGPT. Engineering already has Cursor open. You have 200 people, three clients and no policy yet. Per-user MCP server vs shared endpoint is the fork you hit before any question about roles or logging. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps
In the first shape, each person ends up with their own server address and their own set of connected accounts behind it. In the second, there is one address for the whole organization, and what varies is the grant (the OAuth authorization a client holds after a person signs in). Elaichi is the second shape. One endpoint, POST /mcp, standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth. There are no per-toolbox URLs and no embedded tokens, where a toolbox is a saved set of tools and accounts.
The two shapes diverge most at two moments. The week you roll out, and the hour somebody leaves.
Per-user MCP server vs shared endpoint: what actually varies
| Axis | Per-user MCP server | One org-wide endpoint (Elaichi) |
|---|---|---|
| Address model | One URL per member, sometimes with an embedded connection token | One URL at POST /mcp behind OAuth; the grant varies per person |
| Credentials | Each member connects their own accounts, held per server | Per-account secrets sit in a separate credential service, AES-256-GCM at rest |
| Offboarding | Locate the member's server and any long-lived token, one address at a time | One membership action; preflight refuses removal while a personal connection is still referenced |
| Audit | A tab or log per member; a cross-member query is a vendor question | One record shape across audit and application logs, filterable by actor, action and time |
| Updates | Each member reconfigures their own client when policy changes | Restriction written once against a role, then propagated within one minute |
| Quota | Usage bills per member (Zapier: each tool call consumes tasks against the plan) | Seats bill per active member; free Guest, Billing Admin and Auditor roles are excluded |
In a per-member shape the unit of configuration is a person. In a shared endpoint shape the unit is a rule.
Zapier MCP is the clearest example of the per-member shape. Its rollout docs say "Give each user their own server and token rather than sharing one". In an organization rollout, "each member still signs in and runs tool calls as themselves" (Zapier MCP rollout docs, checked September 2026). For most MCP clients the member adds Zapier inside the client, and Zapier creates and configures the server during that sign-in. Clients not on Zapier's list, and code you write, use a connection token instead. That token is long-lived, tied to one server, and Zapier says to treat it like a password and never distribute it (https://docs.zapier.com/mcp/overview/how-connections-work, checked September 2026).
Composio sits between the two shapes. Its MCP Gateway page says "each team gets its own MCP endpoint", SSO authenticated (https://composio.dev/mcp-gateway, checked September 2026). Per team is fewer addresses than per member and more than one. The longer read on that product is in the Composio comparison.
With Elaichi, restrictions attach to a role or to a user. A restriction decides which connectors and which individual tools a target may reach. There is no organization target. The organization default is the absence of any rule, which means allow-all until you write something. A rule on a user replaces the role rules for that user rather than adding to them Within the winning layer, allow rules union, block rules union, and blocks always beat allows.
What 200 people costs to set up
Per-member setup multiplies by headcount. Shared endpoint setup multiplies by client.
With three AI clients in use, the per-member shape asks each of 200 people to sign in inside each client they use. The shared endpoint asks an admin to point Claude, ChatGPT and Cursor at one URL through each client's own admin console. Adding a fourth MCP client later is the same shape of work, not a new rollout.
Joining is the other half of the arithmetic. Elaichi has four onboarding paths: emailed single-use invite links with roles and teams pre-assigned, verified-domain auto-join with a default role, SCIM provisioning, and just-in-time SSO. SSO here means single sign-on from your identity provider, SAML and OIDC, built in-house rather than resold. SCIM v2 provisions users and groups, and groups map to roles. RBAC (role-based access control) grants permissions through exactly one role per member, so a new hire in the finance group arrives with the finance persona and nothing else.
The arithmetic is not the real cost. The per-member shape distributes decisions. Each member picks which accounts to connect, so the answer to "who can reach billing data" is assembled from 200 local choices. In the shared shape that answer is a restriction on a role, written once and readable in one place. Elaichi serves 450+ connectors it authors itself, so the rule you write names a connector and a tool rather than a server somebody in your company stood up.
One more thing changes at 200 people. Past a threshold of 30 tools, the connected tools collapse behind two meta-tools, search_tools and execute_tool. The threshold counts control-plane catalog operations and connected tools together, so one connected app is normally enough to trip it. Control-plane operations stay listed individually. If you care how the search behaves once the collapse happens, the ranking floor writeup covers it.
What happens the hour somebody leaves
With one shared endpoint, removal is one action against the membership. removing or suspending a member revokes every live grant in the same transaction as the membership change. The revocation timestamp is re-read from the organization store on every single call, so the next call fails. Role and restriction changes are slower and should not be described the same way: those take effect within about two minutes, on MCP, console and REST alike.
Removal also runs a preflight. Personal connections referenced by a toolbox entry must be resolved first, by transfer to the organization, a team or another member, or by deletion. Otherwise the removal is refused. Unreferenced personal connections are cleaned up. A private connection is not transferable at all, because a credential only its owner could use does not become someone else's when its owner leaves. Delegated toolbox entries surface as a non-blocking warning, and re-pinning is the fix.
In a per-member shape the thing you have to find is an address and, for code-based clients, a long-lived token. So the question to ask in the trial is what becomes of a member's server when that member leaves the account. Zapier's MCP security page does not state it (https://docs.zapier.com/mcp/manage/security, checked September 2026). That is a question for the vendor, not an assumption to make. If the people churning are contractors, the contractor offboarding playbook gives the order to work in.
What the record looks like afterwards
Elaichi writes one entry per tool-call attempt, succeeded or failed, and both name the account actually reached. The audit log is the record of who did what, and here it uses one record shape for audit events and application logs. A single query answers what happened instead of two systems being correlated by eye. The recorded connection comes from the execution, not from the intent, which is what answers "which of our two workspaces did the agent write to". actor_kind is a recorded field, not an inference, and its values include ai_assistant. Argument names and counts are logged. Argument values never are.
The trail is append-only, newest-first, cursor-paginated, and filterable by free text, category, actor, action kind and time. A departed member renders as "Former member" rather than disappearing. Export forwards to your own destination: Datadog is implemented, Splunk HEC and Microsoft Sentinel are accepted but not yet delivering. Rows are eventually consistent, so one may take a moment to appear. A read-only Auditor seat is free, so a compliance reviewer does not consume a license.
Zapier MCP records activity too: a History tab shows user-level activity logs for tool calls, and account-level app and action restrictions apply through MCP (https://docs.zapier.com/mcp/manage/security, checked September 2026). If the address is per member, the question worth putting to any vendor is whether one query spans all of them.
What the shared endpoint costs you instead
One address is one place to get wrong, and the failure is organization-wide rather than personal. Two traps are worth knowing before you write rules. First, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. And block rules match on the tool name or the pinned operation, while allow rules match on the pinned operation only. The reasoning behind that asymmetry is in the name versus operation post.
Seats are the other cost. Gold is $15 per user per month, or $120 per user per year. The two plans are Gold and Black, with a 14-day trial Billable seats are active memberships, so suspended members and the free roles (Guest, Billing Admin, Auditor) are excluded from the count. The trial is 14 days with no credit card. Per-seat pricing is predictable at 200 people and indifferent to how heavily anyone uses it, which cuts both ways.
One limit, stated plainly. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What does hold on the endpoint is RBAC per operation, the forbidden classification, output redaction, OAuth scope limits and full audit logging. Residency is real for two of three regions: eu and us are a hard jurisdiction for compute and storage, while apac is a placement hint (best-effort). Eu and us are the two hard-residency zones. Customer-managed keys in AWS KMS are available per organization if your security team wants to hold the key.
When a server per member is still the right call
Small headcount, one AI client, one or two apps, and automation already living in the same account. Ten people who each connect their own accounts do not need a control plane, and buying one adds a seat line for a problem you do not have.
Zapier MCP has no separate billing: each successful tool call through the server consumes two tasks, failed calls consume none, and tasks count against the plan allowance (https://docs.zapier.com/mcp/features/usage, checked September 2026). If that usage fits a plan you already pay for, the per-member shape is cheaper in both money and attention. The fuller version of that argument is in the case for waiting.
The per-member shape stops working when three things are true at once. More than one AI client is in use. People join and leave every month. And somebody outside your team asks which account an agent wrote to.
Setting the shared endpoint up in the order that works
Run it in this order, because each step narrows the one after it.
- Create the organization and pick the region first.
euandusare hard residency;apacis best-effort placement. - Turn on SSO and SCIM, and map identity provider groups to roles, so joining is not a manual step at 200 people.
- Connect the accounts each team needs, before anyone points a client anywhere.
- Write restrictions against roles, then add user overrides only where a person genuinely differs. A user-targeted rule replaces role rules entirely rather than layering on them.
- Point Claude, ChatGPT and Cursor at the one endpoint through each client's admin console.
- Add an Auditor seat for whoever reviews access. It is free and read-only.
- Remove a test member and watch the preflight. That is the rehearsal you want to have done before a real departure.
If the rollout is for one team rather than the whole company, the Salesforce for sales walkthrough shows the same order applied to a single group. For the other direction, where the servers are yours and the question is who runs them, read the self-hosted cost breakdown. Otherwise, check which of your apps are covered in the connector catalog or find your team on the use cases page.
