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).