Elaichi AI vs running our own MCP servers

What Elaichi AI vs running our own MCP servers really decides

One engineer has a Slack MCP server in a container. A Jira one is half written. Four people are asking for the URLs. Elaichi AI vs running our own MCP servers decides two things: who authors and maintains the connector, and what address your AI clients point at. MCP is the Model Context Protocol, the open standard an AI client uses to discover and call tools in other systems. Both shapes speak it, so the protocol is not the fork in the road.

Running your own means a process per system. Each one has a deployment, a credential store, a URL and an owner. Elaichi is one organization-wide endpoint instead. That endpoint is POST /mcp, standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth, the standard that gives a client a scoped grant without handing it a password. Elaichi authors the connectors and serves them from its own infrastructure, so in that shape your company does not run MCP servers.

The running cost of a fleet has its own breakdown. What follows is the architectural fork: who owns the connectors, how many addresses exist, where the credential sits, how much governance you would write yourself, and what the record looks like afterwards.

Where do the connectors come from in each shape?

With self-hosted MCP servers they come from you, or from whoever published the server you deployed. With Elaichi they come from Elaichi, which authors and maintains 450+ connectors and serves them from its own infrastructure. Elaichi is not a registry of servers other people run, and not a proxy in front of servers you run.

That ownership cuts both ways. A connector you did not write is one you cannot patch at 4pm when a vendor renames a field. In exchange, the upgrade treadmill for every connected app stops being your on-call rotation. When a target service changes its API, the connector changes centrally and you deploy nothing.

Elaichi narrows the gap in two places. Custom connectors are authored from JSON config and can be forked from a public connector. A fork pulls 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. Synthetic tools go further: a DAG of steps, each calling a connection's tool with templated arguments over inputs and prior outputs. Cycles are rejected at save, independent steps run in parallel, and every step passes the same restriction and audit pipeline as any other call.

The line is clear enough. If the behavior you need is not expressible as config and templated steps, write the server yourself. Code beats config there, and it always will.

One organization-wide endpoint, or one URL per server?

Self-hosted MCP servers give you one address per system. Elaichi gives you one address for everything and varies the grant instead of the URL.

Count the work. With servers you run, every client times every server is a configuration somebody maintains. With Elaichi, Claude, ChatGPT and Cursor are each pointed at the same URL through their own admin console, and so is the Elaichi Agent. There are no per-toolbox URLs and no embedded tokens. There is no MCP server to create, list or revoke per person. Adding a fourth MCP client is the same shape as adding the third.

The other side has a real benefit. Handing team A one server URL and team B another is a crude access control that needs no product to implement. For two servers and eight people that is enough, and the case for waiting before you buy a gateway is worth reading first. The weakness shows up later. If the URL is the only thing gating a server, a leaver's client keeps working until somebody rotates it.

What happens when one endpoint serves every tool?

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.

Only the connected half collapses. Control-plane operations stay listed individually, 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, so there is no privilege in it.

Ranking is purely lexical over the tool name, the description and the connector label, with a relevance floor that a tool has to clear before it is returned at all. The reasoning is in the relevance floor behind search_tools. A self-hosted server that advertises every tool it has leaves that filtering to the model.

Where does the credential live in each shape?

In a server you run, the credential sits on the host. It is an environment variable, or a secret manager you wired up. Whoever can reach that server acts as that token. In Elaichi, connector credentials never live in Elaichi at all.

A separate credential service holds per-account secrets, encrypted with 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.

Two levers matter if you are handing over key management. An organization can bring its own OAuth app per connector, supplying client_id, client_secret and scopes. That is gated on connector:manage rather than connection:manage, so everyone who can delete a connection does not silently gain the ability to repoint the organization's OAuth app. BYOK adds per-organization envelope encryption with a customer-managed key in AWS KMS.

What governance would you have to build yourself?

Role checks, per-tool restrictions, and one audit record per attempt. Those three are the homework a self-hosted fleet leaves you, because the MCP specification does not supply them. Whatever you write sits in the critical path of every call.

Elaichi keeps three layers separate. Permissions are about 38 action strings grouped into roles, with exactly one role per member. Resource ACLs are grants of view, use or edit to a user, a team or the whole organization, and a member sees only what they own or what was shared with them. No organization-level permission silently widens a listing. Restrictions decide which connectors and which individual tools a target may reach. Restriction 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 user override replaces role rules entirely rather than layering on top of them.

