Possibility of adding a MCP

[falconmick]

Howdy!

Was thinking it could be handy to expose the ability to utilise this utility with a light weight mcp wrapper to allow my agents to spin up worktrees on the fly, would a contribution to this repo be at all plausible and if so has any preference around the approach?

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[mausch]

Haven't tried it myself yet but some repos just add instructions for gtr in their AGENTS.md and/or skills
e.g.
https://github.com/drevantonder/openfinance/blob/16145f05b2939e1a24a82fcc90e1b56c21f1c422/docs/AGENTS.md
https://github.com/cataclysmbn/Cataclysm-BN/blob/dbc58c1b0196b805ebd9200fd3d2916535b4dc88/AGENTS.md

[abhraneeldhar7]

Recently added mcp with oauth flow for my side project, can I work on it?

[anatolykoptev]

@falconmick good call — letting agents manage their own worktrees is basically what gtr is for. @abhraneeldhar7, if you're already on this, happy to compare notes or hand it over.

I built a small working MCP server for gtr to make the options concrete: https://github.com/anatolykoptev/gtr-mcp. It wraps the core worktree actions — list, create, status, rename, remove, clean — as tools, and asks for an explicit confirm before anything destructive so an agent can't delete a worktree on a misread. I left out a generic "exec" tool on purpose; agents already have a shell, and that's the easy way to get burned.

I saw there's an earlier in-repo attempt in #74 that didn't get merged — so I went the standalone-package route, which keeps a JS/MCP surface out of the Bash repo and leans on the existing AGENTS.md for the "when to use a worktree" guidance rather than baking it into a tool.

@mausch, before I send anything — is a standalone package the right shape here, or would you rather it live in the repo? Either's fine; just didn't want to drop a surprise PR. (I maintain go-mcpserver and run a few MCP servers myself, so glad to shape it however works.)

[mausch]

@anatolykoptev just had a quick look a https://github.com/anatolykoptev/gtr-mcp . IMHO the GTR_MCP_REPO_PATH makes it a non-starter.

[anatolykoptev]

Fair point on GTR_MCP_REPO_PATH — ripped it out and rebuilt around it.

It's cwd-native now, like gtr itself: works on the repo at the working directory, no repo_path arg, no pinning env, one server = one repo. Dropped the exec tool too (you've got a shell). What's left only does what the CLI can't hand an agent — JSON from list/status and a confirm gate on deletes.

Standalone, not asking you to carry JS in a Bash repo: https://github.com/anatolykoptev/gtr-mcp (v0.4.0). Link it if it's ever useful, no worries if not.

[helizaga]

Thanks all — we looked into this and decided not to add a first-party MCP server to GTR. Most coding agents already have shell access, and maintaining a separate MCP runtime in this Bash project doesn’t feel worth the added complexity.

Instead, #192, released in v2.10.0, adds:

• git gtr new --porcelain with stable path, branch, and hook_status output
• clean stdout/stderr separation for agent integrations
• documented AGENTS.md guidance and safety boundaries

This gives shell-capable agents a stable native interface. Standalone MCP projects can still build on that contract if useful, but we don’t plan to maintain an in-repo MCP implementation.

Thanks again for the ideas and prototypes here. Closing this out as not planned.