github / github/github-mcp-server
Add MCP tools for GitHub Stacked PRs (gh stack link / sync / view)
- Ngôn ngữ chính
- Go
- Star
- 33k
- Fork
- 5k
- Merge trung bình
- 2 ngày 1 giờ
- Pull request đã merge (30 ngày)
- 52
Mô tả
## Describe the feature or problem you’d like to solve
Agents that manage **stacked / dependent PRs** (each PR’s `base` is the branch below it) can already create and re-base-point individual PRs via `create_pull_request` / `update_pull_request`, but they have **no first-class way** to:
1. Discover or read a GitHub **native stack** (the stack object / annotations created by `gh stack link` / `gh stack submit`)
2. Create or update that stack as a unit
3. Cascade-rebase / sync the tower when trunk moves (`gh stack sync` / `gh stack rebase`)
4. Merge bottom-up with stack-aware ordering
Today the only path to native stacks is the `gh stack` CLI extension (`github/gh-stack`), which many agent environments intentionally don’t expose (token stays on a host proxy; container `gh` is stubbed; agents talk to GitHub through this MCP).
## Proposed solution
Add a small **stack toolset** (or extend `pull_requests`) that mirrors the operations agents already need from `gh stack`, without shelling out:
| Tool | Purpose |
|---|---|
| `list_stacks` / `get_stack` | Resolve a stack by number, PR number, or head branch; return ordered PRs + trunk |
| `link_stack` | Create/update a stack from an ordered list of PR numbers or branches (`gh stack link`) |
| `update_stack` | Reorder / reparent / drop layers |
| `sync_stack` | Cascade-rebase onto trunk + push with lease semantics (`gh stack sync`) — or return structured rebase instructions if server-side git is out of scope |
| `merge_stack` | Merge bottom-up, stopping on the first non-mergeable layer |
Minimum useful v1: **read + link** (`get_stack`, `link_stack`). Agents can already do Path-B base-chaining with `update_pull_request(base=…)`; what’s missing is the **native stack object** and a single call that wires N PRs correctly.
## Example
```text
link_stack(
owner: "org",
repo: "app",
base: "develop", # trunk
pull_numbers: [7609, 7797, 7810, 7815, …] # bottom → top
)
→ { stack_number: 7928, prs: [...] }
get_stack(owner, repo, stack_number: 7928)
→ ordered layers with number, head, base, mergeable, reviewDecision
Hướng dẫn đóng góp
Hướng nghiên cứu
Start by reviewing the existing create_pull_request and update_pull_request tools, then compare their base-chaining behavior with the proposed get_stack and link_stack operations. A minimum v1 is complete when agents can read a native stack and create or update one from an ordered list of pull requests or branches, with ordered layers and trunk returned.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- go
- Lĩnh vực
- api, backend
- Loại issue
- Tính năng
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức độ hoạt động
- Sôi nổi
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 35/100