MCP server registry vs first-party connectors: where the fork sits
| Axis | MCP server registry | First-party connectors (Elaichi) |
|---|---|---|
| Quality control | Varies by each server's author and the catalog's admission policy | One vendor's bar applied to every connector in the catalog |
| Maintenance ownership | Whoever wrote the server, on their release cadence | Elaichi owns the fix, one queue for every connector |
| Security review | Multiple parties, reviewed to varying depth | Single review surface across the whole catalog |
| Updates | Ship when each author ships, if the author still cares | Ship behind the same POST /mcp clients already point at |
| Coverage | Broad and grows fast; long tail included | Bounded to what one vendor writes; 450+ today |
| Integration effort | Enable per server, sometimes host it, per-server credentials | Connect a SaaS account once, one endpoint for every client |
A tool that worked in March returns an error in April. The agent retries, summarizes something vague, and an analyst opens a ticket with IT. How long that ticket stays open is decided by authorship. MCP server registry vs first-party connectors is the choice between federating servers other people wrote and buying connectors one vendor wrote, maintains and serves. Both shapes speak MCP: MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Both can put a policy check in front of a call. They differ on who owns the repair.
Breadth is what you evaluate on the day you buy. Repair is what you live with every week after. A registry gives you a long list quickly. First-party authorship gives you one party to hold to a fix. Pick the variable you will be measured on, which for most IT and operations owners is time to working tool, not count of available tools.
Who fixes the tool when the SaaS vendor changes its API?
In a federated shape, the fix belongs to whoever authored the server. That is sometimes the SaaS vendor, sometimes a community maintainer, sometimes the gateway vendor when it hosts the server too. Your gateway can block the broken tool, pin an older version if one exists, or wait. None of those is a repair. The repair happens in a repository you do not control, on a schedule you do not set. If forty teams run forty applications, the worst case is forty separate maintainers with forty separate release cadences.
In a first-party shape, the connector is the vendor's own code. Elaichi authors, maintains and serves 450+ from its own infrastructure. Companies do not run MCP servers, and Elaichi does not wrap a registry of servers other people operate. A broken tool is one vendor's defect with one queue behind it.
Breakage also arrives quietly through credentials. Connector credentials never live in Elaichi. A separate credential service holds per-account secrets, AES-256-GCM encrypted at rest, and owns token refresh. When a refresh fails, the connection is marked needs_reauth rather than failing silently. The failure surfaces as a state an admin can see instead of a run of confusing tool errors.
What a federated registry is built for
A registry-and-gateway product is built for an organization that already runs MCP servers, or that wants a wide catalog immediately. 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 (https://www.lunar.dev/, checked September 2026). Tyk describes an MCP Gateway that proxies and governs remote MCP servers and can generate an MCP proxy from a managed REST API (https://tyk.io/docs/ai-management/mcp-gateway/overview, checked September 2026). If servers already exist in your estate, that is the natural fit and the reason those products exist.
Hosted variants move the running, not the authorship. MintMCP describes a hosted MCP gateway that "hosts our MCPs and manages credentials", with hosted connectors and a large server catalog (mintmcp.com, checked September 2026). Composio Connect is described as an MCP server at https://connect.composio.dev/mcp that gives an agent access to 1000+ apps through a small set of meta-tools, with OAuth links approved in the browser (https://docs.composio.dev/docs/composio-connect, checked September 2026). Put the question to any vendor in this shape procedurally. When a tool in the catalog breaks, who writes the patch, and what is the median time to ship it. Ask for the answer in writing.
What first-party authorship costs you
It costs you optionality. One vendor's catalog is one vendor's roadmap. If the app your legal team runs is not in it, you wait or you author it yourself. That is a real constraint, worth naming before it surprises you in month three.
Elaichi's answer to the gap is custom connectors authored from JSON config, which can also be forked from a public connector. The permission that allows this, connector:create, is flagged high trust, because a custom connector can be pointed at any destination. Keep it in a small number of roles. The second cost is that you cannot run the connector code inside your own network. If that is a hard requirement, read what self-hosting MCP servers actually costs instead.
Does a breakage change the address your clients point at?
With Elaichi, no. Every connected account is served through one organization-wide MCP endpoint, POST /mcp, standard MCP over Streamable HTTP, behind OAuth (the sign-in protocol that issues a client a grant instead of a shared secret). There are no per-toolbox URLs and no embedded tokens. Claude, ChatGPT, Cursor and any other MCP client are pointed at the same address through their own admin console. A connector fix ships behind that address and nobody reconfigures a client.
Address models differ across the category, and the vendor's own words are the thing to read. Composio's MCP Gateway page says each team gets its own MCP endpoint, SSO authenticated (https://composio.dev/mcp-gateway, checked September 2026). More endpoints is not automatically worse. Every address is still something somebody has to maintain, distribute and retire. Count them before you commit.
How does a fat tool list reach the model?
Federating many servers grows the list of tools the model has to read before it picks one. Elaichi collapses the connected half of that list behind two meta-tools, search_tools and execute_tool, past a threshold of 30 tools counted across catalog operations and connected tools together. One connected app is normally enough to trip it, so collapse is the normal case. Control-plane operations stay listed individually.
Ranking inside search_tools is purely lexical over tool name, description and connector label. A tool must also account for at least half the query's own IDF-weighted mass to be returned at all. That relevance floor stops a query about one app returning a plausible-looking tool from a different app, which is worse than returning nothing, because the model calls it. The mechanics are in why tool search needs a relevance floor.
How maintenance leaks into your governance rules
A connector change can quietly rewrite what your rules mean. A tool's advertised name is editable by whoever maintains the connector's documentation, so a rule written against a name is a rule written against a label the governed party controls. Elaichi pins the canonical operation against the catalog when you write the rule. A block matches on the tool name or the pinned operation. An allow matches on the pinned operation only. The reasoning is set out in why a block matches the name and an allow does not.
Restrictions target a role or a user, and a user rule replaces role rules rather than layering on them. When you change one, plan for propagation. A restriction or role change takes effect within about two minutes, on the MCP endpoint, the console and the REST surface alike. Only grant revocation, member removal and suspension are effective on the next call, because a grant's revoked state is re-read from the org store on every single call. During an incident, revoke the grant rather than editing a restriction.
What the audit trail looks like when one vendor owns the code
One authorship means one record shape. Elaichi writes audit events and application logs in the same shape, so a single query answers what happened instead of correlating two systems by eye. There is 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. That answers the first question after an unexpected change: which of my two Notion workspaces did the agent write to.
The log pipe has a firewall in it. Two error strings exist per failed call. The one returned to the caller is derived from the third party's response body and is never written anywhere else. The one written to the audit trail is never derived from the request or the response, because audit records are org-visible and fanned out to whatever SIEM you configure. Argument names and counts are logged. Argument values never are.
What happens to connections when somebody leaves?
Offboarding runs a preflight. A personal connection referenced by a toolbox entry must be resolved before the member is removed. Transfer it to the org, a team or another member, or delete it, 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 somebody else's when its owner leaves. Delegated toolbox entries surface as a non-blocking warning, and re-pinning is the fix.
Ask a federated vendor the same question plainly. When a member leaves, what happens to the servers and credentials that were attached to them. The contractor version of this problem is worked through in what to do about departing contractors and AI access.
Forking a connector and pulling upstream fixes
Forking is the middle path when the shipped connector is close but not right. A forked connector 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 accepting an upstream batch does not silently delete a tool a synthetic workflow depends on.
Two guardrails keep the maintenance story predictable. A connector cannot be deleted while connections still use it. A forked connector's identity includes its declared lineage, walked to the root, block-only, and failing closed if the chain is truncated or cyclic. A fork cannot be used to shed a block that applied to its parent.
When a registry is the right answer for you
Sometimes neither shape is worth buying yet. If two people use one assistant against one app, and that app ships an MCP server your client can point at directly, point it there and revisit in a quarter. That case is written up in the cases where a gateway is premature.
A registry-and-gateway product is the right answer when you already run MCP servers you intend to keep, when your engineers author servers over proprietary databases, or when you need an app today that no first-party catalog covers. A first-party control plane is the right answer when your bottleneck is tickets about broken tools and clients that need reconfiguring.
A decision procedure for an afternoon
Run this before you sit through another demo. It takes about two hours and produces an answer you can defend.
- List the six apps your agents must reach next quarter. Not twenty, six.
- For each, find out who authors the MCP server or connector, and where the code lives.
- Ask each vendor, in writing, who patches a broken tool and what the median turnaround is.
- Count the addresses each shape leaves you maintaining, per team and per client.
- Check the propagation story for a rule change and for an access cut separately. They are different numbers.
For a per-team rollout order, see the twelve team playbooks. The connector catalog lists what is authored and served today, and the rest of the comparisons cover the other shapes in this category.
