Related Servers

There are two parallel tool families covering the same operations (e.g. repository_manager_clone_projects vs rm_git_clone, repository_manager_commit_project vs rm_git_commit, repository_manager_pull_projects vs rm_git_pull), so an agent cannot tell which to pick. Worse, whole groups share byte-identical descriptions: all ~11 rm_gates_* tools (run, status, explain, profile, audit_fail_fast, xdist_plan, phase_direction...) carry the same text, as do repository_manager_maintain_projects and repository_manager_phased_bumpversion. Several tools (rm_git_raw, rm_git_action, process-style wrappers) have indistinguishable boundaries.

Two competing conventions coexist: a verbose 'repository_manager_verb_noun' style and a short 'rm_<module>_<action>' style, applied inconsistently to the same underlying capabilities. The rm_* family splits into ~20 sub-namespaces (rm_gates, rm_git, rm_worktree, rm_merge_queue, rm_build, rm_concepts, rm_remote_workers), each mostly verb_noun internally, but the duplication of verbs across namespaces undermines predictability.

122 tools is an extreme mismatch for a repository management server; the guidance target is roughly 3-15. A large fraction are redundant wrappers of the same git/workspace actions exposed under two naming families, plus many near-duplicate gate/concept/remote-worker variants, inflating the surface far beyond what the domain needs.

The domain is broadly covered — clone/pull/push/commit/branch, version bumping, gates, builds, worktrees, merge queue, workspace config, and even concept reservation and remote workers. However several tools are documented as non-functional stubs (rm_remote_workers_host_loss_reconcile 'always refuses today', concept mutations refuse when authority is absent), and the redundancy makes it hard to identify the canonical path for any lifecycle step.