What can you do with this server?

This server provides a safe, agent-friendly interface for performing Git rebase and other conflict-generating operations. It catches silent Git errors, prevents unsafe actions, and offers structured conflict resolution. * Pre‑flight check: Inspect a rebase before starting to identify dropped commits, untracked file collisions, and already‑upstream changes. * Safe rebase lifecycle: Start (rebase_start), continue (rebase_continue), skip (rebase_skip), and abort (rebase_abort) rebases with automatic handling of untracked files, optional autosquash, custom commit‑check commands, and backup tags. * Conflict inspection: View conflicts as two diffs (branch vs. replayed commit) with enclosing function context and summaries — not raw conflict markers. * Structured resolution: Choose a side (branch or replaying), keep both, or supply final content. Refuses to stage files containing conflict markers. * Safe amend: Amend a commit only when HEAD is truly the commit being applied, preventing accidental folding of commits at conflicted stops. * Todo list management: Read or replace the rebase plan, with protection against silently dropping commits. * Post‑rebase verification: Verify the branch still makes the same net change, scan for leftover conflict markers, and restore stashed files. * General conflict support: Works for any conflicted Git operation (cherry‑pick, revert, merge, stash pop). * Key safety features: Prevents amending at unsafe states, refuses conflict markers in resolutions, guards against dropped commits, and validates final branch integrity.

Which integrations are available for this server?

Provides tools for safely managing git rebases, including preflight checks, conflict resolution, amending, and verifying that the branch's overall change is preserved.

How do I use git-rebase-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@git-rebase-mcp Show me the conflicts in this rebase" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

git-rebase-mcp

by aaron-riact

Overview Schema Related Servers Score Discussions

Python

Local

git-rebase-mcp

By agents, for agents.

Written by one that mangled its own branch three times in an afternoon and took it personally.

An MCP server that lets an agent drive a git rebase — or a cherry-pick, a revert, a merge, or whatever else left three stages in the index — without quietly wrecking the history on the way through.

Git is very good at rebasing and very bad at mentioning when it went wrong. Each of these exited zero and reported success:

Amending at a conflicted edit stop. edit normally stops with HEAD on the commit just applied, but when it stops because of a conflict HEAD is still the previous commit. git commit --amend there silently folds two commits into one. Nothing in git's output distinguishes the two situations.
A hand-written todo list that dropped three commits. They vanished without a warning.
Staging a file that still contained conflict markers. Two commits shipped <<<<<<< into the tree.

No error, no warning, no non-zero exit. An agent has no reason to look, and by the time anybody does, the branch is three commits further on.

Try it

uv tool install --from git+https://github.com/aaron-riact/git-rebase-mcp git-rebase-mcp

Point your agent at git-rebase-mcp (see Install it for the config snippets) and ask it to rebase something. Nothing is touched until you say so — rebase_preflight is read-only and will tell you what the rebase would do, including which commits a todo silently drops.

If it does start, the tip is tagged first. git reset --hard to that tag undoes the whole thing.

Related MCP server: git-surgeon-mcp

What it does about it

Refuses the unsafe operation rather than documenting it. rebase_amend is not callable at a conflicted stop, and the refusal says why and what to do instead:

Refusing to amend: the rebase is conflicted, and HEAD (2c806c04b 'base') is not a commit this step created. Stopped part-way through applying 87f3d0fd4 (third). That commit does not exist yet, so HEAD is still the one before it and amending would rewrite the wrong commit. Resolve the conflicted paths, then continue.

Says when a stop is the last one. An edit step stops for you once its commit applies — unless it conflicts, in which case the conflict is that stop. --continue commits the resolution and moves to the next step, and the commit you meant to change goes past unchanged. Git says nothing, and the advice above is true and beside the point: a caller can follow it exactly, resolve, continue, and lose the edit. So action_stop_lost says so and the guidance says what to do instead — stage the change now, with the resolution, because --continue commits everything staged. A conflicted reword is worse and gets the same warning: it finishes the whole rebase still carrying the original message, and reports success.

Shows a conflict as two intents, not as marker soup. Per contested region it reports what each side did to the common base:

──── branch so far ────          ──── replaying: "Use delta_count" ────
 def counts(packages):            def counts(packages):
-    if packages:                     if packages:
-        rows = []                        rows = []
-        for package in packages:         for package in packages:
+    rows = []                   -            rows.append(delta(package))
+    for package in packages:    +            rows.append(delta_count(package))
     return rows                      return rows

"The branch has not replayed the wrap yet" against "the fix swaps the call, and leaves the wrap alone". Composing those needs no reasoning about which of three interleaved blocks belongs to whom.

Each side also gets a sentence — "adds 1 line and reindents or moves 3 lines" against "adds 1 line and removes 1 line" — because a block wrapped in an if produces a diff the size of the block and a change of one line, and the diff alone does not say which you are looking at.

Each region is headed by the definition it sits in — @@ -662,13 +662,12 @@ def counts_render(self, ctx): — worked out by git's own funcname driver for the language, of which it ships twenty-five. Git applies one only where a repository asked for it in .gitattributes, and most have not; its fallback then recognises a definition at column 0 only, which in any language whose definitions nest names the class every time and the method never. So this server picks the driver, and picks nothing else: the patterns stay git's, and a language it has never heard of is named as well as one it has.

Both sides get to state their intent. The replayed commit has its message; the branch so far is an accumulation with no message, so each region names the commits behind its lines — which is the nearest equivalent, and is left empty rather than guessed when the lines predate the rebase.

