Do you already run MCP servers?
Count them first, because the count decides the answer. With none, the Lunar MCPX alternative to look at is a hosted MCP server such as Elaichi, which serves your SaaS accounts with no servers of your own to run. With several, a gateway is the right shape, and MCPX belongs on the shortlist. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.
The gateway case looks like this. An engineer stands up an MCP server for the internal ticketing API. A data team ships a second one over the warehouse. A year later there are nine, each with a token file, a deploy story and its own opinion about who may call what. That estate has a gateway-shaped problem, and a gateway is the right purchase.
A company with zero MCP servers reads the same gateway pages and reaches the wrong answer. Support, finance and legal are not waiting for a proxy. They are waiting for Salesforce, Xero and Jira to show up inside ChatGPT with limits attached. Buying a gateway in that state means first finding or building the servers it is supposed to govern.
What is Lunar.dev's MCPX built for?
MCPX is built for an estate that already has servers in it. Lunar.dev presents MCPX as an "Enterprise MCP Gateway" that sits between agents and the MCP servers, APIs and LLM providers they use (checked October 2026). The same page says MCPX is fully self-hosted, running inside your own infrastructure, and an open-source version is on GitHub.
Read the shape of that description. A gateway is a middle. It assumes two ends: agents on one side, servers and APIs on the other. Its value comes from consolidating control over servers and APIs your agents already use. If those exist, that value arrives on day one. You keep the server code, the network path and the release cycle, and you gain one place to watch the traffic.
The same description implies the standing work. A middle is only as current as its ends. Nine servers still need nine upgrades when a vendor changes an API, and nine owners on call when one of them stops refreshing a token. That is a fair price for an estate that wanted those servers. It is a strange price for an estate that never asked for them.
Tyk and Zuplo sell a related shape from an API management starting point (both checked October 2026). Tyk's MCP Gateway proxies and governs remote MCP servers. Zuplo's MCP Gateway federates MCP servers behind one OAuth-protected gateway.
What does the Boomi acquisition change?
It changes who owns the roadmap, not the shape of the product. Boomi announced a letter of intent to acquire Lunar.dev on May 13, 2026 (Boomi press release). It has since completed the acquisition (Boomi blog, checked October 2026).
Treat that as a set of questions to put in writing, not as a verdict. Ask about standalone pricing now that the gateway sits inside a larger platform. Ask about the release cadence of the open-source version. Ask whether support terms survive without a wider platform contract. Ask which buyer the roadmap now follows. An acquisition is not a reason to rule a product out. An unanswered roadmap question is a reason to keep the first commitment short.
What does a Lunar MCPX alternative look like with no servers to front?
| Axis | Lunar MCPX | Elaichi |
|---|---|---|
| Where it runs | Self-hosted, inside your own infrastructure, which some auditors require | Hosted service; every SaaS account served through one org-wide POST /mcp endpoint behind OAuth |
| What it serves | The MCP servers, APIs and LLM providers your agents already use | 600+ connectors, most authored by Elaichi and the rest vendors' own MCP servers it governs |
| Who maintains the tools | Whoever runs each server behind the gateway | Elaichi; custom work through JSON config, or forks with a review step for upstream changes |
| Per-tool rules | Ask how rules are written and where each one is enforced | Block or allow rules on a role or a user, checked wherever a member can reach a connector or tool, including the outbound URL |
| A leaver's access | Ask how it is cut at the gateway and at each server | Grant re-read on every call; a preflight for personal connections |
| Audit | Ask what the gateway records and what each server records | One record shape across audit and application logs; each entry names the account reached |
| Cost model | Engineer time to run it; open-source version on GitHub; commercial terms to confirm after the Boomi deal | Gold lists at $15 per user per month in USD; free read-only Auditor seat |
For a company with no servers, the server is the cost, so the useful Lunar MCPX alternative deletes that line rather than governing it. A gateway routes traffic to servers that already exist. Elaichi serves the tools itself.
Elaichi is a governed MCP control plane. Every SaaS account the company uses is connected once, and the tools those accounts expose are served through one organization-wide endpoint: POST /mcp, standard MCP over Streamable HTTP, JSON-RPC 2.0, stateless, behind OAuth. No toolbox gets its own URL, and no token rides inside a link. An admin adds that address once where each AI client allows it, and each person then connects and signs in as themselves. Connecting ChatGPT shows one client's flow end to end. Elaichi authors, maintains and serves most of the connectors from its own infrastructure, and the catalog runs to 600+. The rest are vendors' own MCP servers that Elaichi staff publish one by one, not an open registry, and there is nothing for your team to deploy.
Who decides what a tool call may touch?
Three layers decide it, and they stay separate. Permissions group 58 action strings into roles, and a member holds exactly one role, so every role is a complete persona. Sharing is a grant of view, use or edit on a resource to a user, a team or the whole org. Nobody sees a resource they neither own nor were given, org owners included.
Restrictions are the third layer: which connectors and which individual tools a target may reach. One limit on them is deliberate: 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. Blocks always beat allows inside each layer. A block can match a tool's name or the operation underneath it, while an allow matches the operation alone. The reason is in the writeup on names versus operations. Every rule is checked 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.
Who holds the credentials in each shape?
With a gateway in front of servers you run, your team holds them. Each server carries its own secret and its own refresh path, and rotation is a job with your name on it.
Connector credentials never sit in Elaichi. Secrets for each account live in a separate credential service that encrypts them at rest and handles refresh. A refresh that fails flags the connection needs_reauth, so the break shows up where someone will see it. A connect URL is a one-time session that carries no token, which is why it is safe to return over MCP. Read-back of an account's configuration returns public values plus the list of dot-paths that were encrypted, carrying none of their values. An org can supply its own OAuth app per connector. That setting is gated on connector:manage, not connection:manage, so deleting a connection and repointing the org's OAuth app stay separate powers.
When is self-hosting still the requirement?
Self-hosting wins whenever your policy puts the tool plane inside your own network. An air-gapped segment, an internal system with no internet-reachable API, or a control that requires inspection of every outbound packet all point at a self-hosted gateway. Elaichi runs as a service, so in those estates it is not the answer and MCPX is a reasonable place to look.
Elaichi does carry controls that regulated buyers ask about. An organization picks its region at creation. Elaichi has three regions, EU, US and APAC. 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. In Elaichi, customer-managed keys in AWS KMS come with the Black plan, which is launching soon. None of that is the same sentence as "inside our VPC", so check which sentence your auditor actually wrote.
What do you give up when the servers disappear?
Three things, stated plainly. First, you no longer own the connector code. Elaichi authors it. You can fork a public connector, edit its JSON config, and pull upstream changes. A review surface separates new tools, safe updates, config diffs, conflicts and upstream removals. But the base is not yours.
Second, prompt injection. 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: role-based permissions per operation, the forbidden classification that no OAuth scope reaches, output redaction, scope limits and an audit row for each call that reaches execution.
Third, cost shape. Gold lists at $15 per user per month, or $120 per user per year, in USD, and pricing shows the price where you are. Black is the other plan. There is 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. If a trial ends without checkout, the workspace pauses rather than losing anything. A self-hosted gateway converts that line into engineering time, which is cheaper at some headcounts and much more expensive at others. The self-hosted versus managed arithmetic works it through.
One more disclosure while you cost it: deleting an organization deletes its connector credentials but leaves three stores: the audit history, analytics events, and the credential service's organization, environment and installed-connector configuration rows. Elaichi reports that residue by name. It never claims a clean wipe.
How does each shape show which account an agent wrote to?
Elaichi answers from its own audit trail, with no correlation work. The trail holds one entry for each connected-tool call that reaches execution (a call refused earlier writes none). The connection on each entry is the account the call reached, taken from the execution itself. Audit events and application logs share one record shape, so a single query answers what happened. The actor_kind field is recorded at the point of action rather than guessed from a user agent, and its values include ai_assistant, which marks only the Elaichi Agent. A call from an MCP client is recorded under the person who signed in, with the OAuth client named. The trail logs the one path argument that names the object, as the target id, and nothing else about the arguments. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon. The read-only Auditor seat is free, so a compliance reviewer does not consume a license.
Two error strings exist per failed call. The one returned to the caller derives from the third party's response body. The one written to the audit trail never does, because audit records are org-visible and fan out to whatever SIEM you configured.
With a gateway in front of servers you run, the answer depends on what the gateway records and on what each server behind it records. Settle that inventory question on a quiet afternoon rather than during an incident.
What happens on the day somebody leaves?
In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. A grant is the OAuth authorization a client holds for that person. Its revocation status is re-read on every single call, so removal is effective on the next call. Role and restriction changes are different. They resolve through a short cache and take effect within about two minutes, on the MCP endpoint, the console and the REST surface alike.
Offboarding runs a preflight that lists every connection the departing member owns, private and shared alike. A private connection that a shared toolbox still relies on blocks the removal until you transfer it to an active member, never to the organization, to a team, or to the admin running the removal. A private connection nothing else depends on cannot be transferred and is deleted with the member. A shared connection a team still depends on is left untouched unless you delete it, so transfer it to someone who is staying, which leaves every grant on it as it was. For the contractor version of this problem, the offboarding walkthrough covers what to do before any of this is in place.
How do you sort your own estate in an afternoon?
Start with the count, then price both shapes against it. The steps below take a couple of hours and settle the question better than any feature grid.
- List every MCP server running in your company today, with an owner name against each.
- List the AI clients your people already use, and check how each one lets an admin add a single URL for members to connect to.
- Read your own policy for the sentence about where third-party processing may happen.
- Price the gateway path as engineer-weeks per quarter, and the hosted path as billable seats.
- Trial whichever shape the first four answers favor, scoped to one team and one connected app.
If the count in step one is zero and step three does not require your own network, you are buying a hosted MCP server. If it is nine, you are buying a gateway, and the acquisition questions belong in that conversation. If both answers feel premature, the case for waiting is a real one. For the wider field, see what an MCP gateway is, shape by shape. When you want to see what a single endpoint would serve, browse the connector catalog or the team use cases.