Two details are worth copying even if you build your own. An allow rule that names nothing denies everything, because the allowlist stage engages on the presence of a rule and not its contents. And a block matches the tool name or the pinned operation, while an allow matches the pinned operation only, for the reason set out in why blocks bind the name and allows bind the operation. 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 are stripped from the advertised schema and merged over caller arguments at execution, so passing the key cannot un-freeze it.

Timing is the part people state wrongly. A role or restriction change takes effect within about two minutes, resolving through a 60 second cache plus edge propagation. Only grant revocation, member removal and suspension are effective on the next call. removing or suspending a member revokes every live grant in the same transaction as the membership change.

How do you answer what happened afterwards?

With Elaichi, one query. The audit trail uses one record shape for audit events and application logs, which is what lets a single query answer what happened instead of correlating two systems by eye. Across a fleet of servers you host, that correlation is tracing you build.

There is one entry per tool-call attempt, succeeded or failed, and both name the account actually reached, taken from the execution rather than the intent. actor_kind is a recorded field with values including user, system, staff, scim, api_token and ai_assistant, so whether an AI took the action is written at the point of action rather than guessed from a user agent. Argument names and counts are logged; argument values never are.

An error-text firewall keeps two strings per failed call apart. 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 organization-visible and fanned out to whatever SIEM the customer configured. Each organization gets its own log tenant. The trail is append-only and eventually consistent, so a row may take a moment to appear. Export to Datadog is implemented, while Splunk HEC and Microsoft Sentinel are accepted but not yet delivering. A compliance reviewer reads all of it on a free Auditor seat.

What does offboarding look like on each side?

On servers you host, offboarding is a checklist: revoke the keys, shut down the instance, hope nobody kept a copy of the URL. In Elaichi it is a preflight that refuses the removal until the loose ends are resolved.

A personal connection referenced by a toolbox entry has to be transferred to the organization, a team or another member, or deleted, before the member can be removed. Unreferenced personal connections are cleaned up. A private connection is not transferable at all: a credential only its owner could ever use does not become someone else's because its owner left. Delegated toolbox entries surface as a non-blocking warning, and re-pinning is the fix rather than a credential decision. The same-day version for non-employees is in contractor offboarding.

When running your own MCP servers is the right answer

Three cases, and none of them are close.

First, the control plane has to sit inside your own network. Elaichi is hosted. The residency lever is region choice at organization creation. Eu and us are hard residency covering compute and storage. Apac is a placement hint (best-effort placement, not the same contractual promise). If the requirement is a deployment in your own VPC, or a database with no route out of the perimeter, that is a different product shape.

Second, the system is yours and its behavior is not config-shaped. An internal pricing service with real branching logic, or a datastore with no public API, is a server you should write. You will finish it faster than you would fight a config file.

Third, you already run the servers and the gap is governance over them. Lunar.dev describes MCPX as a self-hosted enterprise MCP gateway that sits between agents and the MCP servers, APIs and LLM providers they use (lunar.dev, checked September 2026). Tyk's MCP Gateway proxies and governs remote MCP servers and can generate an MCP proxy from a managed REST API (Tyk docs, checked September 2026). Composio's enterprise page lists self-hosting at the Enterprise tier alongside SSO over SAML and OIDC (Composio enterprise, checked September 2026). A gateway in front of servers you run is a different job from being the server.

One thing neither shape fixes. Elaichi's prompt-injection write gate lives in the agent window and does not apply to POST /mcp, because an MCP server never sees a user prompt. What does hold on the endpoint is RBAC per operation, the forbidden classification, output redaction, OAuth scope limits and full audit logging. A server you host has the same blind spot, and none of that list until you build it.

How to decide this in an afternoon

Work through five checks in order. The first one ends the exercise for most small teams.

1. List the systems and the people. Write down every system an assistant needs to reach and who needs each one. Two systems and one team means you should run the servers.
2. Count the clients. Multiply clients by servers. That product is the configuration you maintain forever in the self-hosted shape.
3. Run the leaver test. Pick someone who left last quarter and ask how long their access to each server survived.
4. Ask the audit question. "Which of our two Notion workspaces did the agent write to?" If your servers cannot answer that from one query, the record is your gap, not the routing.
5. Trial one team. Elaichi's Gold plan is $15 per user per month, or $120 per user per year, 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. The two plans are Gold and Black, with a 14-day trial.

Start with the app you cannot afford to get wrong. The connector catalog shows what is already authored, rollouts by team show the order people actually do this in, and how Elaichi and Composio differ covers the case where the alternative is a hosted vendor rather than your own servers.