Offers the resolution rather than making it. resolve takes take="both" | "branch" | "replaying" for the cases the two diffs make obvious, so answering costs one call instead of sending a whole file back. auto_resolve will compose conflicts where the two sides touched different lines and carry on without stopping, but it is off by default: lines that do not overlap can still contradict each other — one side adding a call, the other removing the helper it needs — and a conflict resolved without being read has to be reviewed afterwards anyway.

Says when the question is whether a path lives at all. A modify/delete does not look like a conflict: git leaves the surviving side's text in the working file with no markers in it, so nothing about the file says one side deleted it. It is reported as that, with the side named, and take then means a side rather than a text — the side that deleted the path stages the deletion. It used to compose the file's blocks, of which there are none, and stage the empty string that fell out: an empty file in the commit, the path no longer conflicted, and nothing downstream with a reason to complain. The guidance also points out that such a deletion is often half of a rename, in which case what the incoming side did to the old path has to be reapplied to the new one.

Splits a commit without being reached past. rebase_split takes the commit a step just applied back out, leaving its changes in the working tree to commit as several. Doing that by hand — git reset HEAD^ at an edit stop — is the one move that leaves a rebase where --amend rewrites the commit before the one you mean, and git's own record still says amending is safe through it. Now the state says unapplied, amending is refused, and proceed refuses while any of the commit is still outside a commit. That last one matters most for a file the commit added: the reset leaves it untracked, and git rebase --continue neither refuses nor picks it up. It reports success, and the change is simply not in the branch.

Knows the upstream from the landing place. git rebase --onto exists because a branch cut from a history that has since been rewritten needs both: the old upstream is the only thing that still says which commits are the branch's own, and the rewritten history does not, because the same work is there under other shas. Given only the landing place, a branch of seven commits reads as seventy — and the checks then fire correctly and unhelpfully, refusing over the sixty-three a todo "would drop". onto= says what was meant instead, and the finish check measures upstream..old tip against onto..new tip rather than guessing a merge-base that reaches back past the upstream.

Records where the branch was, and checks the result against it. What must stay the same is the change the branch makes to its base -- not the resulting tree, which changes for good reason when the rebase also moves onto newer upstream work. A difference is usually a report of damage, and this is what caught all three errors above. Usually, because a deliberate redistribution looks the same from there — a commit dropped because the new base already has it, or one commit's work moved into others — so the report says which: tree_identical means the content is exactly what it started as, and nothing was lost but the branch's own share of it.

The quiet ones

A refusal handles the failures git could have caught. The harder class is the one where git behaved perfectly and the result is still wrong — nothing to refuse, nothing to report, no exit code to read. Those get counted and named instead:

What went quiet	What is said
A resolution rewrote more than the contested region and re-added lines merged below it	Lines the staged text has more copies of than either side had
A resolution was written from memory instead of from the file, and dropped code neither side touched	Lines both sides kept that the staged text has none of
A conflicted file's other hunks were merged silently, and the commit has since moved	How many hunks landed outside the contested regions
A todo replays a commit ahead of one it used to follow	Which commits moved, and past what

None of these refuse anything: composing two sides legitimately duplicates a shared line, rewriting a region legitimately drops one, and reordering is what a todo is for. They exist because a clean merge is silent by construction, and the one thing an agent will not do is go and look without a reason.

Each was found by making the mistake. The last two came from resolving one region of a reordered commit and shipping the second hunk it had merged in the meantime — a call to a function that did not exist yet on that branch. The file parsed, the suite passed, the build was green.

It is not only for rebases

A rebase is not the only thing that leaves three stages in the index. A cherry-pick, a revert, a merge, a rebase you started by hand, a stash that popped into a conflict — git records all of them the same way, which is what the conflict view reads. So the tools work on any of them:

status:   state=conflicted operation=cherry-pick
          A cherry-pick of 47ba527eb (side change) left 1 path conflicted.
          Nothing has been committed yet. Call conflicts to read them…
proceed:  runs `git cherry-pick --continue`, because `git rebase --continue`
          does not finish a cherry-pick

state stays conflicted whatever produced it, so one check answers the question; operation says what to expect. This was a false negative until recently: anything that was not a rebase read as "no rebase in progress", which conflicts reported as "Nothing is conflicted." — of a repository with unmerged paths sitting in the index.

A conflict nothing recorded — the popped stash — is reported as operation="unknown", with its regions read exactly as any other. What it does not get is a proceed or an abort, because there is no operation to finish and no way to know what undoing it would discard.

The rebase-specific safety stays rebase-specific: the backup tag, the branch-change check and the amend refusal are all about rewriting history, which a cherry-pick is not doing.

Tools

