Describe the feature or problem you’d like to solve
list_pull_requests and search_pull_requests return rich per-PR metadata (state, draft, mergeable_state, timestamps, etc.) but neither exposes the PR's review decision (approved / changes requested / review required) or its combined CI/check status. Getting either today requires a separate pull_request_read call per PR (method: get_reviews and/or get_status), which doesn't scale: summarizing N open PRs costs one bulk listing call plus up to 2×N follow-up calls.
Proposed solution
Add optional fields to list_pull_requests's (and search_pull_requests's) fields allow-list:
review_decision: the PR's overall review decision (APPROVED, CHANGES_REQUESTED, REVIEW_REQUIRED, or null) — equivalent to GitHub's GraphQL reviewDecision field, already used by gh pr list --json reviewDecision.status_check_rollup (or similar): the combined CI/check status for the PR's head commit — equivalent to GitHub's GraphQL statusCheckRollup field, already used by gh pr list --json statusCheckRollup.
With these available, a single list_pull_requests call per repository would be enough to classify PRs into buckets like "needs review", "blocked/CI failing", "approved and green", etc. — removing the need for any per-PR follow-up call in the common case.
Example prompts or workflows (for tools/toolsets only)
- "Give me a one-table summary of every open PR across these repos: link, title, review status, CI status" — currently requires 1 + 2N calls; with these fields, a single
list_pull_requests call per repo would suffice.
- Daily/weekly PR digest bots that bucket PRs into categories (needs review / blocked / ready to merge / stale) across many repositories.
- Dashboards needing an at-a-glance "is this PR green and approved?" signal for a large PR backlog without pulling full review/check-run detail for each one.
Additional context
This mirrors what GitHub's own CLI (gh pr list --json reviewDecision,statusCheckRollup,...) already exposes in one compact call per repo. An automation agent using only the current MCP tools had to make one list_pull_requests call plus 2 pull_request_read calls per PR just to get this same information, and the resulting accumulated context (~215KB across ~80 calls for 36 PRs) was enough to make the agent's next reasoning step time out. Exposing these two fields directly on the listing/search tools would remove the need for that fan-out entirely for this class of use case.
Describe the feature or problem you’d like to solve
list_pull_requestsandsearch_pull_requestsreturn rich per-PR metadata (state, draft, mergeable_state, timestamps, etc.) but neither exposes the PR's review decision (approved / changes requested / review required) or its combined CI/check status. Getting either today requires a separatepull_request_readcall per PR (method: get_reviewsand/orget_status), which doesn't scale: summarizing N open PRs costs one bulk listing call plus up to 2×N follow-up calls.Proposed solution
Add optional fields to
list_pull_requests's (andsearch_pull_requests's)fieldsallow-list:review_decision: the PR's overall review decision (APPROVED,CHANGES_REQUESTED,REVIEW_REQUIRED, ornull) — equivalent to GitHub's GraphQLreviewDecisionfield, already used bygh pr list --json reviewDecision.status_check_rollup(or similar): the combined CI/check status for the PR's head commit — equivalent to GitHub's GraphQLstatusCheckRollupfield, already used bygh pr list --json statusCheckRollup.With these available, a single
list_pull_requestscall per repository would be enough to classify PRs into buckets like "needs review", "blocked/CI failing", "approved and green", etc. — removing the need for any per-PR follow-up call in the common case.Example prompts or workflows (for tools/toolsets only)
list_pull_requestscall per repo would suffice.Additional context
This mirrors what GitHub's own CLI (
gh pr list --json reviewDecision,statusCheckRollup,...) already exposes in one compact call per repo. An automation agent using only the current MCP tools had to make onelist_pull_requestscall plus 2pull_request_readcalls per PR just to get this same information, and the resulting accumulated context (~215KB across ~80 calls for 36 PRs) was enough to make the agent's next reasoning step time out. Exposing these two fields directly on the listing/search tools would remove the need for that fan-out entirely for this class of use case.