Feature request: batch-fetch pull request review comment threads for an explicit PR list

[Varshini-M]

Problem

Today, pulling inline review threads for multiple PRs means N separate pull_request_read calls (get_review_comments per PR). For agent workflows (team playbooks, review digests, distilling recurring conventions into docs or rules), that is slow, error-prone, and uses more API round-trips than necessary.

Proposed solution (v1)

Add a tool (name up to maintainers) that accepts:

• owner, repo
• pull_numbers: array of integers (bounded, e.g. configurable max such as 20–50)
• Optional pagination parameters consistent with existing get_review_comments behavior

Behavior: For each PR number, return the same structured data as today’s per-PR get_review_comments (threads + metadata such as resolved/outdated), keyed by pull_number.

Explicit non-goals (v1):

• No semantic ranking, clustering, or “top comments” inside the server.
• No implicit full-repo scan; the caller supplies an explicit list (e.g. from search_pull_requests / list_pull_requests / git).

Why this matters

• Documents a single supported pattern for agents: select PRs → one batch read → summarize offline.
• Reduces N+1 calls for engineering hygiene (guidelines derived from real review text).

Acceptance criteria (suggestion)

• Documented max PR count and behavior for missing/404 PRs (partial success vs fail-all—pick one and document).
• Tests + script/generate-docs / toolsnap updates per repo conventions.

Related issues

• Reply to review comments (still one thread at a time today): Add ability to reply to individual pull request review comments #1323
• Copilot suggestion changesets not in API (platform/API gap): Copilot-generated PR review code suggestions ("Suggest" changesets) are not returned by pull_request_read or any API #2235
• Companion (batch PR metadata for changelogs): Feature request: batch-fetch merged PR metadata for release notes / changelog generation #2302

Note

We are happy to prototype a PR if maintainers agree on v1 scope (explicit pull_numbers[], caps, and error semantics).