Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

pull_request_read: support response field filtering

Ouverte
  • Quelque chose ne va pas ?
#3,286 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
55/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
github, go
Domaine
api, backend

Piste de recherche

Commencez au point d’entrée pull_request_read et comparez le fonctionnement du filtrage des champs dans list_pull_requests et search_pull_requests. Suivez chaque méthode listée, en particulier get_reviews et get_check_runs, afin de déterminer comment les champs de réponse sont représentés et validés. Le travail est terminé lorsque les appelants peuvent demander des champs sélectionnés sans recevoir de données de payload inutiles, tout en conservant la compatibilité des appels existants.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement request ai review
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.

Langage dominant
Go
Étoiles
33.1k
Forks
5k
Merge moyen
2 j 3 h
PR mergées (30 j)
18

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de github/github-mcp-server

Toutes les issues de github/github-mcp-server

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.