MCP server registry vs first-party connectors: what is the difference?
MCP server registry vs first-party connectors is a choice about authorship. A registry lists servers that other people write and run. First-party connectors are written, maintained and served by one vendor. Both 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 repairs a tool when it breaks.
The protocol now has an official registry to measure the term against. The official MCP Registry calls itself a "centralized metadata repository for publicly accessible MCP servers". It hosts metadata that points to packages on npm, PyPI or Docker Hub, not the code itself. Its metadata is "deliberately unopinionated", and it leaves security scanning to those package registries and to the marketplaces built on top of it. As of October 2026 it is still in preview.
| 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 it authors |
| Maintenance ownership | Whoever wrote the server, on their release cadence | Elaichi owns the fix for its own connectors; the app vendor builds and runs a native MCP connector's tools |
| Security review | Spread across authors, package registries and marketplaces | Single review surface across the connectors Elaichi authors |
| Updates | Ship when each author ships | Ship behind the same POST /mcp clients already use |
| Coverage | Broad and grows fast, long tail included | Bounded to what one vendor writes or publishes, 600+ connectors |
| Setup 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.
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 a working tool, not the 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 serves 600+ connectors and authors, maintains and runs most of them on its own infrastructure. The rest are native MCP connectors: each app vendor's own server, published by Elaichi staff one by one rather than drawn from a registry, and governed under the same rules. Companies do not run MCP servers. A broken tool in a connector Elaichi wrote 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, encrypted at rest with AES-256-GCM, and owns token refresh. When a refresh fails, the connection is marked needs_reauth rather than failing silently. An admin sees a state instead of a run of confusing tool errors.
What is a federated registry 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 a self-hosted enterprise MCP gateway that sits between agents and the MCP servers, APIs and LLM providers they use (lunar.dev, checked October 2026). Tyk's MCP Gateway proxies and governs remote MCP servers, and Tyk Gateway can also generate an MCP proxy from a Tyk-managed REST API (Tyk's documentation, checked October 2026). If servers already exist in your estate, that is the natural fit and the reason those products exist.
Hosted variants move the running off your machines. Whether they also move the authorship depends on the vendor. Composio Connect is an MCP server at https://connect.composio.dev/mcp that gives an agent access to "1000+ apps" through 7 meta-tools (Composio's documentation, checked October 2026). Ask any vendor in this shape two things in writing: who writes the patch when a tool in its catalog breaks, and how long a patch usually takes to ship.
What does first-party authorship cost 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. Name that constraint 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 broken connector change the address your clients point at?
With Elaichi, no. Every connected account is served through one organization-wide MCP endpoint, POST /mcp, which speaks standard MCP over Streamable HTTP. It sits 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.
An admin adds that address once where each client allows it, and each member then connects and signs in with their own grant. In Claude Team and Enterprise, the owner's step is Organization settings > Connectors. Members then find the connector under Customize > Connectors and click Connect (Claude's help center, as of October 2026). In ChatGPT, full MCP with write actions is a beta on Business, Enterprise and Edu plans. An admin creates and publishes the app there (OpenAI's help center, as of October 2026). Connecting Elaichi to ChatGPT walks through the steps. A connector fix ships behind the same 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 carrying only the tools it is permitted to use" (composio.dev, checked October 2026). More endpoints is not automatically worse. Every address is still something somebody has to maintain, distribute and retire. Count them before you commit.
Does a bigger catalog mean a longer tool list for the model?
Not with Elaichi. Federating many servers grows the list of tools a client hands the model before it picks one. In Elaichi, connected tools are never listed one by one, however few there are. The model searches with search_tools and calls its pick through execute_tool, while control-plane operations stay listed individually.
Ranking inside search_tools is purely lexical over tool name, description and connector label. A relevance floor, a minimum share of the query that a tool must match, keeps a query about one app from returning a plausible tool from another. That matters because a wrong tool is worse than none: the model calls it. How tool search picks one tool from hundreds covers the mechanics.
Can a connector update change what your rules mean?
It can, if rules bind to names. A tool's advertised name can be edited by whoever maintains the connector's documentation, so a rule written against a name is 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. Why a block matches the name and an allow does not sets out the reasoning.
In Elaichi, 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. Plan for the delay when you change a rule. A restriction or role change takes effect within about two minutes, on the MCP endpoint, the console and the REST surface alike. Grant revocation, member removal and suspension take effect on the next call, because a grant's revoked state is re-read on every call. During an incident, revoke the grant rather than editing a restriction.
What does the audit trail show when one vendor owns the code?
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. It keeps one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each entry names the account the call actually reached, taken from the execution rather than from the intent. After an unexpected change, the first thing anyone asks is which of two Notion workspaces the agent wrote to, and the entry says.
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. Audit records are visible across the organization and readable by the in-product assistant, and a vendor's error body written there would leak third-party data through the log. The trail logs the one path argument that names the object, as the target id, and nothing else about the arguments.
What happens to connections when somebody leaves?
Offboarding runs a preflight. It lists every connection the departing member owns, private and shared alike. A private connection pinned by a toolbox (a shared, saved set of tools and the accounts they use) blocks the removal until the admin transfers it to another active member, never 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 depends on is left untouched unless the admin deletes it, so transfer it to someone staying and every grant on it stays as it was. Delegated toolbox entries surface as a non-blocking warning, and re-pinning is the fix.
Ask a federated vendor the same thing in plain terms: what happens to the servers and credentials attached to a member who leaves. What to do about departing contractors and AI access works through the contractor version.
Can you fork a connector and still get upstream fixes?
Yes. 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 tool 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 is a registry the right answer?
A registry-and-gateway product fits when you already run MCP servers you intend to keep. It also fits when your engineers author servers over proprietary databases, or when you need an app today that no first-party catalog covers. For internal servers, the official MCP Registry is not the place: it does not support private servers and recommends running a private registry of your own.
A first-party control plane is the right answer when your bottleneck is tickets about broken tools and clients that need reconfiguring.
Sometimes you need neither shape 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. The cases where a gateway is premature are written up separately.
How do you decide in 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 how long a rule change takes and how long an access cut takes, 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, and the rest of the comparisons cover the other shapes in this category.
