Describe the bug
Since #2451 (merged 2026-05-20), list_dependabot_alerts always returns:
400 Pagination using the `page` parameter is not supported
The tool is effectively unusable — any call fails, regardless of arguments, because the handler unconditionally sends page=1.
The GitHub Dependabot alerts REST API (GET /repos/{owner}/{repo}/dependabot/alerts) does not support page-based pagination. It only supports cursor-based pagination (before / after). Sending a page query parameter is rejected with a 400.
Root cause
#2451 wired all three GHAS list tools to the page-based helper OptionalPaginationParams, which defaults page to 1:
// pkg/github/params.go
func OptionalPaginationParams(args map[string]any) (PaginationParams, error) {
page, err := OptionalIntParamWithDefault(args, "page", 1) // <- always 1 by default
...
}
pkg/github/dependabot.go then puts that on the request options unconditionally:
pagination, err := OptionalPaginationParams(args)
...
ListOptions: github.ListOptions{
Page: pagination.Page, // = 1 -> sent as ?page=1 -> 400
PerPage: pagination.PerPage,
},
So a page query param is sent on every call, which the Dependabot alerts endpoint rejects.
This is correct for list_code_scanning_alerts (that endpoint does support page), which is likely why it slipped through review — only one of the three endpoints in the PR is cursor-only.
The codebase already has the right helper for this case, in the same file:
// pkg/github/params.go
// OptionalCursorPaginationParams returns the "perPage" and "after" parameters,
// without the "page" parameter, suitable for cursor-based pagination only.
func OptionalCursorPaginationParams(args map[string]any) (CursorPaginationParams, error) { ... }
Suggested fix
Switch list_dependabot_alerts from page-based to cursor-based pagination:
- Use
WithCursorPagination(schema) instead of WithPagination(schema) so the tool exposes perPage / after but not page.
- In the handler, use
OptionalCursorPaginationParams(args) and populate only PerPage and After on github.AlertListOptions (do not set Page).
secret_scanning.go should be audited too — the secret scanning alerts API is likewise cursor-based and may have the same regression.
Why tests didn't catch it
dependabot_test.go mocks the GitHub API and happily returns data for page=1, so the real 400 from the live endpoint never surfaces in CI. A test that asserts no page query parameter is sent (or a mock that 400s on page) would have caught it.
Steps to reproduce
- Call
list_dependabot_alerts with any args, e.g. { "owner": "<org>", "repo": "<repo>", "state": "fixed" }.
- Observe:
400 Pagination using the page parameter is not supported.
Workaround
Use the REST API directly, which negotiates cursor pagination correctly:
gh api repos/{owner}/{repo}/dependabot/alerts --paginate -f state=fixed
Affected version
Remote/hosted MCP server, and any build including #2451 (merged 2026-05-20).
References
Describe the bug
Since #2451 (merged 2026-05-20),
list_dependabot_alertsalways returns:The tool is effectively unusable — any call fails, regardless of arguments, because the handler unconditionally sends
page=1.The GitHub Dependabot alerts REST API (
GET /repos/{owner}/{repo}/dependabot/alerts) does not support page-based pagination. It only supports cursor-based pagination (before/after). Sending apagequery parameter is rejected with a 400.Root cause
#2451 wired all three GHAS list tools to the page-based helper
OptionalPaginationParams, which defaultspageto1:pkg/github/dependabot.gothen puts that on the request options unconditionally:So a
pagequery param is sent on every call, which the Dependabot alerts endpoint rejects.This is correct for
list_code_scanning_alerts(that endpoint does supportpage), which is likely why it slipped through review — only one of the three endpoints in the PR is cursor-only.The codebase already has the right helper for this case, in the same file:
Suggested fix
Switch
list_dependabot_alertsfrom page-based to cursor-based pagination:WithCursorPagination(schema)instead ofWithPagination(schema)so the tool exposesperPage/afterbut notpage.OptionalCursorPaginationParams(args)and populate onlyPerPageandAfterongithub.AlertListOptions(do not setPage).secret_scanning.goshould be audited too — the secret scanning alerts API is likewise cursor-based and may have the same regression.Why tests didn't catch it
dependabot_test.gomocks the GitHub API and happily returns data forpage=1, so the real 400 from the live endpoint never surfaces in CI. A test that asserts nopagequery parameter is sent (or a mock that 400s onpage) would have caught it.Steps to reproduce
list_dependabot_alertswith any args, e.g.{ "owner": "<org>", "repo": "<repo>", "state": "fixed" }.400 Pagination using the page parameter is not supported.Workaround
Use the REST API directly, which negotiates cursor pagination correctly:
gh api repos/{owner}/{repo}/dependabot/alerts --paginate -f state=fixedAffected version
Remote/hosted MCP server, and any build including #2451 (merged 2026-05-20).
References