Describe the feature or problem you’d like to solve
list_pull_requests and search_pull_requests both support a fields parameter to trim response size to only what the caller needs. pull_request_read has no equivalent for any of its methods (get, get_diff, get_status, get_files, get_commits, get_review_comments, get_reviews, get_comments, get_check_runs) — every call always returns the full, maximally verbose payload.
This is a significant problem for get_reviews and get_check_runs specifically:
get_reviews returns the full review body for every review, even when the caller only needs state and user.login to compute a review decision. Bot-generated reviews (e.g. Copilot code review) can each be several KB of markdown.
get_check_runs returns a fully itemized list of every check run (name, URL, timestamps, etc.) even when the caller only needs an overall pass/fail signal — get_status already provides that more cheaply, but doesn't help when a specific failing check's name is needed.
In practice, this forces callers who just want a compact per-PR summary (review decision + CI status) into fetching and carrying far more data than necessary.
Proposed solution
Add a fields (or select) parameter to pull_request_read, consistent with the existing pattern on list_pull_requests/search_pull_requests:
- For
get_reviews: allow selecting a subset of {id, state, user, submitted_at, body} per review, defaulting to omit body.
- For
get_check_runs: allow a fields filter over per-check fields (name, conclusion, url, timestamps, etc.).
This lets callers request only the compact signals they need, keeping response size proportional to what's actually useful — the same benefit fields already provides on list_pull_requests and search_pull_requests.
Example prompts or workflows (for tools/toolsets only)
- "Summarize the review and CI status of every open PR across these 7 repositories" — an agent lists PRs per repo, then for each PR calls
pull_request_read with method: get_reviews, fields: [state, user] and method: get_check_runs, fields: [name, conclusion] to build a compact status table, instead of ingesting full review bodies and full check-run details it never uses.
- Any dashboard/digest/reporting tool that needs "is this PR approved and green?" for many PRs at once, without paying the cost of full review text and full check-run metadata per PR.
- Bulk PR triage workflows that classify PRs into buckets (needs review / blocked / ready to merge / stale) based only on review state and CI pass/fail, run across many repositories in a single pass.
Additional context
We hit this concretely in an automation agent that summarizes open PRs across several repositories into a digest: listing PRs, then calling get_reviews + get_check_runs per PR to classify each one, accumulated roughly 660KB of conversation context across ~110 tool calls (full unfiltered payloads for each call). The agent's next step then timed out entirely before producing any output. A single compact call per repository via GitHub CLI's gh pr list --json reviewDecision,statusCheckRollup,... returns equivalent information in a fraction of the size, precisely because it lets the caller select only the fields it needs — the same capability pull_request_read is missing.
Describe the feature or problem you’d like to solve
list_pull_requestsandsearch_pull_requestsboth support afieldsparameter to trim response size to only what the caller needs.pull_request_readhas no equivalent for any of its methods (get,get_diff,get_status,get_files,get_commits,get_review_comments,get_reviews,get_comments,get_check_runs) — every call always returns the full, maximally verbose payload.This is a significant problem for
get_reviewsandget_check_runsspecifically:get_reviewsreturns the full reviewbodyfor every review, even when the caller only needsstateanduser.loginto compute a review decision. Bot-generated reviews (e.g. Copilot code review) can each be several KB of markdown.get_check_runsreturns a fully itemized list of every check run (name, URL, timestamps, etc.) even when the caller only needs an overall pass/fail signal —get_statusalready provides that more cheaply, but doesn't help when a specific failing check's name is needed.In practice, this forces callers who just want a compact per-PR summary (review decision + CI status) into fetching and carrying far more data than necessary.
Proposed solution
Add a
fields(orselect) parameter topull_request_read, consistent with the existing pattern onlist_pull_requests/search_pull_requests:get_reviews: allow selecting a subset of{id, state, user, submitted_at, body}per review, defaulting to omitbody.get_check_runs: allow afieldsfilter over per-check fields (name, conclusion, url, timestamps, etc.).This lets callers request only the compact signals they need, keeping response size proportional to what's actually useful — the same benefit
fieldsalready provides onlist_pull_requestsandsearch_pull_requests.Example prompts or workflows (for tools/toolsets only)
pull_request_readwithmethod: get_reviews, fields: [state, user]andmethod: get_check_runs, fields: [name, conclusion]to build a compact status table, instead of ingesting full review bodies and full check-run details it never uses.Additional context
We hit this concretely in an automation agent that summarizes open PRs across several repositories into a digest: listing PRs, then calling
get_reviews+get_check_runsper PR to classify each one, accumulated roughly 660KB of conversation context across ~110 tool calls (full unfiltered payloads for each call). The agent's next step then timed out entirely before producing any output. A single compact call per repository via GitHub CLI'sgh pr list --json reviewDecision,statusCheckRollup,...returns equivalent information in a fraction of the size, precisely because it lets the caller select only the fields it needs — the same capabilitypull_request_readis missing.