Tool		Works on
`rebase_preflight`	What a rebase would do. Changes nothing. Names commits a todo would drop, and — since reordering is when a commit stops sitting on what it was written against — which commits a todo moves ahead of ones they used to follow.	rebase
`rebase_start`	Tags the tip, moves aside colliding untracked files, begins. `lost_locals` names any local file the checkout onto the new base deleted. `base` is the upstream and `onto=` is where the commits land, for a branch cut from history that has since been rewritten. `edit=[sha, ...]` builds the todo for you — those commits stop, the rest are picked — or `edit_every=` for all of them and `break_first=` for a stop before the first commit, where a baseline is measured. `autosquash` folds `fixup!` commits in; `update_refs` carries every other branch pointing into the range along, which a stack of branches on one another needs.	rebase
`status`	Typed state, what operation is in progress, and whether `HEAD` is the commit being replayed. Reports a rebase that has ended and not been checked, rather than only that none is running. Every report also names the checkout it is about — `worktree` and `branch` — so an answer from here can be told apart from one a shell gave about a different worktree of the same repository, and `replayed_resolutions` names any conflict git answered from its recorded memory rather than fresh.	any
`conflicts`	Each contested region as two diffs, headed by the definition it sits in, plus the incoming commit's message. Also `merged_elsewhere`: how many hunks the incoming commit landed in this file outside the contested regions, so you know whether the region in front of you is the whole of its intent. `context=` for more surrounding lines, `include_file_diffs=` for those other hunks.	any
`resolve`	Stages a resolution: `take="both"`/`"branch"`/`"replaying"`, edited in place, or written inline. Refuses markers, unless `allow_markers=` says the file is meant to have them. Counts lines the result has more copies of than either side had, and lines both sides kept that it has none of — see The quiet ones. Where one side deleted the path, `take` names a side rather than a text, so taking that side stages the deletion.	any
`rebase_amend`	Amends — only where `HEAD` really is this step's commit. Not needed to fold a change in: staging it and calling `proceed` does that.	rebase
`rebase_split`	Takes this step's commit back out, changes left in the tree, to commit as several.	rebase
`proceed`	Carries on, by the operation's own `--continue`. Refuses while anything is unmerged, or while part of this step's commit is left outside a commit. `message=` names the commit a conflicted resolution is about to become — the only place it can be named, since the commit does not exist yet and a conflicted `edit` gets no later stop.	any
`skip`	Drops the commit being applied — for one already in the base.	rebase, cherry-pick, revert
`rebase_todo`	The steps left, and replaces them. Refuses to drop a commit.	rebase
`rebase_finish`	Checks the branch still makes the same change to its base, and names any commit that brought a conflict marker to a file. `tree_identical` says whether a difference is a redistribution or a loss, and a difference is read against what the run actually did — amending explains one, and so does resolving a conflict or staging something at an `edit` stop, so a rebase that did any of those is told which rather than told its own work looks like damage. When the change moved, `branch_change` names the paths whose contribution moved and by how many lines — the difference itself, not a diff between the two tips, which on a rebase onto newer upstream work is mostly the new base's own commits — and `changed_commits` names the commits that account for it — dropped, added, or altered — with `include_diff=` adding git's commit-by-commit rendering. `allow_change=`/`allow_markers=` waive either, and still report it. `fragile_locals` names any file the rewrite made local that the backup tag still tracks, because checking that tag out and coming back deletes it; `lost_locals` names the ones whose working copy the rewrite has already taken, which is what rebasing onto a history that untracked them does. A rebase started with `update_refs` also reports, per branch it was asked to carry, whether that branch actually moved — git exits zero either way, and a sibling left behind points into history the rebase replaced.	rebase started here
`rebase_compare`	Pairs the commits replayed so far against the originals, mid-rebase. `changed` empty means every one carries the patch it came from; `pending` is the tail not reached yet, which pairs as dropped and is not lost.	rebase started here
`abort`	Abandons the operation and puts back what was moved aside.	rebase, cherry-pick, revert, merge

The prefix carries the distinction: rebase_ is for the tools that only make sense inside a rebase — a todo, an amend, a check against where the branch was — and the bare names are for the ones that read or drive a conflict whatever produced it. If a name has no prefix, it does not care how you got here.

rebase_start takes a check_command, run after every commit. It is the only thing that catches a step which applies cleanly and still leaves the tree broken -- a resolution that drops a line, say, so the file no longer parses. Use it.

check_halts=False stops it being a gate at all: the command runs at each stop and the result comes back in the report, and nothing halts. That is the shape for a rebase somebody is watching, where the question at each stop is "what does the suite say here?" held against a baseline — and where a gate would halt on the branch's own history instead. Asked to replay seven commits and test each, I did not reach for the gate at all: four of the seven were legitimately red, so the suite got run by hand at every stop.

Add check_edits_only=True if you want a gate but the branch was not green at every commit to begin with, which most are not: a budget or a fixture raised one commit after the code that needed it is red in between, and a check after every commit then halts the rebase on history that was already like that. Narrowing it to the commits you stop at keeps the part that was wanted — prove the commits I changed are sound — and drops the part that only rediscovers what the branch was.

Install it

One stdio server, one command, no arguments and no environment. Put it on your PATH:

uv tool install --from git+https://github.com/aaron-riact/git-rebase-mcp git-rebase-mcp

Then point your agent at git-rebase-mcp. Most harnesses take the same shape and differ only in where the file lives and what the top-level key is called:

{
  "mcpServers": {
    "git-rebase": { "command": "git-rebase-mcp" }
  }
}

Harness	Where	Key
Claude Code	`claude mcp add git-rebase --scope project -- git-rebase-mcp`, or `.mcp.json` in the repo	`mcpServers`
Cursor	`.cursor/mcp.json`, or `~/.cursor/mcp.json` for every project	`mcpServers`
Gemini CLI	`.gemini/settings.json`, or `~/.gemini/settings.json`	`mcpServers`
Codex CLI	`codex mcp add git-rebase -- git-rebase-mcp`, or `~/.codex/config.toml`	`[mcp_servers.git-rebase]`
VS Code (Copilot)	`.vscode/mcp.json`	`servers`
Zed	`~/.config/zed/settings.json`	`context_servers`

The two that are not JSON-with-mcpServers:

# ~/.codex/config.toml
[mcp_servers.git-rebase]
command = "git-rebase-mcp"

// .vscode/mcp.json — "servers", not "mcpServers"
{ "servers": { "git-rebase": { "type": "stdio", "command": "git-rebase-mcp" } } }

If the server fails to start in an editor launched from a desktop icon rather than a shell, it is PATH: those processes do not read your shell profile, so ~/.local/bin is missing. Give the absolute path — which git-rebase-mcp — as the command.

Every tool takes a repo argument, defaulting to the working directory, so one installation serves every repository you work in.

