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_comment returns the comment's node ID (PRRC_...), which is distinct from the thread's node ID.
pageInfo.startCursor / endCursor are pagination cursors, not thread IDs.
- Within an MCP-only session there is no
gh CLI 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_comments response schema — include PullRequestReviewThread.id (GraphQL node ID) as id or node_id on each thread object.
- Add a dedicated method —
pull_request_read method=get_review_threads that returns a thin list of threads with their node IDs (and the existing is_resolved / is_outdated / is_collapsed flags).
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
Background
After #1768 shipped,
resolve_review_threadis available as an MCP tool. However, the companion read path — retrieving a review thread's GraphQL node ID so it can be passed toresolve_review_thread— is still missing from the response schema.When an AI agent is addressing PR review feedback, the typical flow is:
pull_request_read method=get_review_comments.add_reply_to_pull_request_comment.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_commentsreturns eachreview_threads[]object with these fields only:{ "is_resolved": false, "is_outdated": false, "is_collapsed": false, "comments": [...], "total_count": N }There is no
id/node_idfield on the thread object, so there is no way to obtain the valueresolve_review_threadrequires.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.ghCLI or direct GraphQL escape hatch.Note: issue #1768 stated that "the thread IDs are already returned by
get_review_commentsin theIDfield". That does not appear to match the current shipped response schema — theIDfield 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_commentsreturns no field usable as thethread_idargument ofresolve_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 manualgh api graphqlcalls 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
idfield on each thread.Proposal
Either:
get_review_commentsresponse schema — includePullRequestReviewThread.id(GraphQL node ID) asidornode_idon each thread object.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/isCollapsedare exposed), so addingidto the same selection set should be a minimal change.Current workaround
For MCP-only sessions,
resolve_review_threadis effectively unreachable — users must drop out of MCP and click "Resolve conversation" in the GitHub web UI (or rungh api graphqloutside the session). This defeats the purpose of shipping the tool in #1768.References
resolve_review_threadis_resolvedexposure on comments