Repository navigation
infra: expose review thread node ID in get_review_comments response (follow-up to #1768) #2331
Description
Background
After #1768 shipped, resolve_review_thread is available as an MCP tool. However, the companion read path — retrieving a review thread's GraphQL node ID so it can be passed to resolve_review_thread — is still missing from the response schema.
When an AI agent is addressing PR review feedback, the typical flow is:
- Read review comments with
pull_request_read method=get_review_comments. - Reply to the comment with
add_reply_to_pull_request_comment. - Resolve the thread with
resolve_review_thread.
Step 3 requires the thread's node ID (e.g. PRRT_kwDO...), but step 1's response does not expose it.
Problem
pull_request_read method=get_review_comments returns each review_threads[] object with these fields only:
{
"is_resolved": false,
"is_outdated": false,
"is_collapsed": false,
"comments": [...],
"total_count": N
}There is no id / node_id field on the thread object, so there is no way to obtain the value resolve_review_thread requires.
Auxiliary paths are also blocked:
add_reply_to_pull_request_commentreturns the comment's node ID (PRRC_...), which is distinct from the thread's node ID.pageInfo.startCursor/endCursorare pagination cursors, not thread IDs.- Within an MCP-only session there is no
ghCLI or direct GraphQL escape hatch.
Note: issue #1768 stated that "the thread IDs are already returned by get_review_comments in the ID field". That does not appear to match the current shipped response schema — the ID field is absent on the thread object as of 2026-04-15.
Reproduction
On any PR with multiple unresolved review threads, calling pull_request_read method=get_review_comments returns no field usable as the thread_id argument of resolve_review_thread. This was observed while addressing Copilot PR reviewer feedback on a PR with 5 unresolved threads — the workflow had to fall back to manual gh api graphql calls outside MCP to complete step 3.
Minimal repro outside MCP — compare the current MCP response shape to this GraphQL query, which does expose the thread id:
{
repository(owner: "<owner>", name: "<repo>") {
pullRequest(number: <n>) {
reviewThreads(first: 50) {
nodes { id isResolved isOutdated }
}
}
}
}The MCP response should surface the same id field on each thread.
Proposal
Either:
- Extend the
get_review_commentsresponse schema — includePullRequestReviewThread.id(GraphQL node ID) asidornode_idon each thread object. - Add a dedicated method —
pull_request_read method=get_review_threadsthat returns a thin list of threads with their node IDs (and the existingis_resolved/is_outdated/is_collapsedflags).
Option 1 is likely a single-field addition: the underlying GraphQL query almost certainly already selects the thread object (since isResolved/isOutdated/isCollapsed are exposed), so adding id to the same selection set should be a minimal change.
Current workaround
For MCP-only sessions, resolve_review_thread is effectively unreachable — users must drop out of MCP and click "Resolve conversation" in the GitHub web UI (or run gh api graphql outside the session). This defeats the purpose of shipping the tool in #1768.
References
- Add support for resolving/unresolving PR review threads #1768 — original request that added
resolve_review_thread - get_pull_request_review_comments doesn't return resolved state #1086 —
is_resolvedexposure on comments - MCP tool list snapshot date: 2026-04-15
Activity
SamMorrowDrums commentedon Apr 22, 2026
Tracking this with PR #2245, which restores the review thread
idfield inget_review_commentssoresolve_thread/unresolve_threadcan work end-to-end again.feat(cloud): add Auto-fix + gh-over-MCP guidance, user-level CLAUDE.md