Context
Sub of #10214. See parent epic for architectural rationale. This ticket focuses on the implementation delta for Sub 3 — adding a native MCP tool surface for GitHub's PR-reviewer-request API.
The Problem
#10208 / PR #10211 merged the cross-family PR review mandate (Claude-family ↔ Gemini-family Approved review required before merge). The mandate is the validation mechanism. No corresponding invitation mechanism exists — reviewers learn about PRs needing their review via notification polling or manual discovery. GitHub natively supports PR reviewer-requests via the requested_reviewers API (gh pr edit --add-reviewer <login>), but no MCP tool exposes it.
Under the cross-family mandate's 7-day-open fallback, invitation is the natural escalation step BEFORE the fallback fires. Without an invitation mechanism, authors rely on reviewers noticing PRs organically — which is the exact latency this ticket closes.
The Architectural Reality
GitHub API: POST /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers — accepts reviewers (array of logins) and team_reviewers (array of team slugs). Returns the updated PR.
GH CLI equivalent: gh pr edit <pr-number> --add-reviewer <login>.
github-workflow MCP server already surfaces manage_issue_assignees (for issue assignees) and manage_issue_comment (for comments). A sibling manage_pr_reviewers tool completes the coverage. Alternative: extend manage_issue_assignees with a target: 'pr_reviewers' action mode. Less preferred — orthogonal surface, distinct API path.
The Fix
- Add new MCP tool
manage_pr_reviewers to github-workflow server:
- Actions:
add, remove
- Args:
pr_number, reviewers (array of GH logins), optional team_reviewers
- Returns: updated PR reviewer list
- Document the tool in the server's OpenAPI spec + the relevant skill references.
- Cross-reference from
pull-request §6.1 Cross-Family Mandate:
- Add a line: "If no cross-family reviewer has engaged ~2 hours after open, author SHOULD formally request review via
manage_pr_reviewers add. This is the invitation layer; the mandate's Approved-status requirement is the validation layer."
- Consider a convention for the
~2 hours threshold — or leave as soft guidance; author judgment.
Acceptance Criteria
Out of Scope
- Automatic reviewer assignment based on CODEOWNERS — separate mechanism (GitHub already auto-requests CODEOWNERS; this tool is for manual invitation)
- Reviewer rotation / load balancing — YAGNI until the swarm grows beyond Claude ↔ Gemini
- Team-based reviewer requests (
team_reviewers) — include in tool signature but low priority on initial implementation; current swarm uses individual identities
- Integration with the 7-day-open fallback's verification logic — fallback still reads
get_conversation independently; invitation is orthogonal
Related
- Parent epic:
#10214
- Sibling / validation layer:
#10208 cross-family mandate (merged); pull-request §6.1
- Sibling / invitation companion: this ticket
- Adjacent tool pattern:
manage_issue_assignees (existing; analogous shape)
Handoff Retrieval Hints
query_raw_memories(query="manage_pr_reviewers MCP tool GitHub requested_reviewers invitation layer")query_summaries(query="cross-family PR review invitation vs validation")
Known contributing sessions:
ae546a40-2133-482f-85a6-779fdf6757b2 (epic authoring session)
Context
Sub of
#10214. See parent epic for architectural rationale. This ticket focuses on the implementation delta for Sub 3 — adding a native MCP tool surface for GitHub's PR-reviewer-request API.The Problem
#10208/ PR#10211merged the cross-family PR review mandate (Claude-family ↔ Gemini-family Approved review required before merge). The mandate is the validation mechanism. No corresponding invitation mechanism exists — reviewers learn about PRs needing their review via notification polling or manual discovery. GitHub natively supports PR reviewer-requests via therequested_reviewersAPI (gh pr edit --add-reviewer <login>), but no MCP tool exposes it.Under the cross-family mandate's 7-day-open fallback, invitation is the natural escalation step BEFORE the fallback fires. Without an invitation mechanism, authors rely on reviewers noticing PRs organically — which is the exact latency this ticket closes.
The Architectural Reality
GitHub API:
POST /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers— acceptsreviewers(array of logins) andteam_reviewers(array of team slugs). Returns the updated PR.GH CLI equivalent:
gh pr edit <pr-number> --add-reviewer <login>.github-workflowMCP server already surfacesmanage_issue_assignees(for issue assignees) andmanage_issue_comment(for comments). A siblingmanage_pr_reviewerstool completes the coverage. Alternative: extendmanage_issue_assigneeswith atarget: 'pr_reviewers'action mode. Less preferred — orthogonal surface, distinct API path.The Fix
manage_pr_reviewerstogithub-workflowserver:add,removepr_number,reviewers(array of GH logins), optionalteam_reviewerspull-request §6.1 Cross-Family Mandate:manage_pr_reviewers add. This is the invitation layer; the mandate's Approved-status requirement is the validation layer."~2 hoursthreshold — or leave as soft guidance; author judgment.Acceptance Criteria
manage_pr_reviewersMCP tool implemented inai/mcp/server/github-workflow/services/withadd+removeactionspull-request §6.1cross-references the tool as the invitation mechanismOut of Scope
team_reviewers) — include in tool signature but low priority on initial implementation; current swarm uses individual identitiesget_conversationindependently; invitation is orthogonalRelated
#10214#10208cross-family mandate (merged);pull-request §6.1manage_issue_assignees(existing; analogous shape)Handoff Retrieval Hints
query_raw_memories(query="manage_pr_reviewers MCP tool GitHub requested_reviewers invitation layer")query_summaries(query="cross-family PR review invitation vs validation")Known contributing sessions:
ae546a40-2133-482f-85a6-779fdf6757b2(epic authoring session)