For development, clone it and uv sync; uv tool install --from . git-rebase-mcp installs the working tree instead of the published remote.

Prior art

The conflict view is DiffDiff's idea. It shows the same two diffs in vim, and its documented wishlist — commit messages as labels, conflict counts, resolve-with-ours/theirs — anticipates most of this tool surface. This server is that insight delivered to an agent instead of a buffer, wrapped in the rebase state machine.

The regions are DiffDiff's too, and that matters more than it looks. Git's merge has already decided which parts of a file could not be reconciled, and marked exactly those; DiffDiff diffs the three sides of one such block and never sees the rest of the file. Working the regions out independently -- diffing whole sides against the whole base and intersecting -- re-derives that decision badly: two independent diffs cannot know what a merge could reconcile, so a block one side has not reached yet gets fused with a one-line change beside it, and one side ends up with nothing to say. This server made that mistake first and measured it: 4556 characters for one conflict, of which one side was 104 lines of unchanged context. Asking git for the blocks instead brought the same conflict to 289.

Design notes

docs/plan.md — the design, and what is deliberately left out.
docs/decisions/0001-python-rather-than-rust.md — including the two things Rust would have done better, and how each is recovered here.
docs/decisions/0002-git-s-funcname-drivers-rather-than-tree-sitter.md — why naming what a region sits inside did not need a parser, and why the language patterns are git's rather than this server's.

Rebase state is a closed union of four types rather than fields on one object, so rebase_amend accepts one type instead of testing a set of conditions that could drift apart from the states. patiencediff rather than difflib, because the default matcher pairs up the wrong blocks in files that repeat — a test file being the obvious case — and those hunk boundaries are the main output.

Status

The rebase tools are complete and tested, and have driven the same 21-commit branch twice. They caught two defects nothing else would have — a syntax error committed into 8 of 10 commits, and a fixup whose test depended on a commit scheduled after it.

A third run, tidying a branch whose TypeScript conversion had been split from the feature that prompted it, produced the four fixes above: take staging an empty file where the branch had renamed one away, an edit stop reported as "a run of 0 fixup or squash steps", no way to divide a commit without reaching past the tools, and a deliberately dropped commit called damage. Each was found by using the thing, and each is now a test.

A fourth run drove a stack of three branches through six rebases — a squash, two reorders, and a branch replayed onto a rewritten version of the history it was cut from. The two-intents view earned itself there: it turned a conflict that looked like "pick one of these event listeners" into "these are two different events, keep both", which reading markers would not have.

It also produced the last three entries in The quiet ones, each by getting it wrong first — a resolution written from memory that deleted a component, a route lookup and a memo comparator, and a reordered commit shipping a call to a function that did not exist yet. Both were caught by diffing the staged result against HEAD by hand. That is still the check nothing here replaces; the counts only tell you when to bother running it.

What they do not yet do is save much time: nine of eleven conflicts in one run were mechanical shapes resolved by a hand-written script. Phase 2 is planned against that measurement rather than against a feature list, and says how to tell whether it worked.

Contributing

Bug reports from agents are welcome and, so far, are where every feature came from. If the server let you do something destructive, that is the interesting kind of issue: say what you called, what git did, and what you expected — the gap between those two is the whole design brief.

Development

uv sync
uv run pytest       # builds real repositories and runs real git against them
uv run pyright

Tests use scratch repositories rather than mocks. The point of the server is that it agrees with git, so mocking git would test nothing worth testing.

Available Tools

11 tools

rebase_abortA

Abandon the rebase and put back anything that was moved aside.

ParametersJSON Schema

Name	Required	Description	Default
`repo`	No		.

Output Schema

ParametersJSON Schema

Name	Required	Description
`head`	Yes
`guidance`	Yes
`restored`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description must fully disclose behavior. It explains the primary effect (abandonment) and one consequence (restoring moved-aside items), which is helpful. However, it omits details such as error conditions when no rebase is active, whether the action is reversible, or any side effects on uncommitted changes, leaving gaps in behavioral disclosure.

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

Conciseness5/5

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

The description is a single concise sentence with no filler. It states the action and its direct consequence in an efficient manner, fully earning its place.

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

Completeness3/5

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

An output schema exists, but the description is minimal for a destructive operation. It does not indicate prerequisites (e.g., that a rebase must be in progress), potential errors, or what happens to the repository state beyond putting things back. The presence of sibling rebase tools suggests a richer context, but the description itself provides limited completeness.

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?

The schema has one optional parameter 'repo' with a default of '.', and the description does not mention it. With 0% schema description coverage, the description should compensate, but the parameter is self-explanatory from its name and default. The schema already conveys its meaning, so the description adds no additional value, making a mid-range score appropriate.

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?

The description uses the specific verb 'abandon' with the resource 'rebase' and adds effect context ('put back anything that was moved aside'). This clearly distinguishes it from siblings like rebase_continue or rebase_skip, which imply progression rather than cancellation.

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

Usage Guidelines4/5

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

The phrase 'Abandon the rebase' clearly implies the tool is for canceling an in-progress rebase, providing clear context for when to use it. However, it does not explicitly mention when not to use it or name alternatives, so it stops short of a full 5.

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

rebase_amendA

Amend the commit this rebase has just applied.

Refused at every other kind of stop. At a conflicted stop the commit being replayed has not been created yet, so HEAD is still the one before it and amending would fold two commits into one -- silently, and reported by git as success.

stage_tracked stages modifications to files git already tracks. It will not add untracked files: those are never part of what a rebase is rewriting, and sweeping them in is how a stray binary or somebody's local notes end up in history.

ParametersJSON Schema

