Skip to content

pull_request_read: support response field filtering #3286

Description

@noirbizarre

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions