feat: add pagination to list GHAS alerts tools#2451
Open
dvirarad wants to merge 9 commits into
Open
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adds standard REST pagination support to the GHAS repository-level “list alerts” MCP tools so callers can retrieve more than the first 30 alerts returned by default from GitHub’s APIs (fixing the truncation problem described in #2363).
Changes:
- Exposes
pageandperPageinputs forlist_code_scanning_alerts,list_dependabot_alerts, andlist_secret_scanning_alertsviaWithPagination(...). - Wires
OptionalPaginationParams(args)into each tool handler and forwardsgithub.ListOptions{Page, PerPage}to go-github request options. - Updates unit tests and regenerates tool schema snapshots to reflect default and custom pagination behavior.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| pkg/github/code_scanning.go | Adds paginated input schema and forwards ListOptions to the Code Scanning list-alerts API call. |
| pkg/github/code_scanning_test.go | Updates query-param expectations for default pagination and adds a custom pagination test; asserts schema now contains page/perPage. |
| pkg/github/dependabot.go | Adds paginated input schema and forwards ListOptions to the Dependabot list-alerts API call. |
| pkg/github/dependabot_test.go | Updates query-param expectations for default pagination and adds a custom pagination test. |
| pkg/github/secret_scanning.go | Adds paginated input schema and forwards ListOptions to the Secret Scanning list-alerts API call. |
| pkg/github/secret_scanning_test.go | Updates query-param expectations for default pagination and adds a custom pagination test. |
| pkg/github/toolsnaps/list_code_scanning_alerts.snap | Snapshot updated to include page and perPage inputs. |
| pkg/github/toolsnaps/list_dependabot_alerts.snap | Snapshot updated to include page and perPage inputs. |
| pkg/github/toolsnaps/list_secret_scanning_alerts.snap | Snapshot updated to include page and perPage inputs. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2363.
Why
The three GHAS list-alerts tools —
list_code_scanning_alerts,list_dependabot_alerts,list_secret_scanning_alerts— currently sendGETwith nopage/per_pagequery parameters, so the API returns at most 30 alerts and there is no way to fetch the rest. As @rwjblue-glitch notes in the issue, this gives AI tooling a false sense of security: it sees 30 alerts and reports "these are the alerts," when the underlying repo may have hundreds.The issue reproduces with prompts like "generate a CSV with ALL code scanning alerts" — the model uses
list_code_scanning_alerts, gets 30 rows, writes them out, and never knows it was truncated.Underlying go-github types (
AlertListOptions,ListAlertsOptions,SecretScanningAlertListOptions) already embedListOptions, so this is a small wiring change that matches whatissue_read,list_issues, etc. already do viaWithPagination/OptionalPaginationParams.What
pkg/github/code_scanning.go,pkg/github/dependabot.go,pkg/github/secret_scanning.go— for each list tool:schemavariable and callWithPagination(schema)so the tool exposespageandperPage(matching the existing convention, e.g.issues.goline 235).OptionalPaginationParams(args)and populateListOptions{Page, PerPage}on the respective options struct.No new helpers; no API changes beyond two new optional input fields per tool;
secret_scanning.SecretScanningAlertListOptionsalso embedsListCursorOptionsbut go-github documents that REST Enterprise Cloud and.comboth honorpagefromListOptions, which is the existing convention in this repo for paginated list tools.Tests
pkg/github/code_scanning_test.go,pkg/github/dependabot_test.go,pkg/github/secret_scanning_test.go:expectQueryParamsmaps to include the new defaults ("page": "1","per_page": "30").successful alerts listing with custom paginationcase per tool that assertspage=2/page=3andper_page=50/per_page=100propagate to the upstream request.assert.Contains(t, schema.Properties, "page")/"perPage"to the schema-shape assertions in the code-scanning test (matches existing style there).pkg/github/__toolsnaps__/list_*.snapregenerated to includepageandperPage(matches the format used by every otherWithPaginationtool, e.g.issue_read.snap).Out of scope
list_*_alerts_for_organdlist_*_alerts_for_enterprise(if/when added) would benefit from the same treatment; this PR keeps the change focused on the three repo-level list tools called out in Pagination on GHAS list_* endpoints #2363.Checklist
pageandperPageare optional with documented defaults).