reforge-mcp

Overview Schema Source Related Servers Discussions Admin

git_commit

Destructive

Record reviewed edits by staging specified files and creating a local Git commit; supports branch checkout and confirmation checkpoints without pushing.

Instructions

Stage the named files and create a Git commit within the session budget. Use when: edits have been reviewed and should be recorded in local Git history. Don't use when: you need to apply or test a patch first (use write_fix instead).

Returns {success, commit_hash, branch, files_committed, error}. A checkpoint additionally returns needs_confirmation=true and message; retry with confirmed=true after approval. files_committed echoes the requested list, not an inventory of the commit: previously staged changes are also committed. Refuses an empty commit when the staged index matches HEAD; refusals do not consume the session budget. Initial commits with staged content are allowed. May create/check out a branch and invoke Git hooks; does not push.

Input Schema

Name	Required	Description
`files`	Yes	Required nonempty list of files to stage, relative to repo_path or absolute within it; e.g. ['src/main.py']. Already staged changes are also included by Git's index commit; inspect the index first.
`branch`	No	Branch name to check out before staging; default null stays on the current branch. Must exist unless create_branch is true.
`message`	No	Commit message; null (default) or an empty string uses 'refactor: automated fix #N', with N the next per-repository session count.
`confirmed`	No	Default false. Set true on retry after needs_confirmation is returned and the user approves. Does not bypass session_budget (default 20 commits); checkpoints default to every 5 commits via reforge.toml.
`repo_path`	Yes	Git repository directory to commit in; prefer an absolute path, e.g. /work/app.
`create_branch`	No	Default false. When true and branch is supplied, create and check out that branch; without branch this flag has no effect.

Output Schema

Name	Required	Description	Default
`error`	Yes
`branch`	Yes
`message`	No
`success`	Yes
`commit_hash`	Yes
`files_committed`	Yes
`needs_confirmation`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.4.5Nov 6, 2026

addedInput schema / properties / branch / description

Added value: +"Branch name to check out before staging; default null stays on the current branch. Must exist unless create_branch is true."

addedInput schema / properties / confirmed / description

Added value: +"Default false. Set true on retry after needs_confirmation is returned and the user approves. Does not bypass session_budget (default 20 commits); checkpoints default to every 5 commits via reforge.toml."

addedInput schema / properties / create_branch / description

Added value: +"Default false. When true and branch is supplied, create and check out that branch; without branch this flag has no effect."

addedInput schema / properties / files / description

Added value: +"Required nonempty list of files to stage, relative to repo_path or absolute within it; e.g. ['src/main.py']. Already staged changes are also included by Git's index commit; inspect the index first."

addedInput schema / properties / message / description

Added value: +"Commit message; null (default) or an empty string uses 'refactor: automated fix #N', with N the next per-repository session count."

addedInput schema / properties / repo_path / description

Added value: +"Git repository directory to commit in; prefer an absolute path, e.g. /work/app."

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / properties

Added value: +{
+  "branch": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "commit_hash": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "error": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "files_committed": {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  "message": {
+    "type": "string"
+  },
+  "needs_confirmation": {
+    "type": "boolean"
+  },
+  "success": {
+    "type": "boolean"
+  }
+}

addedOutput schema / required

Added value: +[
+  "success",
+  "commit_hash",
+  "branch",
+  "files_committed",
+  "error"
+]

Addedv0.2.9Oct 28, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare the mutation/open-world profile; the description goes well beyond them by disclosing the checkpoint confirmation flow (needs_confirmation plus retry with confirmed=true), that refusals do not consume the session budget, that empty commits are refused, that initial commits are allowed, that Git hooks may run, and that nothing is pushed. The one omitted behavior is what 'destructive' concretely means here (e.g. whether rewriting history is possible), which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Strong structure: purpose first, then labeled use/don't-use, then return shape, then caveats. Every sentence carries information, but the return-value enumeration is partly redundant given an output schema exists, and the tail-end caveats are packed densely into long sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world mutation with six parameters and an approval gate, the description covers the confirmation retry loop, budget interaction, index semantics, branch switching and hook invocation. Combined with the output schema, an agent has everything needed to call it correctly and to handle the refusal and checkpoint paths.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains files, branch, message, confirmed, repo_path and create_branch in detail. The description mostly restates those semantics, with the only genuinely additive note being that files_committed echoes the requested list rather than being an inventory of the commit. Baseline 3 is appropriate when the schema carries the parameter burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb-plus-resource pair ('Stage the named files and create a Git commit') and adds a scoping constraint ('within the session budget'). It also explicitly names the sibling it is not for ('use write_fix instead'), so an agent can distinguish it from the patch-application tool without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a labeled 'Use when' condition (edits reviewed and should be recorded in local history) and a labeled 'Don't use when' condition that names the alternative tool write_fix. This is the explicit when/when-not/alternative structure an agent needs for routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server