Summary
The git domain of mcp-git exposes 30+ local-git operations and 52+ GitHub API operations, but does not include git_clone. This forces callers to either fall back to a shell with network privileges, or simulate clone via git_init + git_remote_add + git_fetch + git_checkout.
Use case
Multi-repo standardization workflow: bring 5 new Hummingbot sub-package repos (hb-event-bus, hb-async-utils, hb-data-type-primitives, hb-connector-utils, hb-logger) up to canonical standards from a reference repo (hb-web-assistant). This requires cloning 6 repos into an isolated workspace.
In a primary-as-router Claude Code architecture, shell access for primary is denied and git clone classifies as T3 (prompt_required). Approving T3 across agent boundaries (token must reach the executing agent) is awkward and adds 3-4 orchestration turns per repo.
A first-class git_clone MCP tool — already a network-privileged operation conceptually equivalent to the existing git_fetch and git_push — would close this gap cleanly.
Proposed signature
git_clone(
repo_url: str,
target_path: str,
branch: str | None = None, # checkout this branch after clone
depth: int | None = None, # shallow clone
single_branch: bool = False,
recurse_submodules: bool = False,
)Workaround
git_init(repo_path=<target>)
git_remote_add(repo_path=<target>, name='origin', url=<url>)
git_fetch(repo_path=<target>, remote='origin', depth=<depth>)
git_checkout(repo_path=<target>, branch=<default>)
Works but is 4 tool calls instead of 1, and requires the caller to know the default branch upfront (or call git_remote_show which also isn't exposed).
Related
- The
~/.claude/CLAUDE.md 'Git Mental Model' table lists git_status / git_log / git_diff / git_add / git_commit / git_push but has no entry for clone — confirming this is a known gap in the lean interface.
- See also: any
git_remote_show / git_ls_remote for default-branch detection prior to clone.
Summary
The git domain of mcp-git exposes 30+ local-git operations and 52+ GitHub API operations, but does not include
git_clone. This forces callers to either fall back to a shell with network privileges, or simulate clone viagit_init+git_remote_add+git_fetch+git_checkout.Use case
Multi-repo standardization workflow: bring 5 new Hummingbot sub-package repos (
hb-event-bus,hb-async-utils,hb-data-type-primitives,hb-connector-utils,hb-logger) up to canonical standards from a reference repo (hb-web-assistant). This requires cloning 6 repos into an isolated workspace.In a primary-as-router Claude Code architecture, shell access for primary is denied and
git cloneclassifies as T3 (prompt_required). Approving T3 across agent boundaries (token must reach the executing agent) is awkward and adds 3-4 orchestration turns per repo.A first-class
git_cloneMCP tool — already a network-privileged operation conceptually equivalent to the existinggit_fetchandgit_push— would close this gap cleanly.Proposed signature
Workaround
Works but is 4 tool calls instead of 1, and requires the caller to know the default branch upfront (or call
git_remote_showwhich also isn't exposed).Related
~/.claude/CLAUDE.md'Git Mental Model' table lists git_status / git_log / git_diff / git_add / git_commit / git_push but has no entry for clone — confirming this is a known gap in the lean interface.git_remote_show/git_ls_remotefor default-branch detection prior to clone.