Name	Required	Default
`repo`	No	.
`message`	No
`stage_tracked`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`after`	Yes
`before`	Yes
`guidance`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses the refusal condition, the dangerous silent-folding scenario at conflicted stops, and the stage_tracked semantics (tracked-only, no untracked files). This goes well beyond the input schema and is highly informative.

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

Conciseness5/5

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

The description is well-structured: main action first, then a critical refusal context, then a parameter explanation. Every sentence adds value and there is no redundant or vague wording.

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

Completeness4/5

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

The description covers the core behavior, refusal reasons, and the most nuanced parameter. It lacks explicit setup for repo/message, but these are relatively self-evident from names and defaults. An output schema exists, so return values are not needed in the description.

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 0%, so the description must compensate. It thoroughly explains stage_tracked, but repo and message are not discussed. The names and defaults offer some hints, but explicit explanation of what 'message' does (e.g., new commit message) and what 'repo' refers to would be needed for full compensation.

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?

The description opens with 'Amend the commit this rebase has just applied,' a specific verb+resource that clearly distinguishes this from sibling tools like rebase_skip, rebase_abort, or rebase_status. It also clarifies the exact scope of operation.

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

Usage Guidelines4/5

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

The description gives strong when-not guidance: 'Refused at every other kind of stop' and explains the conflicted-stop caveat. However, it does not explicitly name alternative tools (e.g., 'use rebase_continue after resolving'), leaving the agent to infer alternatives from sibling names.

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

rebase_conflictsA

Report each conflict as what the two sides did, rather than as markers.

Per contested region you get two diffs from the common base: one for the branch built so far, one for the commit being replayed. Read them as two intents and compose them -- "wrap this block in an if" plus "swap this call" is usually just both.

Regions only one side changed are not listed: git merged those already.

context is how many unchanged lines to show around each change. Raise it when the region is hard to place -- which function it is in, whether the lines above already do what the replayed commit is adding. Set include_full_sides for the three whole texts when even that is not enough.

ParametersJSON Schema

Name	Required	Default
`repo`	No	.
`context`	No
`include_full_sides`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`files`	Yes
`guidance`	Yes
`replaying`	Yes
`replaying_body`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden. It discloses precise behavioral details: per-region two diffs from common base, omission of regions where only one side changed, and parameter effects. This goes well beyond the tool name and provides a clear mental model of the output.

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

Conciseness5/5

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

The description is a single, well-structured paragraph that front-loads the purpose, then covers output structure, exclusions, and parameter tuning. Every sentence contributes meaningful information without repetition or fluff.

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?

The description is complete for a diagnostic tool: it explains what it does, how to interpret results, what is intentionally omitted, and how to vary parameters. The output schema likely covers exact return structure, and the only minor omission of `repo` is acceptable given its default and self-explanatory type.

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

Parameters5/5

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

Schema has 0% description coverage, so the description must compensate. It fully explains both `context` ('how many unchanged lines to show around each change') and `include_full_sides` ('for the three whole texts'), including when to increase them, effectively replacing missing schema documentation.

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?

The description clearly states a specific verb and resource: 'Report each conflict as what the two sides did, rather than as markers.' It distinguishes itself from generic conflict listing by explaining the two-diff structure and what is intentionally omitted, making it stand out among sibling tools.

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

Usage Guidelines4/5

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

The description gives clear context on how to use the tool, including when to adjust `context` and `include_full_sides`. However, it does not explicitly name alternatives or state when to prefer this over `rebase_status` or `rebase_resolve`, so usage is implied rather than explicitly contrasted with siblings.

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

rebase_continueB

Carry on with the rebase, and report where it stops next.

Refused while any path is still unmerged, which is the other way a marker reaches a commit.

auto_resolve behaves as it does in rebase_start, and is off for the same reason: deciding a conflict without reading it is not this tool's job.

ParametersJSON Schema

Name	Required	Description	Default
`repo`	No		.
`auto_resolve`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`head`	Yes
`step`	No
`state`	Yes
`action`	No
`git_said`	No
`guidance`	Yes
`can_amend`	Yes
`replaying`	No
`auto_resolved`	No
`conflicted_files`	No
`head_is_replaying_commit`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the refusal condition and explains why auto_resolve is off, which is useful. Yet it does not mention other side effects or error scenarios beyond the refusal.

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?

The description is short and to the point, with the purpose in the first sentence and additional details in separate short paragraphs. No filler words.

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

Completeness3/5

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

The tool has an output schema (not shown), so return details are covered. The description gives a constraint and auto_resolve context, but relies on knowledge of rebase_start and does not explain prerequisites or the phrase 'the other way a marker reaches a commit'.

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

Parameters2/5

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

Schema coverage is 0%, so the description must compensate. It explains auto_resolve's behavior and default rationale, but does not mention the `repo` parameter at all, leaving it unexplained.

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

Purpose4/5

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

The description clearly states the tool carries on with a rebase and reports the next stopping point. This distinguishes it from siblings like rebase_start and rebase_status, though it does not explicitly name them.

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

Usage Guidelines3/5

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

It provides a refusal condition (while any path is unmerged) and references rebase_start for auto_resolve behavior, giving some context. However, it does not explicitly name alternative tools or state when to choose this over them.

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

rebase_finishA

Check the finished rebase against the tip it started from, and tidy up.

What must stay the same is the change the branch makes to its base -- not the resulting tree, which legitimately changes when the rebase also moves onto newer upstream work. A difference here is a report of damage: a commit dropped from the todo, or a conflict resolved the wrong way. Every rewritten commit is also scanned for conflict markers, since one committed part-way and tidied up later still leaves a commit nobody can build.

The backup tag is kept either way; deleting the only record of where the branch was is not this tool's decision to make.

ParametersJSON Schema

