git-training-wheels
# MCP Git Training Wheels
LLMs try to please, but as the context window gets larger and larger, errors
start to happen. In particular, current models have a tendency to just
`git add -a` the whole source tree, accidentally adding lots of random stuff
to their commits.
These issues become especially noticable when multiple agents are working on
a codebase in parallel, or if you're doing quick fixes while an agent is working.
And no current model has the ability to un-fuck a git history.
This MCP server gives the agent some training wheels for using git safely,. It
ensures that only a specific named set of files can be committed, and also
provides a convenient way to fixup earlier commits. For best results, use
permissions to automatically deny the use of `Bash(git commit:*)` or equivalent.
It's still using the regular `git commit` command under the hood, so global
and global git settings like username, email, and commit signing all apply
as usual.
## Installation
### Using uv
```bash
uvx mcp-git-training-wheels
```
### From source
```bash
git clone https://github.com/lava/mcp-git-training-wheels
cd mcp-git-training-wheels
uv pip install -e .
```
## Usage
### Add the following
Depending on your agent of choice, run something like the following
```sh
claude mcp add git-commit -- uvx mcp-git-training-wheels
```
or drop the following JSON into `.mcp.json` or any other location of your
choice.
```json
{
"mcpServers": {
"gtw": {
"type": "stdio",
"command": "uvx",
"args": [
"mcp-git-training-wheels"
],
"env": {}
}
}
}
```
The specific command may change depending on your installation method.
### Available Tools
#### git_commit
Commits specified files with a message and saves the commit information for
later use.
**Parameters:**
- `files`: List of file paths to commit
- `message`: Commit message
**Example:**
```json
{
"tool": "git_commit",
"parameters": {
"files": ["src/main.py", "tests/test_main.py"],
"message": "Add main functionality and tests"
}
}
```
#### fixup_commit
Adds files to a previously created commit. If the commit is still HEAD, it
uses `git commit --amend`. Otherwise, it uses the `gitrevise` module to edit
the commit in history.
**Parameters:**
- `files`: List of file paths to add to the commit
**Example:**
```json
{
"tool": "fixup_commit",
"parameters": {
"files": ["src/utils.py"]
}
}
```
TDQS
Scored across 2 tools
git_commit creates a new commit, while git_commit_amend modifies an existing commit (via amend or fixup). The purposes are clearly distinct and the descriptions explicitly define the boundary. No ambiguity exists between the two tools.
Both tools follow the same `git_` prefix plus a verb (`commit`, `commit_amend`), creating a clear and predictable pattern. The naming is consistent and immediately conveys the action.
With only two tools, the surface feels thin, even for a focused 'training wheels' server. While the tools are well-chosen for basic commit workflows, a couple more (e.g., log, status) would round out the set. It is borderline but not critically under-scoped.
The domain appears to be basic git commit operations, and the two tools cover creating and amending/fixing up commits. However, there are notable gaps such as inspecting commit history, checking repository status, or reverting changes, which an agent would likely need for a complete workflow.