Do I need an MCP control plane at five people and one app?
| Axis | Native AI-client connectors (Claude, ChatGPT direct) | Governed MCP control plane (Elaichi) |
|---|---|---|
| Team size fit | Fine for a few people with one account each in one client | Earns its keep once accounts, reviewers or clients multiply |
| Governance visibility | The operator sees their own chat history | Read-only Auditor seat and org-wide audit queries |
| Offboarding | Revoke inside each app, each client, per member | Member removal revokes every grant in one transaction; next call fails |
| Seat cost | Included in each AI client's subscription | $15 per user per month; Auditor, Guest and Billing Admin are free seats |
| Per-tool restrictions | Whatever the app's own roles allow | Role or user rules, frozen parameters, forbidden tool class |
| Audit | Per-client chat history and per-app native logs | One record shape across audit events and application logs |
Probably not. Five people, one CRM, everybody already an admin inside it, one AI client between them. In that shape of company the answer to "do I need an MCP control plane" is no, and a vendor who tells you otherwise is selling. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps A control plane is the layer above that: it decides which of those tools each person may reach, and records what happened after.
The reason the answer is no at that size is structural. Each person connects their own account inside the AI client's own connector settings. That account already carries that person's permissions in the app. The app's own roles are the restriction, written by someone who understood the data. The app's own log names one human, because each human has exactly one account. Nothing is shared, so nothing needs a second layer of governing.
The cost side is just as plain. Elaichi 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 Five seats is $75 a month spent on a problem that has not arrived. The longer version of this argument, including the setup that does hold up at that size, is in the case for waiting.
Signal one: more accounts than there are people
Count accounts, not headcount. Once your team holds more SaaS accounts than it has members, the question "which account did the agent just write to" stops having an obvious answer. That is the first real signal.
The extra accounts arrive quietly. A second Notion workspace for a client project. A shared finance login two people know. A service account for the warehouse that nobody remembers creating. Each one breaks the assumption the small setup rested on, which was one human, one account, one log line.
Elaichi writes one entry per tool-call attempt, succeeded or failed, and both name the account. The recorded connection is the account actually reached, taken from the execution rather than from the intent, because the intent is what you already doubt. Argument names and counts are recorded; argument values never are.
The other half of the fix is frozen parameters. A frozen key is stripped from the schema the model is shown, and its value is merged over whatever the caller passed at execution time. Pin the workspace, and the agent cannot write to the other one, because it never sees the field.
Signal two: someone who is not the operator has to answer for it
The second signal is a person outside the room asking what an agent did. A customer security questionnaire, a clause in a renewal, an internal reviewer, a board packet. When the answer has to satisfy someone who did not make the call, a screenshot of a chat window stops being evidence.
This is the signal most teams misread, because it does not feel like a technical event. It is a change in who the audience for the record is. A personal AI client shows the operator their own history. It does not give a reviewer a queryable, append-only trail, filterable by actor and time, that survives the operator changing laptops.
Elaichi keeps one record shape for audit events and application logs, one log tenant per organization, and a free read-only Auditor seat. The reviewer does not consume a license, and the Auditor role lacks tool:execute, so a compliance seat cannot call a tool. You can forward the trail to your own destination; Datadog is implemented, while Splunk HEC and Microsoft Sentinel are accepted but not yet delivering.
Signal three: a second AI client, or a second team
The third signal is multiplication. One client and one team is a setup task. Two clients across three teams is a matrix, and every account has to be connected in each cell of it.
Per-person setup is a legitimate design, and it is what several products are built for. Zapier's own rollout documentation tells an admin to give each user their own server and token rather than sharing one, and says each member still signs in and runs tool calls as themselves (Zapier docs, checked September 2026). For most MCP clients that sign-in is OAuth inside the client; clients not on Zapier's list use a connection token instead. That shape fits a company whose AI work already lives inside a Zapier account.
Elaichi takes the other shape. There is one organization-wide endpoint, POST /mcp, behind OAuth, with no per-toolbox URLs and no embedded tokens. Claude, ChatGPT and Cursor are each pointed at the same address through their own admin console. A fourth client is the same job again, not a fork. If the choice in front of you is specifically between the two address models, the endpoint-per-member comparison covers it in detail.
What does not count as a signal
Plenty of things feel like the moment and are not. Volume is the most common. Ten thousand tool calls a month through one person's own account is still one person's own account, and a control plane governs nobody new.
Curiosity is another. Wanting to understand MCP is a good reason to read the specification and a poor reason to buy a seat for everyone. Catalog size sits in the same bucket. 450+ connectors matter when you need the twelfth one governed, not when you need the first one working.
One departure is also not a signal by itself. If a contractor leaves and you can revoke their single account in the single app, do that today and move on; the offboarding checklist is the short version. And if the question you are actually weighing is whether to run MCP servers yourself, that is a different decision with a different cost curve, laid out in the run-it-yourself math.
What changes on the day a signal fires
When one of the three is true, the work is smaller than it looks, and the order matters. Connect each account once in Elaichi instead of once per person per client. Assign each member exactly one role; a unique index enforces one role per member, which is why every role is a full persona rather than a bolt-on.
Then write restrictions. A restriction targets a role or a user, and nothing else. There is no organization-level target, because the organization default is the absence of any rule, which means allow-all. A user-targeted rule replaces the role rules for that person rather than layering on them. Within the winning layer, blocks always beat allows, and an allow rule that names nothing denies everything. That last one is the strictest thing you can express and the easiest to write by accident.
Timing is the fact most posts get wrong. A role change or a restriction change takes effect within about two minutes. Only grant revocation, member removal and suspension are effective on the next call, because the grant is re-read from the org store every single time.
Expect the tool list to collapse. Past 30 tools, counting control-plane operations and connected tools together, the connected half hides behind search_tools and execute_tool. One connected app is usually enough to cross that line, so collapse is the normal case. How that search decides what the model sees is worked through in the relevance floor write-up.
What a control plane does not fix
Some things stay yours. 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 that no OAuth scope can reach, output redaction, scope limits and full audit logging.
Residency is precise rather than universal. The eu and us regions are hard residency, so compute and storage stay in that jurisdiction. The apac region is a placement hint (best-effort). Only eu and us are hard-residency.
Deletion is partial and says so. Deleting an organization tears down the workspace but has no path to purge that organization's log tenant, and the response returns the residue by name. If your obligation is total removal, that gap is the thing to test first.
Where the money lands either way
Moving early costs $15 per user per month plus an afternoon. Moving late costs a reconstruction job: working out which of four accounts an agent touched, from logs that were never written, for a reviewer who wants an answer this week. The reconstruction is the expensive one, and it is the only one with a deadline attached.
The trial is 14 days with no credit card. Checkout collects a card and sets the paid trial to the remaining days rather than starting a fresh 14, so it is one continuous trial. If the trial ends without checkout the workspace pauses: gated features lock, gated routes return a structured error, and nothing is deleted. The two plans are Gold and Black, with a 14-day trial. to fall back to, which is the honest reason to wait until a signal fires.
If you want to check coverage before deciding, the connector catalog lists what is served today, and the team pages show the shape of a first rollout for support, finance, sales and legal. The comparison against client-native connectors, which is the setup most small teams are already running, sits in one plane versus many clients. Seat prices and what each plan gates are on the pricing page.