Name	Required	Description	Default
`repo`	No		.
`allow_change`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`commits`	Yes
`guidance`	Yes
`restored`	Yes
`backup_ref`	Yes
`branch_change`	Yes
`reordered_only`	No
`commits_with_markers`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries full responsibility for disclosing behavior. It explains that the tool compares the branch's change to its base rather than the resulting tree, scans for conflict markers, and explicitly states that the backup tag is kept either way. This is substantive behavioral transparency, though it omits details about the 'allow_change' parameter.

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?

The description is moderately verbose but front-loaded with the main purpose. Each paragraph adds a distinct point about the tool's behavior (what must stay the same, conflict marker scanning, backup tag retention). It is well-structured, though some phrasing could be tightened.

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

Completeness3/5

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

The description covers the core behavior and logic well, but it lacks operational details such as what 'tidy up' concretely does and what 'allow_change' influences. While an output schema is present, the missing parameter semantics and side-effect information make the description incomplete for a correct and safe invocation.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not mention the 'repo' or 'allow_change' parameters at all. Most critically, it fails to explain what allowing change does, which is essential for correct invocation. The description adds no parameter-level meaning, leaving the agent to guess.

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?

The description clearly states the tool's specific function: 'Check the finished rebase against the tip it started from, and tidy up.' This distinguishes it from sibling tools like rebase_start, rebase_continue, or rebase_status, which have different roles in the rebase workflow.

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

Usage Guidelines4/5

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

The description implies clear usage context—'Check the finished rebase'—indicating it is used after a rebase has completed. It provides guidance on what to compare (the change to the base) but does not explicitly name alternative tools or exclusions, which keeps it from a 5.

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

rebase_preflightA

Check what a rebase would do, without starting it or changing anything.

Reports commits the todo would drop silently, commits it names that are not in the range, commits whose change is already in the base under a different sha, anything already in progress or uncommitted, and untracked files a replayed commit would collide with.

ParametersJSON Schema

Name	Required	Default
`base`	Yes
`repo`	No	.
`todo`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`base`	Yes
`commits`	Yes
`dropped`	Yes
`unknown`	Yes
`blocking`	Yes
`guidance`	Yes
`stray_fixups`	Yes
`safe_to_start`	Yes
`already_upstream`	Yes
`untracked_collisions`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

Without any annotations, the description carries full responsibility. It explicitly states the tool is non-destructive ('without starting it or changing anything') and details the categories of reports it produces, providing strong transparency beyond what structured fields offer.

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?

Two sentences with no filler. The first sentence is a clear summary; the second packs several report categories into a list. Slightly dense but each clause is informative and earns its place.

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

Completeness4/5

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

The description covers purpose, non-destructive behavior, and the kinds of output, which is sufficient for a preflight check with an output schema present. It does not explicitly mention the 'repo' parameter or usage timing, but the overall context is adequate.

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 0%, so the description must compensate. It indirectly explains 'todo' and 'base' through the report list, but does not explicitly define the parameters, their types, or defaults. 'repo' is entirely omitted. This is partial but not complete compensation.

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?

The description uses a specific verb ('Check') and resource ('what a rebase would do'), and explicitly states that it does not start or change anything. This clearly distinguishes it from sibling tools like rebase_start and rebase_status.

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

Usage Guidelines4/5

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

The description makes the preflight intent clear (check before rebase, without mutating), which implies when to use it. However, it does not explicitly name alternative tools or state when not to use it, though the sibling list provides context.

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

rebase_resolveA

Stage the resolved content for one conflicted path.

Three ways, in rough order of how much they cost to use:

take="both", "branch" or "replaying" resolves every conflict block in the file the stated way. "both" keeps the branch's lines then the replayed commit's, which is what two insertions at the same point almost always mean. Cheapest, and it cannot introduce a typo.
no arguments stages what is already in the working tree, for a file large enough that sending it back costs more than editing it in place.
content writes the finished file and stages it.

Every route refuses content that still contains conflict markers. Staging one is how a commit ends up with <<<<<<< in it, and nothing downstream catches that.

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`repo`	No	.
`take`	No
`content`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	Yes
`guidance`	Yes
`still_conflicted`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description must carry the full transparency burden. It does well by explaining the staging behavior, the three routes, and the safety check that rejects content with conflict markers, including the rationale. It omits details about workspace-side effects or error handling, but the key behavioral traits are disclosed.

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

Conciseness5/5

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

The description is efficiently structured, front-loading the core purpose and then using a clear enumerated list for the three usage modes. Every sentence contributes value—cost ordering, the 'both' meaning, and the safety rule. No fluff, and the length is justified by the tool's complexity.

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

Completeness4/5

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

For a tool with four parameters, no annotations, and an output schema, the description is nearly complete. It covers the main modes and the conflict-marker constraint. It doesn't mention path/repo specifics or how to identify conflicted paths, but sibling tools (rebase_conflicts) fill that gap. Minor omissions keep it from a 5.

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

Parameters4/5

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

Schema coverage is 0%, and the description compensates by explaining 'take' values ('both', 'branch', 'replaying'), the 'content' parameter, and the no-arguments case. However, the `repo` parameter is not mentioned at all. The explanation adds substantial meaning beyond the raw schema, but the repo gap prevents a 5.

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?

The description opens with a specific verb-resource pair: 'Stage the resolved content for one conflicted path.' This clearly identifies the tool's unique role relative to siblings like rebase_conflicts, which lists conflicts, and rebase_status, which shows status. It distinguishes itself as the action of resolving and staging.

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

Usage Guidelines4/5

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

The description provides explicit usage guidance for the three modes ('take', 'no arguments', 'content') and even orders them by cost. It tells the reader when to use 'take' versus editing in place. It does not explicitly name alternative sibling tools (e.g., rebase_skip) for when resolution should be skipped, so it's not a perfect 5.

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

