MCP SERVER
Git primitives with commit categorization, safety checks, and merge request lifecycle.
| Tool | Purpose | Returns |
|---|---|---|
| commit | Create a git commit with [CATEGORY] prefix. Runs safety checks against staged changes. Supports dry run preview and force override for warnings. | SHA, check results, fixup candidates |
| amend | Amend HEAD commit. Blocked if already pushed to remote. Re-runs safety checks on the new staged content. | Updated SHA, check results |
| fixup | Create a fixup commit targeting an earlier MR commit, then autosquash rebase. Pre-flight validates staged changes, clean tree, target SHA in range, and no debug statements. | Target SHA, fixup SHA, final HEAD |
| audit | Audit all commits in the MR branch for commit breakdown compliance. Checks category prefixes, debug statements, and SHIFT_LEFT thresholds per commit. | Pass/fail status, per-commit violations |
| push | Raw git push with no auto-commit or remote creation. Supports --force-with-lease for post-amend/rebase pushes. | Web URL for the branch |
| rebase | Rebase current branch onto a target. Fetches the remote by default before rebasing. | Rebase status |
| mr_create | Create a GitLab merge request. Pushes the branch first, then creates the MR via glab CLI. Supports draft mode. | MR URL, IID, web URL |
| mr_update | Update an existing merge request — title, description, or target branch. Pushes latest changes first. | Updated MR metadata |
| mr_view | View the merge request for the current branch. Returns full MR details without modification. | MR state, title, description, URL |
| mr_comments | Get MR comment threads with reply chains, file positions, and surrounding diff hunks. Filters by author, resolved status, recency, and file path. | Thread array with notes and diff context |
| mr_reply | Reply to an MR discussion thread. Optionally resolves the thread with the reply in a single call. | Note ID, resolved status |
| mr_resolve | Bulk resolve or unresolve MR discussion threads. Processes each thread independently — partial success is possible. | Per-thread success/error results |
| glab_auth | Check or refresh GitLab CLI authentication. Status check, PAT login, or browser-based OAuth. | Auth status, username, hostname |
Every commit gets a [CATEGORY] prefix that controls which checks run and how the commit is audited. The categories enforce a separation: structure changes go in REFACTOR, behavior changes go in CORE. If you're doing both, that's two commits. CASSETTES are always last — large recorded files that skip diff analysis entirely.
[DISCOVERY] — exploration, research, spikes. No behavioral expectations.
[REFACTOR] — restructuring without behavior change. Move code, rename, extract.
[CORE] — the actual feature or fix. Triggers SHIFT_LEFT analysis.
[CASSETTES] — VCR test recordings. Always committed last. Diff analysis auto-skipped.
Debug statements — blocks commit. Catches console.log, debugger, fmt.Print, breakpoint(), dbg!(), binding.pry across six languages.
Generated files — blocks commit. Catches direct modification of _mock.go, .pb.go, lock files.
SHIFT_LEFT — warns on CORE commits touching >3 source files or >50 added lines. Suggests splitting into REFACTOR + CORE.
Fixup candidates — suggests existing MR commits that touched the same files.
Every commit supports dry_run=true — see exactly which checks will fire before committing. Errors, warnings, suggestions, and fixup candidates are all surfaced without touching the repository. The standard workflow is preview first, then commit.
Warnings can be overridden with force=true and a required force_reason explaining why. Errors (debug statements, generated files) can never be forced — they must be fixed. The force reason is recorded in the commit metadata for audit trail.
When a change belongs to an earlier MR commit, fixup creates a fixup commit targeting that SHA and immediately autosquash-rebases. Pre-flight checks validate staged changes, clean working tree, target SHA in MR range, and no debug statements — all before touching history.
git-ops has no workspace awareness. Every tool takes a raw cwd path that must come from scout_resolve or scout_activate. Scout resolves the hint to a path, git-ops executes the operation. This separation means git-ops never constructs paths, never discovers repos, never decides where — only what.
The standard feature workflow flows through git-ops in order: commit (with dry_run preview) → audit (validate all branch commits) → push (get code to remote) → mr_create (request review). After review, mr_comments surfaces feedback, mr_reply responds, and fixup amends earlier commits without rewriting the whole branch.
The server that won't let you commit a console.log.