Clean PR — extends the existing tool correctly, uses the right GraphQL mutations, and tests cover the key cases. Ready for merge with minor notes:

1. Unused required params — owner/repo/pullNumber are silently ignored for resolve_thread/unresolve_thread. A one-liner in the method description would prevent confusion.
2. Test gap — threadId: "" is tested, but fully omitted threadId isn't. Go zero-value likely handles it, but worth an explicit case.
3. Idempotency — Worth noting in the method description that resolving an already-resolved thread is a no-op, so agents don't add unnecessary guard logic.
4. Minor DRY opportunity — Resolve/unresolve branches share nearly identical mutation structs. Not a blocker.

Nice work filling a real gap in the PR review workflow.

I believe the feedback should be addressed. I'm not a frequent contributor to this repo so if there is anything I need to amend just let me know! I squashed the commits as well

Would love to get this feature in - currently when claude et al. are using the github MCP server they can create threads with suggestions but if the suggestion is approved / fixed they can't resolve the thread.

It may seem like a small quality of life thing but it's nice when we can get the thread resolved.

We could really use this as well!

Everything is updated, is there anyone who can help with merging or letting me know what to update?

Hey @plwalters, I also need this feature and wanted to help move it forward with a review.

Review

Clean PR — extends the existing pull_request_review_write tool correctly with resolve_thread and unresolve_thread methods. Uses the right GraphQL mutations, includes good input validation, and tests cover success, empty/omitted input, and error scenarios. Nice work.

Missing thread ID in get_review_comments output

This is the main gap. The tool description says "Get thread IDs from pull_request_read with method get_review_comments", but MinimalReviewThread does not include an ID field:

type MinimalReviewThread struct {
    IsResolved  bool                   `json:"is_resolved"`
    IsOutdated  bool                   `json:"is_outdated"`
    IsCollapsed bool                   `json:"is_collapsed"`
    Comments    []MinimalReviewComment `json:"comments"`
    TotalCount  int                    `json:"total_count"`
}

The underlying reviewThreadNode GraphQL type already has ID githubv4.ID, but convertToMinimalReviewThread doesn't expose it. Without this, callers have no way to discover the threadId needed for resolve/unresolve through the MCP server itself.

Fix would be:

• Add ID string \json:"id"`toMinimalReviewThread`
• Add ID: fmt.Sprintf("%v", thread.ID) to convertToMinimalReviewThread

owner/repo/pullNumber required but unused (minor)

The schema has Required: []string{"method", "owner", "repo", "pullNumber"}, but resolve_thread/unresolve_thread only use params.ThreadID. The description documents this clearly, so it's just a minor UX friction — callers must provide dummy values for unused fields. Not a blocker, just a trade-off of the multi-method tool pattern.

Everything else looks good

• Correct use of githubv4.ResolveReviewThreadInput / UnresolveReviewThreadInput
• Proper error handling with ghErrors.NewGitHubGraphQLErrorResponse
• Idempotency documented in method descriptions
• Tests cover resolve, unresolve, empty threadId, omitted threadId, and GraphQL errors

Generated-by: Claude Code

Thank you for the contribution!

Thanks for approving it! Our team will appreciate this one for sure