rebase_skipA

Drop the commit being replayed and carry on.

For a commit whose change is already in the base under a different sha, or one whose conflict resolves to "the branch already says this". Git offers it at every conflict; without it here the only way to take that offer is to reach past these tools and run git by hand, which is how a rebase ends up half driven from each side.

Refused when nothing is being replayed: skipping is a decision about a commit, and at a break or a failing exec there is no commit in question.

ParametersJSON Schema

Name	Required	Description	Default
`repo`	No		.
`auto_resolve`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`head`	Yes
`step`	No
`state`	Yes
`action`	No
`git_said`	No
`guidance`	Yes
`can_amend`	Yes
`replaying`	No
`auto_resolved`	No
`conflicted_files`	No
`head_is_replaying_commit`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states the tool drops the commit being replayed, carries on the rebase, and refuses when no commit is in question (at break/exec failure). It also explains the rationale (avoiding manual git half-driving). It doesn't describe side effects like working tree state, but the core mutation is clearly disclosed.

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

Conciseness5/5

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

The description is front-loaded with the central action, followed by a concise rationale and a clear refusal condition. Every sentence earns its place; no filler. It is appropriately sized for the tool's complexity.

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

Completeness3/5

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

The description thoroughly covers the tool's behavior, when to use it, and refusal conditions. However, it completely omits parameter semantics (repo, auto_resolve), which is a significant gap given the 0% schema coverage and the presence of an output schema that doesn't compensate. The behavioral context is good, but the missing parameter information reduces overall completeness.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not mention the 'repo' or 'auto_resolve' parameters at all. The description adds no meaning beyond the bare names in the schema. 'auto_resolve' is particularly ambiguous and undocumented, leaving the agent without necessary information to set parameters correctly.

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?

The description opens with a clear, specific verb+resource: 'Drop the commit being replayed and carry on.' It precisely identifies the tool's function (skipping the current commit during a rebase) and distinguishes it from sibling tools like rebase_resolve (which resolves conflicts) and rebase_continue (which continues after resolution).

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

Usage Guidelines4/5

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

The description provides explicit use cases: when a commit's change is already in the base under a different sha, or when a conflict resolves to 'the branch already says this.' It also states when the tool is refused (at a break or failing exec), giving clear context. However, it does not explicitly name alternative tools, instead referring to running git by hand, which slightly weakens the alternative guidance.

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

rebase_startA

Begin a rebase onto base, and report where it stops.

Refuses anything rebase_preflight called unsafe, unless force. Before starting it tags the current tip, so the result can be checked against it, and moves aside untracked files a replayed commit would collide with.

autosquash folds every fixup! and squash! in the range into the commit its subject names, which is the workflow git commit --fixup sets up. It cannot be combined with a todo, since it is a way of generating one.

check_command is run after every commit, which is the only thing that catches a step that applies cleanly but leaves the tree broken.

auto_resolve composes conflicts where the two sides touched different lines and carries on without stopping. Off by default: lines that do not overlap can still contradict each other -- one side adding a call, the other removing the helper it needs -- and a conflict resolved without being read has to be reviewed afterwards anyway. Use it when replaying a branch whose conflicts you already understand.

ParametersJSON Schema

Name	Required	Default
`base`	Yes
`repo`	No	.
`todo`	No
`force`	No
`autosquash`	No
`auto_resolve`	No
`check_command`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`stashed`	Yes
`guidance`	Yes
`backup_ref`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavioral details: tags the current tip for checking, moves aside untracked files, runs check_command after every commit, and explains auto_resolve composition behavior. This far exceeds minimal safety/effect disclosure.

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

Conciseness5/5

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

The description is tightly structured with four paragraphs, each focused on a distinct aspect: main behavior, autosquash, check_command, and auto_resolve. Every sentence adds value and is front-loaded with the primary action.

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

Completeness4/5

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

The description covers the operation's complexity well, including failure modes and flag interactions. It doesn't explain the return format, but an output schema exists to fill that gap. The missing 'repo' parameter is a minor gap in an otherwise complete description.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must explain parameters. It covers base, force, autosquash, check_command, and auto_resolve in depth. However, 'repo' is not explained at all, and 'todo' is only mentioned as incompatible with autosquash, lacking format or usage details.

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?

The description opens with a specific verb and resource: 'Begin a rebase onto `base`, and report where it stops.' This clearly identifies it as the starting operation in the rebase lifecycle and distinguishes it from siblings like rebase_continue or rebase_abort.

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

Usage Guidelines4/5

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

Provides clear usage conditions: refuses unsafe operations unless force, cannot combine autosquash with todo, and auto_resolve is off by default with guidance on when to use it. Does not explicitly name sibling alternatives for when not to use this tool, but the context is strong.

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

rebase_statusA

Report what the rebase in repo is currently doing.

Call this before amending, continuing or resolving. In particular head_is_replaying_commit distinguishes a stop where the commit was applied from one where it conflicted part-way, which git's own output does not.

ParametersJSON Schema

Name	Required	Description	Default
`repo`	No		.

Output Schema

ParametersJSON Schema

Name	Required	Description
`head`	Yes
`step`	No
`state`	Yes
`action`	No
`git_said`	No
`guidance`	Yes
`can_amend`	Yes
`replaying`	No
`auto_resolved`	No
`conflicted_files`	No
`head_is_replaying_commit`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description is the only source of behavioral information. It adds useful context about the `head_is_replaying_commit` field and how it differs from git's output, but it does not state whether the tool is read-only, what happens if no rebase is in progress, or any error conditions. This leaves safety and edge-case behavior undisclosed.

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

