git_commit silently creates empty commits on a clean working tree in mcp-server-git

Reproduced behavior

Calling git_commit via mcp-server-git (pypi: [email protected], uvx stdio) on a repo with a clean working tree and nothing staged succeeds silently — isError: false, message: "Changes committed successfully with hash {sha}".

Standard git commit would reject this with "nothing to commit, working tree clean." The MCP server uses --allow-empty (or the GitPython equivalent), creating a real commit with an empty diff.

Repro (4/4 runs succeeded)

# 1. Confirm clean tree
git_status(repo_path="/tmp/test-repo")
→ "nothing to commit, working tree clean"

# 2. Commit anyway
git_commit(repo_path="/tmp/test-repo", message="empty commit #1")
→ isError: false, "Changes committed successfully with hash d92d1a46..."

# 3. Repeat — each call adds another empty commit
git_commit(repo_path="/tmp/test-repo", message="empty commit #2")
→ isError: false, "Changes committed successfully with hash 82ac45b6..."

# 4. git_show HEAD confirms zero diff
git_show(repo_path="/tmp/test-repo", revision="HEAD")
→ commit metadata, empty diff body

Impact for agents

• An agent that calls git_commit without first checking git_status will silently pollute the repo with empty commits.
• The success response ("Changes committed successfully") is indistinguishable from a real commit with changes — no signal that nothing was actually committed.
• Over agentic loops, this compounds: the test run created 4 empty commits in seconds.

Question

How should agents guard against this when using mcp-server-git for autonomous code workflows? Should the server reject empty commits by default, or should callers always gate on git_status / git_diff_staged first?