You have three AI clients to put in front of staff: Claude, ChatGPT and Cursor. Each has an admin console with a field for a remote MCP connector, and that field takes one URL. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps The per-team MCP endpoint vs org-wide decision is a decision about that field. One shape gives every team its own address. The other keeps one address for the whole company and varies the grant behind it. The difference shows up in rollout, in what happens when somebody changes team, and in how many places you edit when access changes.
What does per-team MCP endpoint vs org-wide actually decide?
| Axis | One org-wide endpoint (Elaichi) | Per-team endpoints (two stacks) |
|---|---|---|
| Cost | One seat count across the organization | Two seat counts, one per stack, plus a separate ops line for each |
| Cross-team sharing | A grant of view, use or edit reaches any member of the org | Sharing across stacks is a manual copy; no connection is actually shared |
| Blast radius | A bad rule reaches the whole org until it is fixed | A bad rule reaches one team; a stack outage contains itself to that stack |
| Restriction targeting | Rules target a role or a user; blocks match tool name, allows match pinned operation | Rules target whatever each stack ships; two rule sets to keep aligned |
| Rollout | One URL per client, so three console entries for three clients | One URL per team per client; five teams across three clients is fifteen entries |
| Migration path | Move a team by changing its role or restrictions | Re-provision the team in the other stack and repoint every client |
It decides where team identity lives. In the per-team shape, the team is in the URL. In the org-wide shape, the team is in the sign-in, and the URL stays the same for everyone.
That reads like a detail. It sets your ongoing work. A URL is configuration inside somebody else's product. Once a team's address sits in three admin consoles, changing who belongs to that team means touching three places. A grant is state in one system, and a grant is what OAuth gives a client instead of a copied token. Changing it is one edit.
Elaichi serves one organization-wide endpoint, POST /mcp. It is standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, and behind OAuth. There are no per-toolbox URLs and no embedded tokens. Clients point at that one address, the person signs in, and the tool list they get back is theirs.
How many admin console entries does each shape produce?
Count the entries before you pick. A per-team address produces one entry per team per client. Five teams across Claude, ChatGPT and Cursor is fifteen entries, each with an owner and each able to drift. One org-wide address produces one entry per client. Three clients means three entries, and adding a fourth MCP client is the same single entry again.
The entries are not equal in weight. A team-specific address is a fact that travels. A team admin can paste it into a personal client, a script or a chat thread. An org-wide address pasted into a personal client still asks the person to sign in first. Elaichi resolves what they may reach at that point, so a copied URL is not a copied capability.
What Composio's MCP Gateway page describes
Composio publishes the per-team shape plainly. Its MCP Gateway page says each team gets its own MCP endpoint, SSO authenticated (composio.dev/mcp-gateway, checked September 2026). Composio Connect is described as an MCP server at connect.composio.dev/mcp that gives an agent access to 1000+ apps through a small set of meta-tools, with OAuth links approved in the browser (docs.composio.dev, checked September 2026).
Governance is there as well, in Composio's own words. Its enterprise page describes permissions set administratively, per user and per role, down to the individual action, every tool call logged with the user, team, tool, action and outcome including denied calls, SSO over SAML and OIDC, and self-hosting at the Enterprise tier (composio.dev/enterprise, checked September 2026). The fork here is not governance against no governance. It is the address model.
Composio's homepage names end users who want an AI assistant to act in apps, and developers building agents (composio.dev, checked September 2026). A builder usually starts from one team and from code, and a per-team address is a natural unit for that reader. For the wider feature ground rather than the address question, the side-by-side on Composio and Elaichi covers it.
Where a separate address per team is the better fit
A per-team address fits when the team really is the unit of procurement, deployment or isolation. Four cases where it is the right call:
- An agency or holding company where each client team must be provably separate, including at the address level.
- An address that gets embedded in code one team ships, where a stable per-team URL is part of the build.
- Teams that buy their own tooling on their own budgets, with no central IT owner.
- Two teams, no movement between them, and no plan to add another.
In those cases the multiplication never happens, and the URL carrying team identity is a feature. The shape starts to cost when the organization chart moves faster than the admin consoles do.
What moves into the grant when the address stays fixed
With one address, everything that would have varied the URL has to vary somewhere else. In Elaichi it varies across three layers, and keeping them distinct is how you predict what a person sees.
Roles are permissions: around 38 action strings grouped into personas, and exactly one role per member, enforced by a unique index. Resource sharing is a grant of view, use or edit on a resource to a user, a team or the whole organization. A member sees only what they own or what was explicitly shared with them. No org-level permission silently widens that listing, org owners and admins included.
Restrictions are the governance layer, meaning which connectors and which individual tools a target may reach. Targets are role or user only. There is no organization target, because the org default is the absence of any rule, which means allow-all. 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. the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything rather than its contents, so an allow rule that names nothing denies everything. Enforcement runs at four points against the same resolver: browse, connect, advertise and execute, plus a final check on the fully substituted outbound URL.
Frozen parameters sit under the same resolver. A frozen key is stripped from the advertised schema, so the model never sees it, and the frozen value is merged over caller arguments at execution. Passing the key cannot un-freeze it. Entry defaults lose to caller arguments, and caller arguments lose to frozen parameters.
Does one address hand the model every tool at once?
No. Past a threshold of 30 tools, the connected tools collapse behind two meta-tools, search_tools and execute_tool. The threshold counts catalog operations and connected tools together, so one connected app is normally enough to trip it. Collapse is the normal case.
Only the connected half collapses. Control-plane operations stay listed, and search_tools never returns one. Tools withheld by a restriction are excluded from the count, because they were handed to nobody. execute_tool is only a naming indirection. It unwraps to the same name and arguments and falls through the identical gates.
Ranking is purely lexical over the tool name, the description and the connector label, with a relevance floor underneath. A tool must account for at least half the query's own IDF-weighted mass. The reasoning behind that floor starts from a real incident: a user with only Notion connected searched for a Cal.com tool and was handed a Notion one, because two generic words carried the whole score.
How fast does a team change take effect?
With Elaichi, a role change or a restriction change takes effect within about two minutes. Both resolve through a 60 second cache plus edge propagation, on every surface, MCP and console and REST alike. Grant revocation, member removal and suspension are different. The OAuth grant is re-read on every single call, and removing or suspending a member revokes every live grant in the same transaction as the membership change. For those three, the next call is accurate.
That is the part a URL cannot do. An address in an admin console does not change when a person's team does. Four onboarding paths feed the same model: single-use invite links with roles and teams pre-assigned, verified-domain auto-join with a default role, SCIM v2 provisioning with group-to-role mapping, and just-in-time SSO. SAML and OIDC SSO are built in-house, with no third-party auth vendor behind them.
Offboarding runs a preflight. Personal connections referenced by a toolbox entry must be transferred to the org, a team or another member, or deleted, or the removal is refused. A private connection is not transferable at all. Delegated toolbox entries surface as a non-blocking warning, and re-pinning is the fix.
Which shape answers "which account did the agent write to?"
That question is settled by the audit trail, not by the address. Elaichi writes one entry per tool-call attempt, succeeded or failed, and both name the account actually reached, taken from the execution rather than from the intent. actor_kind is a recorded field rather than a guess, and ai_assistant is one of its values. Argument names and counts are logged; argument values never are. Errors are recorded as a code only.
Two error strings exist per failed call. The one returned to the caller is derived from the third party's response body. The one written to the audit trail is never derived from the request or the response, because audit records are org-visible and fan out to whatever SIEM you configure.
Audit and application logs share one record shape, and there is one log tenant per organization, enforced in the type system rather than by a WHERE clause. A dropped WHERE clause leaks; a wrong tenant returns nothing. A compliance reviewer does not cost a license, because the read-only Auditor seat is free. Export forwards to your own destination: Datadog is implemented, while Splunk HEC and Microsoft Sentinel are accepted but not yet delivering. If you are weighing several addresses, ask whoever runs them whether the records land in one queryable trail or in several.
Where do credentials sit when everyone shares one URL?
Not in the endpoint, and not in Elaichi. A separate credential service holds per-account secrets, AES-256-GCM at rest, and owns refresh. A failed refresh marks the connection needs_reauth rather than failing silently.
A connect URL is not a credential. It is a one-time session that carries no token, which is why it is safe to return over MCP. Reading back an account's configuration returns public values plus secret_paths, the list of dot-paths that were encrypted, carrying none of their values. Editing one is refused, and the refusal text is identical whichever side produced it.
The tool:execute permission gates the whole endpoint ahead of every scope. Without it, tools/list is empty and a call returns an in-band error naming the permission. Guest, Auditor and Billing Admin lack it. OAuth scopes run mcp:read, mcp:write, mcp:destructive and mcp:tools, and a tool classified forbidden is reachable under no scope at all.
What one address does not protect against
One address does not buy prompt-injection protection. The write gate in the Elaichi agent window does not apply to POST /mcp and cannot, because an MCP server never sees a user prompt. What does hold on the endpoint: RBAC per operation, the forbidden classification, output redaction, scope limits and full audit logging.
Two more facts belong in a residency conversation. The eu and us regions are hard residency, a Cloudflare Durable Object jurisdiction, so compute and storage stay put. The apac region is a placement hint (best-effort). Only eu and us are hard-residency. Organization deletion tears down the workspace but has no path to purge the organization's log tenant, and it returns that residue by name.
When neither shape is worth choosing yet
If one team uses one app through one client, and nobody has asked you who did what, you do not need either shape. Connect the app in the client, write down who has it, and revisit when a second team asks. The case for holding off on a gateway is real, and buying a control plane for three people is overhead you will feel every month.
A short decision path
Ask four questions in order. Does team identity need to be visible in a URL, for isolation or for code a team ships? If yes, a per-team address is the fit. How often do people move between teams, and who edits the admin consoles when they do? Multiply teams by clients, and see whether the number you get is one you want to own. Then ask where the connectors come from: Elaichi authors, maintains and serves the 450+ connectors in its own catalog rather than listing servers other people run.
Gold is $15 per user per month, or $120 per user per year, with a 14 day trial and no credit card to start, and the plan detail lists what sits in each. Free-seat roles, including Auditor, are excluded from the billable count. To see the shape against a specific team's systems, the team rollout pages start from the systems that team already runs, and the other comparisons cover the per-member and self-hosted models.
