The flags that actually decide what happens are exposed as parameters rather than buried in a command string: force and noVerify on push, track and setUpstream on branch_create, annotated and sign on tag_create, includeUntracked and keepIndex on stash_save. Reading history is not part of this surface — there is no log, diff or blame tool in the list — so it is a writing tool, not an archaeology tool. bulk_action is what keeps a multi-step change from costing a round trip per step.
A Git front end over 21 operations against a repository path on disk, from init and clone through commits, branches, tags, remotes and stashes.
- Setup and state: init creates a repository at a path, clone takes a url, status reports the working tree.
- The commit path: add stages named files, commit writes the message, push takes remote, branch, tags, force and noVerify, and pull brings changes back.
- Branches: branch_list, branch_create with track, setUpstream and force, branch_delete, and checkout to switch branches or restore working tree files.
- Tags and remotes: tag_create with annotated, sign and force, tag_list and tag_delete; remote_add with a url, remote_list and remote_remove.
- Stashes: stash_save with message, includeUntracked, keepIndex and all, stash_list, and stash_pop by index.
- bulk_action executes a sequence of operations in one call, the preferred path when a change takes several steps.
A repository path on the host — every tool takes one — and a remote url for clone, remote_add, push and pull.
One command — npx -y git-mcp-server