The situation
Somebody on your team opens a connector in Elaichi's catalog. It almost does what they need, and they ask whether they can change it. They can, if they hold connector:create, by forking it. The real question is whether to fork public MCP connector definitions at all. A fork is a second thing to maintain. It is also a second thing that can drift from the connector it came from.
Some glossary first, so the rest reads cleanly. MCP (Model Context Protocol) is the standard that lets an AI client call tools in your apps. A connector in Elaichi is the definition of one app's tools. A fork is a copy of a connector that records its source. It can later pull that source's changes through a review step.
A connector in Elaichi is not the same thing as a server entry in an AI client's own config. Cursor reads MCP servers from project and home config files (Cursor docs, checked October 2026). Claude Desktop keeps its own servers in claude_desktop_config.json (MCP docs, checked October 2026). A remote server is added to Claude as a custom connector instead (Anthropic docs, checked October 2026). Forking changes the definition inside Elaichi, not any of those files.
This post gives three cases where a fork is the right answer. It gives one case where it is not. It also covers what the pull review shows you afterwards.
When should you fork public MCP connector definitions?
Fork a public connector when your organization needs a change that only your organization wants. Fork when that change must survive the upstream connector being updated. A fork copies the source connector's config, method documentation, category, logo and icon into a new connector. The new connector is owned by whoever forked it, and it records the upstream so changes can be pulled later.
Who can do it: forking needs the connector:create permission. Among Elaichi's built-in roles, only Org Owner and Org Admin hold it. It also needs the custom connectors plan feature, which Gold and Black both include. Forking an organization-owned connector needs at least view access on it. A connector that a restriction blocks for you cannot be forked, and neither can a fork of one.
One kind cannot be forked at all. A remote MCP connector points at a server that already speaks MCP over Streamable HTTP, and it answers 409 connector_not_forkable.
Without a chosen slug the new connector is named <source>-fork. If that is taken, Elaichi tries -fork-2 up to -fork-5. The label is " (Fork)". The fork is private to the forker until it is shared.
Case one: the connector is missing a method your team needs
Fork when the app's API has an endpoint the catalog connector does not define, and you need it. A custom connector is created from a JSON config, validated against Elaichi's integration config schema. A fork starts from the source connector's config. So adding one method to a fork is a smaller job than writing the connector from nothing.
This is the clearest case, because the change is additive. You are not disagreeing with the upstream connector about anything. You are extending it. When the upstream connector later adds methods of its own, the pull review offers those as new, and new methods start selected.
The trade-off to name: Elaichi checks a custom connector's config for shape, not for where it points. The connector:create permission is the only one flagged High trust. Its description warns that connector governance binds the connector, not the host it calls. A restriction on one connector does not constrain a new connector aimed at the same API. The fork is governed as its own connector, with its own slug, plus the forks that declare descent from it.
Case two: the tool names or descriptions have to read differently
Fork when the model needs to see different wording. A connector's tool_name documentation entries replace the tool names Elaichi advertises, matched by resource and method. The label a tool carries is something whoever edits the connector controls.
That matters more than it sounds. Elaichi's tool search is lexical, not semantic. It scores the tool name heaviest of the five fields it reads. Your sales team may search for "deal" where the vendor says "opportunity". That is a ranking problem, and renaming it in a fork is one way to fix it.
Two limits on renaming. Two methods of one custom connector cannot answer to the same tool name. A config edit, a documentation update or a pull that would cause a clash is refused. A rename also does not escape governance. An allow rule matches a tool only by the operation stored when the rule was saved, never by name. A block rule matches by name or by operation. The reasoning behind that split is in why blocks match names and allows don't.
If the only thing you want is a different name for one person or one team, a toolbox entry's override already does that, without a fork. Fork when the rename should apply everywhere that connector is used.
Case three: you need a method gone for the whole organization
Fork when a method should not exist for your organization at all, not merely be blocked for some roles. Restrictions are the normal answer here, and for most teams they are the better one. A block rule on a role, or on one member, keeps a tool out of the tools Elaichi advertises and refuses it at call time.
A fork earns its place when you want the method absent from the definition rather than filtered per caller. A fork is a connector of its own. What you leave out of its config is not there to be advertised to anyone.
Be honest about the cost. A fork is one more connector to own, to share, and to keep current. Restrictions need none of that. And a block on a connector also blocks every fork that declares descent from it. The lineage is walked toward its root for up to 8 hops. If the goal is "this role should not reach these three tools", write the rule. Restrict one tool or the whole app works through six of those cases.
When should you file the change upstream instead?
File it upstream when the change is a correction rather than a preference. The catalog connector may have a wrong HTTP method, a broken path, or a missing required field. A description may mislead every model that reads it. That is wrong for everybody, not just for you. Forking leaves the bug in place for every other organization, and gives you a copy you now maintain forever.
Elaichi authors and runs most connectors in its catalog. The people who can fix a catalog connector are the same engineering organization that built it. A fix there reaches every organization at once, and costs you no ownership.
The test is simple. Would another company using this connector want your change? If yes, it belongs upstream. If the change is only right because of how your company works, fork it.
There is a second reason to prefer upstream. A fork that carries a correction will meet that same correction later, when upstream finally makes it. The pull review will present it as a conflict, because both sides changed. Conflicts are the one category you have to decide about by hand.
What does the pull review show, and what is checked by default?
A fork with a recorded upstream can pull upstream changes through a review step. GET /connector/:slug/pull previews them. POST /connector/:slug/pull applies the ones the editor selects, up to 500 change ids. Pulling needs edit access on the fork, and an upstream the editor can still see.
The preview sorts each difference into one of five kinds:
- new: a method that is new upstream.
- updated: upstream changed it and the fork had not.
- conflict: both sides changed it, or there is no baseline to compare against.
- removed: upstream dropped it.
- config: a top-level config key.
The default selection is the argument for reviewing a pull rather than clicking through it. New methods and safe updates start selected. Conflicts and upstream removals start unselected. A config key starts selected only when the fork still matches the previous upstream value, or when the key is new from upstream.
Read that default as a statement about who decides what. An update to a method you never touched is upstream's call, so Elaichi ticks it. A method you both changed is your call, so Elaichi leaves it to you. A method upstream deleted is also your call. Applying that removal takes a tool away from everyone using your fork. Nothing in the preview knows whether your team still depends on it.
Pull works per method and per top-level config key (base_url, headers, query, query_array_format, authorization, credentials, pagination, rate_limit, error_expression). Each one is taken whole from upstream or kept as is. A config key that upstream dropped is never offered for deletion at all.
One more thing to know before you fork. An older fork created before lineage existed can have its upstream declared after the fact with POST /connector/:slug/link-upstream. That needs edit access on the connector plus the connector:manage permission.
Who owns the fork afterwards
The member who forks a connector becomes its owner. Ownership is recorded separately from sharing, so editing the share list does not change who owns it. Grants come in three levels. View lets a member see and fork it. Use lets them create connections from it. Edit lets them change its config and documentation, pull from upstream and manage its shares; granting a new share also needs connector:share.
Deleting and transferring are the owner's, with no connector:manage override. The permission's own description says it can edit or delete other members' custom connectors. The code does not let it. On custom connectors, connector:manage is checked for assigning an owner to an ownerless connector, and for declaring a fork's upstream.
That ownership is also an offboarding problem. Every custom connector a departing member owns must be given a new owner before the removal goes ahead. A transfer is the only offboarding action for a connector. Offboarding AI access covers what else a removal has to settle.
If what you actually want is to bring another company's MCP server under Elaichi's rules, that is a remote MCP connector, not a fork. Vendor MCP servers through Elaichi describes that path. The connector catalog shows what is already there before you build anything.
