MCP governance platforms compared: what to look at
MCP governance platforms compared this way reduce to four mechanics, not feature grids. Where the connectors come from. How many addresses your AI clients point at. Where the access decision gets made, and how fast a change takes effect. What the record shows afterward. Most rundowns stop at a checkbox table, and a table hides the differences that later generate tickets.
The situation is close to identical at most companies. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps Engineering already runs Cursor. Sales lives in ChatGPT. Someone in support has already pasted a customer record into Claude. You need to give all three real access to real systems without handing out API tokens. You also need to answer, three weeks later, which account an agent wrote to.
Where do the connectors come from?
There are three origins, and the answer decides who you call when a tool breaks. The vendor authors the connectors. The vendor fronts servers somebody else runs. Or you run the servers yourself.
Elaichi authors, maintains and serves 450+ from its own infrastructure. Companies do not run MCP servers to use Elaichi, and Elaichi does not wrap a registry of servers other people run. MintMCP describes a hosted gateway that "hosts our MCPs and manages credentials", with hosted connectors and a large server catalog (https://www.mintmcp.com, checked September 2026). Lunar.dev describes MCPX, a self-hosted enterprise MCP gateway that sits between agents and the MCP servers, APIs and LLM providers they already use (https://www.lunar.dev/, checked September 2026). Tyk is an API management platform whose MCP Gateway proxies and governs remote MCP servers (Tyk docs, checked September 2026). Zuplo federates MCP servers behind one OAuth-protected gateway (https://zuplo.com/mcp-gateway, checked September 2026). Kong AI Gateway supports exposing APIs as MCP tools (https://developer.konghq.com/ai-gateway/, checked September 2026).
The trade-off in the Elaichi model is real. A vendor-authored catalog means you wait for the vendor when the app you need is missing. The answer is custom connectors, authored from JSON config or forked from a public connector, with upstream changes pulled through a review surface that separates new tools, safe updates, conflicts and upstream removals. The permission to create one, connector:create, is flagged high trust, because a custom connector can be pointed at any destination. If you would rather own the servers and the patching, the cost of running them yourself is worked through separately.
One address, or one per team and per member?
The address model shapes your rollout more than any policy feature does. Elaichi serves one organization-wide MCP endpoint, POST /mcp, where an endpoint is the single network address a client calls. It is standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth, the sign-in standard where the client gets a token from the provider rather than from you. There are no per-toolbox URLs and no embedded tokens, a toolbox being a saved set of tools and the accounts behind them. Claude, ChatGPT and Cursor are each pointed at that one address through their own admin console. The address never varies. The grant does.
Other shapes divide the address. Composio's MCP Gateway page says each team gets its own MCP endpoint, SSO authenticated (https://composio.dev/mcp-gateway, checked September 2026). Zapier MCP goes per member, and its rollout guidance is to "give each user their own server and token rather than sharing one" (https://docs.zapier.com/mcp/manage/rollout/overview, checked September 2026). For most MCP clients the member signs in 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 it "grants whoever holds it the ability to run the server's tools". Zapier says to treat it like a password (https://docs.zapier.com/mcp/overview/how-connections-work, checked September 2026).
Count the addresses you would have to create, document and later remove for sixty people. That number is the rollout. The per-member arithmetic is worked out in full in the one endpoint instead of one per user write-up.
Where does the access decision get made?
In Elaichi the decision is made in three separate layers, and keeping them apart is what keeps an evaluation honest. RBAC, role-based access control, is about 38 action strings such as tool:execute and audit:view, grouped into roles. A member holds exactly one role, enforced by a unique index, so each role is a complete persona. The system roles form a strict subset chain from Guest up to Org Owner, with Billing Admin and Auditor sitting off the chain as free seats.
Sharing is one building block: 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, and no organization-level permission silently widens that listing.
Restrictions are the governance layer, covering which connectors and which individual tools a target may reach. Targets are role or user only. There is no organization target, because the organization 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. Also, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. That is the strictest rule you can write, and people write it by accident.
A block matches the tool name or the pinned operation, while an allow matches the pinned operation only. The reasoning is set out in why a block binds the label and an allow binds the operation. Enforcement runs at four points against the same resolver: browse, connect, advertise, execute, plus a final check on the fully substituted outbound URL. That is the code that decides allow or deny. Identity arrives through SAML or OIDC single sign-on built in-house, with SCIM v2 provisioning for users and groups and group-to-role mapping.
How fast does a change take effect?
Ask every vendor this with a number attached, and refuse the word immediately. In Elaichi, a role membership change or a restriction change takes effect within about two minutes, on MCP, the console and REST alike, because it resolves through a 60-second cache plus edge propagation.
Three things are faster. Grant revocation, member removal and suspension are effective on the next call. The grant's revoked state is re-read from the organization store on every single call, and removing or suspending a member revokes every live grant in the same transaction as the membership change. Those two speeds answer different questions, and an evaluation that collapses them into one number will mislead whoever reads it next.
What does the record show after the call?
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. "Which of my two Notion workspaces did the agent write to?" is the first question after an unexpected change. An audit log is the append-only history of what happened. Elaichi uses one record shape for audit events and application logs. A single query answers that question instead of two systems correlated by eye.
actor_kind is a field, not an inference. Its values include user, system, staff, scim, api_token and ai_assistant, so whether an AI took the action is recorded at the point of action. Recorded per call: the operation and tool, the connection, the classification, whether it was approved, the outcome, and an error code only. Argument names and counts are logged. Argument values never are.
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 visible across the organization and fanned out to whatever log destination you configure. There is one log tenant per organization, enforced in the type system rather than by a WHERE clause, so a dropped clause returns nothing instead of leaking. Export is implemented for Datadog, while Splunk HEC and Microsoft Sentinel are accepted but not yet delivering. The trail is eventually consistent, so a row may take a moment to appear.
Other vendors describe their own records. Composio's enterprise page says "every tool call is logged with the user, team, tool, action and outcome, denied calls included" (https://composio.dev/enterprise, checked September 2026). Zapier MCP documents a History tab showing user-level activity logs for tool calls (https://docs.zapier.com/mcp/manage/security, checked September 2026). Read both pages yourself before you compare them. In Elaichi, reviewing a trail does not cost a license, because the read-only Auditor seat is free.
What does the person in Claude or ChatGPT actually see?
They see a sign-in, and then a shorter tool list than they expected. 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, and the control-plane catalog alone is dozens of operations, so one connected app is normally enough to trip it. Collapse is the normal case, not an edge case.
Only the connected half collapses. Control-plane operations, named elaichi__{resource}__{operation}, stay listed individually, and search_tools never returns one. But execute_tool is only a naming indirection: it unwraps to the same name and arguments. It falls through the identical gates, with no separate execution path and no privilege in it. Tools withheld by a restriction are excluded from the count, because they were handed to nobody.
Ranking is purely lexical over tool name, description and connector label, with a relevance floor: a tool must account for at least half the query's own IDF-weighted mass. Scaffolding words such as set, connection, frozen and more are dropped from description tokens, because otherwise every merged tool scores the same and the model gets an arbitrary account. The tool search relevance floor post shows the scoring.
Two further things show up at the client. Frozen parameters are stripped from the advertised schema, so the model never sees the key, and frozen values are merged over caller arguments at execution, so passing the key cannot un-freeze it. And tool:execute gates the whole endpoint ahead of every scope: without it the tool list is empty and a call returns an in-band error naming the permission. Guest, Auditor and Billing Admin lack it.
What happens when somebody leaves?
Removal revokes the departing member's live grants on the next call, and the preflight decides what happens to their connections. Personal connections referenced by a toolbox entry must be resolved first, by transfer to the organization, a team or another member, or by deletion, or 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 ever use does not become someone else's. Delegated toolbox entries surface as a non-blocking warning, and re-pinning is the fix. The contractor case is walked through step by step in what to do the day access ends.
Connector credentials never live in Elaichi. A separate credential service holds per-account secrets, AES-256-GCM at rest, and owns refresh, marking a connection needs_reauth rather than failing silently. An organization can supply its own OAuth app per connector, gated on connector management rather than connection management. So everyone who can delete a connection does not silently gain the ability to repoint the organization's OAuth app.
Where the Elaichi model stops
Three limits belong in any comparison. 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: RBAC per operation, the forbidden classification that no OAuth scope can reach, output redaction, scope limits and full audit logging.
Residency is only partly hard. The eu and us regions are a jurisdiction-pinned Cloudflare Durable Object, so compute and storage both stay put. The apac region is a placement hint (best-effort). Only eu and us are hard-residency. Deletion has a gap: organization deletion tears down the workspace but has no path to purge the organization's log tenant, and it says so by returning the residue by name. Encryption at rest, customer-managed keys in AWS KMS, session revocation and the offboarding preflight are described on the security page.
Price, seats and what you are billed for
Billing units differ, and they change the total more than the sticker price does. Composio bills by the tool call, with a free Hobby tier, a $29 per month Pro tier, and a custom Enterprise tier listing SSO, SCIM and customer-managed keys (https://composio.dev/pricing, checked September 2026). Zapier MCP has no separate billing, and states that each successful tool call through an MCP server consumes two tasks against the plan allowance, while failed calls consume none (https://docs.zapier.com/mcp/features/usage, checked September 2026).
Elaichi bills by the active seat. There are two plans, Gold and Black, with a 14-day trial. Gold is $15 per user per month, or $120 per user per year. The trial runs 14 days with no credit card, and checkout sets the paid trial to the remaining days rather than granting a fresh 14. Suspended members and the free-seat roles, Guest, Billing Admin and Auditor, are excluded from the seat count. If a trial ends without checkout the workspace pauses, gated routes return a structured error, and nothing is deleted. The current numbers are on the plans page.
When none of this is the right purchase yet
If two engineers run local MCP servers on their own laptops, a control plane is overhead. Local development does not share credentials across a company, and the developer holds the key on the machine. The same is true if three people use one app through one client, and everyone can name every connected account from memory.
What a control plane solves is shared credentials, mixed clients and the question asked afterward. The markers for being early are listed in the case for waiting, and they are worth reading before a procurement cycle starts.
A comparison you can run in an afternoon
Run the same five checks against each vendor, using the vendor's own documentation and your own trial. Write the answers down, because they change faster than any published table does.
Then point one real client at one real account. Browse the connector catalog for the systems your teams already run, and check the playbooks by function for the order to roll them out in. If your comparison is specifically against a developer-facing toolkit, the Elaichi and Composio breakdown goes deeper than this page does, and the product overview covers the rest of the control plane.
