LLM coding agents like Claude Code are getting alarmingly good at writing PRs. What they’re not yet good at is structuring multi-step work: an agent left to its own devices will happily produce one 3,000-line PR with eight loosely-related fixes baked in.

The fix is to give the agent the same primitive humans use: stacked diffs. That’s what the stkd MCP server is for. Add it to Claude Code’s config and the agent can create dependent branches, submit stacks, and clean up after itself — natively.

What MCP is, briefly

The Model Context Protocol is an open spec from Anthropic for letting AI models call external tools. An MCP server presents a set of tools (each with a JSON Schema), and the model calls them via a normal tool-use loop. stkd-mcp is one of those servers.

In practice, after you wire it up, Claude can do this entirely on its own:

[ tool use: gt_create { name: "feature/auth-base" } ]
[ tool result: branch created on top of main ]

… makes edits via the file-editing tools …

[ tool use: gt_create { name: "feature/auth-oauth" } ]
[ tool result: branch created on top of feature/auth-base ]

… more edits …

[ tool use: gt_submit { stack: true } ]
[ tool result: PRs #41, #42, #43 created ]

No shell-outs to bash. No fragile prompt parsing. The agent works with typed tool calls and structured responses.

Wiring up Claude Code

1. Install the MCP server

cargo install stkd-mcp

# verify it runs
stkd-mcp --version

You’ll have a stkd-mcp binary on your PATH.

2. Add it to Claude Code’s config

Edit ~/.claude.json (or claude_desktop_config.json on desktop) and add:

{
  "mcpServers": {
    "stkd": {
      "command": "stkd-mcp"
    }
  }
}

Restart Claude Code. In the tools menu you should now see stkd with sub-tools gt_create, gt_submit, gt_restack, gt_sync, gt_land, gt_log, gt_modify, gt_continue, gt_undo.

3. Try it

In a Claude Code session inside a repo that has gt repo init already run:

“Split the changes I’ve made in src/auth/ into three focused PRs: one for the schema migration, one for OAuth, and one for 2FA. Push them as a stack.”

Claude will inspect the diff, create three branches, distribute the changes, run gt submit --stack, and report back with the PR numbers. The whole sequence is auditable in the tool-use transcript.

The tools, in detail

A short tour of the surface, in the order you’d typically reach for them:

gt_create

Creates a new branch stacked on top of the current branch.

// Input
{ "name": "feature/auth-oauth", "from": "feature/auth-base" }  // `from` optional
// Output
{ "branch": "feature/auth-oauth", "parent": "feature/auth-base" }

gt_log

Returns the current stack as JSON.

// Output
{
  "stack": [
    { "branch": "main", "parent": null, "current": false },
    { "branch": "feature/auth-base", "parent": "main", "current": false, "pr": 41 },
    { "branch": "feature/auth-oauth", "parent": "feature/auth-base", "current": true, "pr": 42 }
  ]
}

This is the tool agents reach for first when planning anything — it lets them ground their next step in the actual state of the world.

gt_modify

Amends the current branch’s tip commit with new changes (the agent has typically already done file edits via its own tools).

{ "amend": true, "message": "fix typo" }

gt_restack

Re-bases every dependent branch after a change to an ancestor.

{ "trunk": false }  // pass true to also restack against latest origin/main

gt_submit

Pushes branches and creates / updates PRs or MRs.

{ "stack": true, "draft": false, "reviewers": ["@team-platform"] }

gt_sync

Fetches origin, detects merged branches, cleans up, and restacks.

{ "prune": true }

gt_land

Merges the bottommost open PR; with --stack, merges every PR in order.

{ "stack": true, "strategy": "squash" }

gt_continue / gt_undo

For when an operation hits a conflict (gt_continue after resolution) or the agent realises it made a mistake (gt_undo rolls back the last stkd mutation).

Safety: the agent is in your shell

stkd-mcp runs locally. It uses your existing gh / glab credentials. It can push code under your name. That’s exactly as much power as you intended to grant, but the implications are worth being explicit about:

  • The agent inherits your auth. Anything you can push to, it can push to.
  • Pushes are real. A gt_submit opens real PRs on real repos. People will see them and possibly review them.
  • Rebasing rewrites history. gt_restack force-pushes branches in your stack.

stkd-mcp ships with several safeguards you should know about:

Allowlist tools

If you only want the agent to plan but not act, restrict the toolset:

{
  "mcpServers": {
    "stkd": {
      "command": "stkd-mcp",
      "args": ["--tools=gt_log,gt_create"]
    }
  }
}

Dry-run mode

Every mutating tool becomes a no-op that reports what would have happened:

{
  "mcpServers": {
    "stkd": {
      "command": "stkd-mcp",
      "args": ["--dry-run"]
    }
  }
}

Branch pattern lock

Restrict the agent to a branch namespace it can’t escape:

{
  "mcpServers": {
    "stkd": {
      "command": "stkd-mcp",
      "args": ["--branch-pattern=claude/*"]
    }
  }
}

Now gt_create will reject name: "feature/whatever" and only accept name: "claude/whatever". Your protected branches and personal branches are off-limits.

Read-only mode

Combine --tools and --dry-run for “the agent can plan but not act”:

{ "args": ["--tools=gt_log,gt_create", "--dry-run"] }

Real-world patterns

A few patterns we’ve seen agents use well:

Split a big diff into a stack

The example earlier — the agent reads your working tree, identifies cohesive groups of changes, and lays out the stack. Works well for “I’ve been hacking for two hours, please turn this into reviewable PRs.”

Sweep restacks

After main advances by 50 commits, every stack you have is stale. Ask the agent: “Run gt_sync on each of my repos in ~/code/* and report which stacks now have conflicts.” The agent iterates, calls gt_sync, and gives you a focused report.

Conflict triage

When gt_restack hits a conflict, stkd-mcp returns the conflict markers and a structured description (file paths, hunks). Claude is unusually good at resolving simple conflicts (renames, import reorderings, formatting). For non-trivial conflicts, the agent can summarise the situation and hand back to you with a clear question.

CI babysitter

After a gt_submit, the agent can poll PR statuses via your gh / glab CLI and surface failures as soon as they happen — no need to context-switch back to a browser.

What this is not

A small disclaimer to set expectations:

  • It is not an autonomous code reviewer. The agent can ask GitHub for review-comments, but a human still owns the approval decision.
  • It is not a replacement for your CI. Tests still need to run. The agent doesn’t approve its own PRs by default.
  • It will not invent the “right” split of your diff. The agent will do something reasonable, but a thoughtful split is still your call — and reviewing the agent’s split before gt_submit takes 30 seconds.

Next steps

The MCP server is the most impactful integration in stkd’s surface. Half an hour spent wiring it into your editor is half an hour you’ll get back the first time you use it.