Skip to content

Add support for resolving/unresolving PR review threads #1768

Description

@kulakowka

Describe the feature or problem you'd like to solve

When working with PR review comments via MCP, there's no way to resolve or unresolve review threads programmatically. The get_review_comments method returns IsResolved status (related to #1086), but there's no corresponding mutation to change it.

Currently, to resolve review threads, users must manually go to the GitHub UI and click "Resolve conversation" for each thread.

Proposed solution

Add a new tool resolve_review_thread (or extend existing PR review tools) that wraps the GraphQL mutation:

mutation {
  resolveReviewThread(input: {threadId: "PRRT_xxx"}) {
    thread { isResolved }
  }
}

And optionally unresolveReviewThread for the reverse operation.

Suggested tool schema:

{
  "name": "resolve_review_thread",
  "description": "Resolve or unresolve a PR review thread",
  "inputSchema": {
    "type": "object",
    "properties": {
      "thread_id": {
        "type": "string",
        "description": "The node ID of the review thread (e.g., PRRT_kwDO...)"
      },
      "resolve": {
        "type": "boolean",
        "description": "true to resolve, false to unresolve",
        "default": true
      }
    },
    "required": ["thread_id"]
  }
}

How will it benefit GitHub MCP Server and its users?

  • AI agents can complete PR review workflows end-to-end — after addressing review feedback, the agent can mark threads as resolved
  • Batch operations become possible — resolve multiple threads programmatically instead of manual UI clicks
  • Better integration with automated code review tools — bots like Copilot PR reviewer leave comments that could be auto-resolved once addressed

Use case

  1. AI agent reads PR review comments via get_review_comments
  2. Agent addresses the feedback (makes code changes)
  3. Agent resolves the addressed threads ← not currently possible

Additional context

The thread IDs are already returned by get_review_comments in the ID field (e.g., PRRT_kwDOE5NpvM5okADy), so no additional API calls would be needed to obtain them.

Activity

  1. plwalters commented on Jan 28, 2026

    @plwalters
    Contributor

    It looks like the referenced PR is merged but doesn't fix this yet, is the gap still a missing GraphQL mutation? From what I was reading in the PR it added the ability to resolve the thread but possibly not released yet?

  2. plwalters commented on Jan 28, 2026

    @plwalters
    Contributor

    I opened a PR if not, this would save me a lot of time manually resolving conversations, so let me know if there is anything I can do differently here. I checked the contributing info and made sure the PR checked all of the boxes.

  3. added a commit that references this issue on Feb 10, 2026
    1fdfa13
  4. added a commit that references this issue on Mar 13, 2026
    f93e526
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions