What is the MintMCP alternative if you run no MCP servers?
If you run no MCP servers, the MintMCP alternative to weigh is one that is the server itself, not only a gateway in front of servers. Elaichi is that shape: it writes, hosts and serves most of its connectors, and governs vendors' own MCP servers for the rest. Every AI client reaches them through one organization-wide MCP endpoint, so your team has nothing to run.
Someone in support pointed Claude at a work tool last week and it worked. Now finance wants the same thing, and you have to decide what the company buys. Two different products sit behind the word gateway. One is a hosted gateway over a catalog of MCP servers the vendor lists. The other is a control plane whose connectors the vendor writes and runs itself. That fork decides more than the headline catalog number does.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.
MintMCP's gateway page describes a hosted MCP gateway with a large catalog of servers, and it quotes a customer who needed one that "hosts our MCPs and manages credentials" (mintmcp.com/mcp-gateway, checked October 2026). Elaichi's endpoint, by contrast, is a single network address a client signs in to, with connectors Elaichi maintains on its own infrastructure behind it. Both shapes are real. They fit different readers.
| Axis | MintMCP | Elaichi |
|---|---|---|
| What you run | A gateway fronting MCP servers, MintMCP-hosted or your own (mintmcp.com/mcp-gateway, checked October 2026) | Nothing; Elaichi is the MCP server itself |
| Connector authorship | A catalog of MCP servers hosted or listed by MintMCP | Elaichi serves 600+ connectors, authoring most itself and governing vendors' own MCP servers for the rest |
| Per-org audit | Ask MintMCP what one record holds | Audit history kept apart for each organization; actor_kind on every entry; export to your Datadog with the Black plan, launching soon |
| Tool-list unification | Many servers behind one gateway; ask how many endpoints a rollout produces | One POST /mcp endpoint for every connected account |
| Offboarding | Ask MintMCP what happens on a member's last day | Grants revoked on the next call; a preflight lists every connection the member owns; a shared one can be transferred to another active member, and a private one nothing depends on is deleted with the member |
| Pricing model | Ask MintMCP for the billing unit | Per seat: Gold lists at $15 per user per month in USD, with a 14-day trial |
Why does it matter who authors the connector?
Authorship decides who you call when a tool breaks, and what a governance rule is allowed to bind to. A catalog of servers other people run is also a catalog of other people's release schedules.
Elaichi ships 600+ connectors, and most are its own. The rest are native MCP connectors, vendors' own servers that Elaichi staff publish one at a time rather than pulling in a registry. Companies do not run MCP servers to use either kind. Custom connectors are authored from JSON config. They can be forked from a public connector. A fork can pull upstream changes through a review surface that separates new tools, safe updates, config diffs, conflicts and upstream removals. Conflicts and destructive removals stay unchecked by default, so nobody accepts a deletion by clicking through. A connector cannot be deleted while connections still use it.
The trade-off is plain. An authored connector makes the tool surface one party's responsibility: the tool names, the argument schemas and the operation each tool maps to. The cost is reach. The catalog grows only as fast as one vendor writes connectors, and an app outside it means building a custom one.
When is MintMCP the better buy?
MintMCP is the better buy when breadth of servers matters more than who wrote them. MintMCP's gateway page describes hosted connectors, a large server catalog, and a customer who wanted a gateway that "hosts our MCPs and manages credentials" (mintmcp.com/mcp-gateway, checked October 2026). Two readers should weigh that seriously.
- The team that needs one unusual server this month. A large server catalog is the likelier place to find it. Elaichi's catalog of 600+ connectors either has the app or it does not.
- The platform team that has written MCP servers of its own and wants them hosted, with the credentials managed for it. Elaichi does not host servers a company wrote. It is the server for the connectors it authors and any your team builds from JSON config, and a company server added as a remote MCP connector still runs on your side.
If the app you need is niche and you need it next week, breadth wins. If your problem is that nobody can say what the agent may call, authorship wins.
A different reader wants a door rather than a catalog. Two internal servers and a handful of vendor servers need one address in front of them. The governance question is per server rather than per tool. For that reader a gateway is the right object to buy, and several products are built for it.
Lunar.dev describes MCPX as a self-hosted enterprise MCP gateway sitting between agents and the MCP servers, APIs and LLM providers they use. It has an open-source version on GitHub (lunar.dev, checked October 2026). Tyk describes an MCP Gateway that proxies and governs remote MCP servers (tyk.io, checked October 2026). Zuplo describes an MCP Gateway that federates MCP servers behind one OAuth-protected gateway (zuplo.com, checked October 2026). OAuth here is the sign-in flow that hands a client a revocable grant instead of a password.
If your users are platform engineers, that shape reads naturally. If they sit in finance and legal, it reads like a project. What running MCP servers yourself really costs works through that estate. A wider comparison of MCP gateways sets the other products side by side.
Who is Elaichi built for?
The IT or operations lead whose users sit in support, finance, sales and legal. The job is pointing three different AI clients at the same company data. A MintMCP alternative of this shape is judged on the address model and on who maintains the connector, not on server count.
Elaichi serves one organization-wide endpoint: POST /mcp, standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth. Claude, ChatGPT and Cursor all point at that one address. An admin adds it once where the client allows, and each member then connects and signs in with their own grant. Any other MCP client uses the same address. There are no per-toolbox URLs and no embedded tokens. A toolbox is a saved set of tools with the accounts behind them, and it does not get its own URL. The twelve teams on the use cases page are the same list of readers.
How many addresses does the rollout produce?
With Elaichi, one. Clients point at the single endpoint and each person signs in as themselves. There is no MCP server to create, list or revoke per user, because the address is fixed and the grant is what varies. Adding a fourth client later is the same piece of work as the first three.
Other shapes multiply what sits behind the address. On Zapier MCP every client shares one URL, but "Each MCP client gets its own MCP server", so each member holds a server per client (docs.zapier.com, checked October 2026). That is the per-member shape covered in one organization server, not one per member. Composio's MCP Gateway page says "each team gets its own MCP endpoint carrying only the tools it is permitted to use" (composio.dev, checked October 2026). The side-by-side on company-wide access works through what that means day to day.
Count the addresses and servers a 200-person rollout produces before you count the connectors. One number changes your support load and the other does not.
Can renaming a tool get around a rule?
No. In Elaichi, a rule binds to an operation, not to a label a vendor controls. Three layers stay separate. Permissions are 58 action strings grouped into roles, with exactly one role per member, so each role is a complete persona. Resource sharing is a grant of view, use or edit on a resource to a person, a team or the whole organization. A member sees only what they own or what was shared with them. Restrictions decide which connectors and which individual tools a target may reach.
By design, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Within each layer, blocks always beat allows. Note that the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything.
A block catches a tool by its name or by the operation behind it. An allow counts only the operation, because whoever edits the connector's documentation can change a tool's displayed name. That asymmetry has its own post: why block matches the name and allow matches the operation. Enforcement runs at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. A role or restriction change takes effect within about two minutes. Grant revocation, member removal and suspension are effective on the next call, and so are revoking a share and disconnecting an account.
Can you freeze an argument the model should never set?
Yes. Frozen parameters are a per-entry map over a tool's flattened argument space, and they work in two directions at once. Frozen keys are removed from the schema the model is shown, so it has no argument to set. Frozen values are merged over caller arguments at execution, so passing the key cannot unfreeze it.
The full precedence is entry defaults, then caller or model arguments, then frozen parameters. Because Elaichi authors the execution path, the same mechanism applies to every connector rather than to the subset that happens to support it.
How does the model find a connected tool?
In Elaichi, connected tools are never listed one by one, however few there are. A model reaches one by searching with search_tools, then calling it through execute_tool.
Control-plane operations stay listed individually, and search_tools never returns one. A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema. Running a tool through execute_tool adds no privilege: it unwraps to the same name and arguments and falls through the identical gates. Ranking is lexical, with a relevance floor that keeps a vague query from returning a tool from the app you did not ask about. The reasoning is set out in how the search ranking floor works.
What counts as a credential, and where does it live?
In Elaichi, the URL is not a credential. POST /mcp is a single address behind OAuth with no token embedded in it, so knowing it grants nothing. The MCP authorization spec rules out the alternative for any server: access tokens "MUST NOT be included in the URI query string" (MCP authorization). A connect URL is not a credential either. It is a one-time session that carries no token, which is why it is safe to return over MCP.
Connector credentials never live in Elaichi. A separate credential service holds per-account secrets, encrypted with AES-256-GCM at rest, and owns refresh. Connections created since 2026-10-05 have their credentials placed in the organization's region: inside the EU or US jurisdiction for those regions, and by best-effort placement for APAC. Older connections stay where they were until reconnected, which copies them into the region. A failed refresh marks the connection needs_reauth rather than failing silently. 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.
An organization can supply its own OAuth app per connector. That right is gated on connector:manage, not connection:manage. Otherwise everyone who can delete a connection would also gain the power to repoint the organization's OAuth app. In Elaichi, customer-managed keys in AWS KMS come with the Black plan, which is launching soon, as the pricing page shows.
What happens to a member's access on their last day?
On Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. Before the removal goes through, a preflight checks the connections that member owns.
The preflight lists every connection they own, private and shared alike. A private connection that a shared toolbox still relies on blocks the removal until the admin transfers it to an active member. A private connection nothing else depends on cannot be transferred and is deleted with the member. A connection is never handed to the organization, to a team, or to the admin running the removal. Delegated toolbox entries surface as a non-blocking warning, and re-pinning the entry is the fix.
A shared connection a team still depends on is left untouched unless the admin deletes it. The admin transfers it to a member who is staying, which leaves every grant on the connection exactly as it was.
What does the audit trail record?
What one MintMCP record holds, and whether it names the account a call reached, is a question to put to MintMCP. On Elaichi's side, the useful test is the first question after an unexpected change: which of two Notion workspaces did the agent write to?
Elaichi's audit log keeps one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry records the account the call actually reached, not the one it was aimed at. A field called actor_kind records who acted, instead of leaving it to be guessed from a user agent. A call from Claude or Cursor is recorded under the person who signed in, with surface mcp and the OAuth client named. Each organization's audit history is kept apart, and a compliance reviewer costs nothing, because the read-only Auditor role is a free seat. What an AI audit log must capture covers the fields in full.
Questions to put to MintMCP before you sign
Seven questions settle most of this comparison, and MintMCP should answer them in writing. A comparison page, this one included, is no substitute for the vendor's own answer.
- Which servers in the catalog do you author, which are third party, and who fixes one when its upstream API changes?
- How many gateway URLs exist once 200 members are onboarded, and who can revoke one?
- Where are connector secrets held, who can read them back, and can we bring our own OAuth app?
- What happens to a member's access on the day they leave our directory?
- What does one audit record hold, and does it name the account a call reached?
- What is the billing unit: seats, tool calls or servers?
- Which region holds the data, and what exactly does the region cover?
Elaichi's answer to the last one is three regions, EU, US and APAC, chosen when the organization is created. For EU and US, the organization's data store and the execution of its org-scoped requests and tool calls stay in that jurisdiction. APAC uses best-effort placement and is not a residency guarantee. The audit trail is stored in one EU log instance for every region. More of the security detail sits on the security page.
When does neither shape earn the spend yet?
If four people each use one app with their own account, and you can still name every tool call from memory, buy nothing. Write the list down, turn on the AI client's own admin controls, and revisit when a second team asks. Buy one of the two shapes when you cannot answer who reached what, or when removing somebody takes more than one action. The threshold test for a gateway lists the other signals.
One limit applies before you shop at all. 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 permission checks per operation and the forbidden classification, which no OAuth scope can reach. Output redaction, scope limits and an audit row for each call that reaches execution hold too. Ask any vendor that claims prompt-injection protection exactly what it inspects, and where.
If the shape fits, the next two pages are the connector catalog and plan pricing. Elaichi has two plans, Gold and Black. Gold lists at $15 per user per month in USD, and the pricing page shows the price for your region. Gold starts with a 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.
