No user-submitted related servers found.
Scored across 22 tools
The read-side cluster (fleet_summary vs overview vs list_repos vs launchpad) could easily blur, but the descriptions explicitly carve them apart by output shape and question asked (counts vs ranked actions vs raw fields vs per-repo flows/tasks). The git verbs (fetch/pull/push/commit/stash/run) and the search/changes split are cleanly bounded, though `changes` vs `get_repo`'s detail drill-in and `search` vs `run` (which explicitly can grep) leave small residual overlap.
Conventions are mixed: verb_noun (list_repos, get_repo, list_prs, record_activity), read_/write_ pairs, bare git verbs (fetch, pull, push, commit, stash), and lone nouns/adjectives (overview, standup, launchpad, search, changes, repo_path, ci_status). The groupings are internally coherent and readable, but there is no single predictable pattern an agent can extrapolate from.
At 22 tools the surface sits in the heavy band, largely because five overlapping read views (fleet_summary, overview, list_repos, get_repo, standup/changes) cover much of the same underlying data. Each tool is defensible on its own, but consolidation into fewer parameterized views would likely serve users better.
Read/audit coverage is genuinely comprehensive (status, diffs, search, CI, PRs, tasks, activity), but the write lifecycle has notable holes: stash has no restore/pop counterpart, and there is no branch creation/switch, merge, tag, or PR creation/merge. Agents can complete the fetch→commit→push path but will dead-end when work must be retrieved from a stash or a branch/PR must be managed.