Expose issue/PR timeline events (incl. `review_requested` timestamps)

オープン
#3,301 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
68/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go
領域
api, tooling

調査の方向性

Start by reading the existing pull_request_read and issue_read tool entry points and how they call GitHub's Timeline endpoint. Implement a read-only timeline capability with pagination, optional event filtering, and the requested event fields; done means callers can identify review request and re-request timestamps.

索引モデルが issue の本文から書いたものです。

説明

enhancement request ai review
Describe the feature or problem you'd like to solve

There's currently no tool in the GitHub MCP server to read an issue's or pull request's timeline events. That means an agent can't tell when a review was requested (or re-requested) on a PR.

The data exists: GitHub shows it in the PR UI, and the REST API returns it via the Timeline endpoint (GET /repos/{owner}/{repo}/issues/{issue_number}/timeline) as review_requested / review_request_removed events with created_at, requested_reviewer and review_requester. None of the current tools expose it.

We hit this building a review-tracking agent in our project management system, which talks to GitHub only through this MCP server. The agent has to figure out which PRs are waiting on a re-review, meaning the author re-requested review after the reviewer's last review. Without the request timestamp it can't reliably tell a re-review apart from a stale PR.

Proposed solution

Add a read-only tool, e.g. list_issue_timeline_events (or get_pull_request_timeline), that wraps the Timeline endpoint:

  • Inputs: owner, repo, issue_number / pullNumber, optional event_types filter (e.g. ["review_requested", "review_request_removed"]), plus standard pagination
  • Output: event type, created_at, actor, and event-specific fields (requested_reviewer / requested_team, review_requester)

Another option is to add a timeline method to the existing pull_request_read / issue_read tools.

Benefit: agents can reason about when things happened on a PR/issue, not just its current state. Review SLAs, re-review detection and reviewer workload reporting all depend on this. It's read-only, so it fits the existing permission model.

主要言語
Go
スター
33.1k
フォーク
5k
平均マージ
2日 15時間
マージ済み PR(30日)
27

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

github/github-mcp-server のほかの issue

github/github-mcp-server の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。