git_add
Stage files for commit. Add file contents to the staging area (index) to prepare for the next commit.
LABSCO SUMMARY
The repository path stops being something you repeat, and the destructive commands stop being one typo away.
Everything that destroys work sits behind its own flag — clean needs force, reset and push need confirmation — so an agent cannot hard-reset a tree by omission. The two least git-like tools shape how the server actually gets used: git_wrapup_instructions returns an acceptance-criteria checklist the agent has to satisfy before a session counts as shipped, and git_changelog_analyze gathers the commits, tags and review framing to write against, leaving the changelog file itself to be read separately. One thing to check on day one: signing is on by default and falls back to unsigned rather than failing, so read the signed field in the response if signed commits are a requirement.
What it is
A server over git itself: 28 tools covering the working tree, history, remotes, tags and worktrees, plus a session working directory that later calls inherit.
What you get
- The everyday cycle: status, staging, commits with multi-line messages passed as JSON strings, unified diffs, and log filtered by author, date, path or message pattern
- History work with the modes each operation actually needs — merge, rebase, cherry-pick and stash all take abort or continue, reset takes soft, mixed or hard
- Remote operations including shallow, bare and mirror clones, fetch with prune, and push with force-with-lease, dry-run and tags
- A working directory set once for the session, returned with a repository snapshot of status, recent commits, tags and remotes so the caller starts oriented
- Tag verification that separates an unsigned tag, missing trust configuration, a bad signature and a valid one, rather than passing or failing as one result
- Worktrees added, listed, moved and removed, for work that runs in parallel on the same repository
- Blame and reflog for the two questions that come up mid-incident: who last touched this line, and where did that commit go
- Commit signing on by default for commits, merges, rebases, cherry-picks and tags, with signed and signingWarning fields in the response when it falls back to unsigned
Requirements
Git installed locally, and Node.js 20 or Bun 1.2 upwards — the runtime is detected for you. Either call git_set_working_dir once or pass a path on every call. Worth setting before the first commit: GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL, which otherwise fall back to your global git config, and GIT_BASE_DIR, which confines every operation to one directory tree. Over HTTP it listens on port 3015 with MCP_AUTH_MODE deciding between none, jwt and oauth. Apache-2.0.
Setup effort
One command — npx @cyanheads/git-mcp-server@latest
USE CASES
01
Committing a session's work without leaving the agent
Fix the working directory once so the rest of the calls inherit it, read what changed, stage it and commit with a message written as a JSON string.
02
Tidying a branch before it goes for review
Read the history you are about to rewrite, replay it onto the current base, and pull across the one commit from elsewhere that belongs in the series.
03
Cutting a release
Gather the commits and tags since the last release with the review framing to work from, tag the release point, and push the tag with the branch.
04
Getting back a commit you thought you lost
Read the reference log for where the branch tip used to be, check that state out, and park anything in the working tree that is in the way.
05
Working out how a line got there
Blame the file over a bounded line range, then open the commit that last touched it to read the change in full.
06
Running two branches side by side
Add a second worktree for the parallel task instead of stashing and switching, then remove it when the work lands.
28 tools
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
git_blame
Show line-by-line authorship information for a file, displaying who last modified each line and when. For large files, use startLine/endLine to limit output.
git_branch
Manage branches: list all branches, show current branch, create a new branch, delete a branch, or rename a branch.
git_changelog_analyze
Gather git history context (commits, tags) and structured review instructions to support LLM-driven changelog analysis. Changelog file should be read separately; this tool provides the supporting git data and analysis framework. Pass one or more review types to control what kind of analysis to perform.
git_checkout
Switch branches or restore working tree files. Can checkout an existing branch, create a new branch, or restore specific files.
git_cherry_pick
Cherry-pick commits from other branches. Apply specific commits to the current branch without merging entire branches.
git_clean
Remove untracked files from the working directory. Requires force flag for safety. Use dry-run to preview files that would be removed.
git_clear_working_dir
Clear the session working directory setting. This resets the context without restarting the server. Subsequent git operations will require an explicit path parameter unless git_set_working_dir is called again.
git_clone
Clone a repository from a remote URL or local path. Accepts HTTP(S), SSH, git://, file://, and bare filesystem paths, with optional shallow cloning.
git_commit
Create a new commit with staged changes in the repository. Records a snapshot of the staging area with a commit message.
Commit Message Format: Pass commit messages as JSON string parameters. Multi-line messages are supported using standard JSON string escaping.
Examples:
- Single line: { "message": "feat: add user authentication" }
- Multi-line: { "message": "feat: add user authentication\n\nImplemented OAuth2 flow with JWT tokens.\nAdded tests for login and logout." }
Note: Do not use bash heredoc syntax. Literal escape sequences ( , \t) in the message string are automatically normalized to their actual characters.
git_diff
View differences between commits, branches, or working tree. Shows changes in unified diff format.
git_fetch
Fetch updates from a remote repository. Downloads objects and refs without merging them.
git_init
Initialize a new Git repository at the specified path. Creates a .git directory and sets up the initial branch.
git_log
View commit history with optional filtering by author, date range, file path, or commit message pattern.
git_merge
Merge branches together. Integrates changes from another branch into the current branch with optional merge strategies.
git_pull
Pull changes from a remote repository. Fetches and integrates changes into the current branch.
git_push
Push changes to a remote repository. Uploads local commits to the remote branch.
git_rebase
Rebase commits onto another branch. Reapplies commits on top of another base tip for a cleaner history.
git_reflog
View the reference logs (reflog) to track when branch tips and other references were updated. Useful for recovering lost commits.
git_remote
Manage remote repositories: list remotes, add new remotes, remove remotes, rename remotes, or get/set remote URLs.
git_reset
Reset current HEAD to specified state. Can be used to unstage files (soft), discard commits (mixed), or discard all changes (hard).
git_set_working_dir
Set the session working directory for all git operations so subsequent calls can omit the path parameter. Always returns a repository snapshot (status, recent commits, recent tags, remotes) to orient the caller.
git_show
Show details of a git object (commit, tree, blob, or tag). Displays commit information and the diff of changes introduced.
git_stash
Manage stashes: list stashes, save current changes (push), restore changes (pop/apply), or remove stashes (drop/clear).
git_status
Show the working tree status including staged, unstaged, and untracked files.
git_tag
Manage tags: list all tags, create a new tag, delete a tag, or verify a signed tag. Tags are used to mark specific points in history (releases, milestones). Verify runs git tag -v and returns a structured result distinguishing unsigned tags, missing trust configuration, bad signatures, and valid signatures.
git_worktree
Manage multiple working trees: list worktrees, add new worktrees for parallel work, remove worktrees, or move worktrees to new locations.
git_wrapup_instructions
Returns a Git wrap-up protocol: an acceptance-criteria checklist the agent must satisfy before the session is considered shipped. Uses the operator's custom instructions if configured, otherwise emits a generic goals-strict/mechanism-generic default. Enriches the response with a repository snapshot (status, recent commits, recent tags) so the agent has immediate orientation for the commit and release steps.
BEFORE YOU INSTALL
What to know first
Tools you get
28 tools when we connected. git_clean and git_reset --hard require explicit confirmation flags. git://working-directory is a resource and Git Wrap-up is a prompt, not tools.
Requires
npx on PATH
Where it runs
Both documented setups run the server on your machine.
CONTEXT COST
Moderate Standing cost
Rated by the size of the 28 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
Connect your client
Server setup
TERMINAL
npx @cyanheads/git-mcp-server@latestMCP Clients
Any MCP client — npx
ANY MCP CLIENT — NPX · JSON
{
"mcpServers": {
"git-mcp-server": {
"type": "stdio",
"command": "npx",
"args": [
"@cyanheads/git-mcp-server@latest"
],
"env": {
"MCP_TRANSPORT_TYPE": "stdio",
"MCP_LOG_LEVEL": "info",
"GIT_SIGN_COMMITS": "true"
}
}
}
}Any MCP client — bunx
ANY MCP CLIENT — BUNX · JSON
{
"mcpServers": {
"git-mcp-server": {
"type": "stdio",
"command": "bunx",
"args": [
"@cyanheads/git-mcp-server@latest"
],
"env": {
"MCP_TRANSPORT_TYPE": "stdio",
"MCP_LOG_LEVEL": "info"
}
}
}
}