Conciseness5/5

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

The description is two sentences, each earning its place: the first states the purpose, the second provides usage guidance and a key output detail. No redundancy with the schema or titles.

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

Completeness4/5

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

The tool is simple (one parameter) and has an output schema, so the description doesn't need to explain return values. It gives enough context for a developer to understand when to invoke it, but it omits edge-case behavior (e.g., no rebase in progress). Overall, it is a solid but not exhaustive description.

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

Parameters2/5

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

The description mentions `repo` only as part of the resource phrase ('in `repo`') and does not explain the parameter's meaning, format, or default behavior. Schema description coverage is 0%, and the description does not compensate by clarifying that repo defaults to '.' (current directory) or what values are acceptable.

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?

The description uses the specific verb 'Report' with the resource 'the rebase in repo', clearly distinguishing this status tool from sibling action tools like rebase_amend, rebase_continue, and rebase_resolve. The first sentence unambiguously states what it does.

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?

The description explicitly tells the agent to 'Call this before amending, continuing or resolving,' naming the exact sibling actions that should follow. It also explains the unique value of the `head_is_replaying_commit` field, which helps the agent know when to use the tool.

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

rebase_todoA

Read the steps a running rebase has left, or replace them.

Worth having because the need shows up mid-run: a fixup turns out to depend on a commit scheduled after it, and the fix is to move one line rather than to abandon thirty resolved conflicts and start again.

Replacing the list can drop commits exactly as writing one badly can, so the same check applies: a commit in the remaining steps and not in the replacement is refused unless force. Lines that name no commit -- exec above all -- are counted too, and dropping every exec silently turns off the per-commit check, so that is called out rather than assumed.

ParametersJSON Schema

Name	Required	Default
`repo`	No	.
`todo`	No
`force`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`dropped`	Yes
`guidance`	Yes
`remaining`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly explains the safety check: replacements that drop commits are refused unless force, exec lines are counted, and dropping all execs silently disables the check—which is called out. This goes well beyond basic expectations.

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?

The description is longer than a simple one-line statement, but each paragraph earns its place: the lead sentence defines the tool, the second gives motivational context, and the third is a critical safety explanation. The structure is logical and front-loaded with the core purpose.

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?

Given the tool's moderate complexity (read/replace with nuanced safety rules), the description covers the important behavior and usage context. An output schema exists, so return values are not needed in the description. The dual read/write behavior is implicitly tied to the 'todo' parameter default of null, which is inferable from the schema.

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?

The description explains the role of 'todo' (replacement list) and 'force' (allows dropping commits) but does not mention the 'repo' parameter. With 0% schema description coverage, this partial explanation compensates only somewhat. The format of the todo array entries is also left vague, though examples like 'exec' hint at it.

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?

The description opens with 'Read the steps a running rebase has left, or replace them,' which clearly states the tool's dual function on the rebase todo list. This is a specific verb+resource combination and distinguishes it from siblings like rebase_status (which reports status) and rebase_amend (which edits commits).

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

Usage Guidelines4/5

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

The 'Worth having because' paragraph gives a concrete scenario ('a fixup turns out to depend on a commit scheduled after it') and explains the value of editing the todo list instead of aborting and restarting. It also implicitly advises when to use force. However, it does not explicitly name alternative tools or state when not to use this tool.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool addresses a distinct phase of the rebase lifecycle: status, conflicts, resolve, todo, preflight, start, amend, continue, finish, skip, abort. No two tools have overlapping purposes; descriptions reinforce clear boundaries.

Naming Consistency5/5

All tool names follow the exact same pattern: 'rebase_' + a verb or noun (e.g., rebase_start, rebase_abort, rebase_todo). Consistent snake_case and predictable structure make the set easy to navigate.

Tool Count5/5

11 tools is well-scoped for a git rebase focused server. Each tool covers a necessary part of the workflow without redundancy, and the count feels neither sparse nor bloated.

Completeness5/5

The toolset covers the full rebase workflow: preflight checks, starting, monitoring, conflict resolution, amending, continuing, skipping, aborting, and final verification. No obvious missing operation is apparent for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
registry A
com.policylayer
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
Security Developer Tools
521
Azure DevOps (ADO)
io.github.PremierInc
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
CI/CD & DevOps Version Control Project Management
21,997
secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181

Related MCP Servers

git-training-wheels
Version Control Developer Tools
lava
A
license
A
quality
D
maintenance
An MCP server that enforces safe git commits by allowing only specified files and providing fixup capabilities for earlier commits.
Updated a year ago (2025-07-28 08:54 UTC)
2
1
MIT
git-surgeon-mcp
Version Control Developer Tools
mustafatekiinn
F
license
A
quality
C
maintenance
An MCP server that gives AI agents safe, non-interactive Git history editing — squashing, rewording, and reflog rescue — without ever hanging on a Vim buffer.
Updated a month ago (2026-07-20 21:45 UTC)
4
git-mcp-server
Version Control Developer Tools
saitolume
A
license
A
quality
B
maintenance
A local MCP server that provides a safe, explicit set of Git operations for version control tasks like status, diff, branching, staging, committing, fetching, merging, and pushing.
Updated a month ago (2026-08-01 20:01 UTC)
13
26
MIT
mcp-gitwand
Version Control Developer Tools
devlint
A
license
Not graded
quality
A
maintenance
an MCP server that auto-resolves Git merge conflicts so agents only touch the complex hunks — deterministic pattern engine with confidence scores and a full decision trace, plus merge/rebase preview and hunk-level resolution tools
Updated 4 hours ago (2026-09-04 08:14 UTC)
167
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aaron-riact/git-rebase-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server