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

まず既存の pull_request_read と get_review_comments の動作を読み、その後、script/generate-docs と toolsnap の更新に関するリポジトリの規約を確認します。PR 数の上限と、存在しない PR または 404 の PR に対する動作を定義して文書化し、テストを追加して、生成されたドキュメントまたは toolsnap アーティファクトを更新します。明示的なリストのバッチ動作がテストされ、文書化されていれば完了です。

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): https://github.com/github/github-mcp-server/issues/1323
• Copilot suggestion changesets not in API (platform/API gap): https://github.com/github/github-mcp-server/issues/2235
• Companion (batch PR metadata for changelogs): https://github.com/github/github-mcp-server/issues/2302

Note

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