`list_dependabot_alerts` always fails with HTTP 400 — tool hardcodes `page`/`per_page`, but the Dependabot alerts endpoint requires cursor pagination

[amattas]

Describe the bug

The list_dependabot_alerts tool fails on every repository because it unconditionally appends page and per_page query parameters to the request. GitHub's "List Dependabot alerts for a repository" REST endpoint does not support page-based pagination — it uses cursor pagination (before/after/first/last) — and therefore responds with 400 Pagination using the page parameter is not supported. There is no parameter exposed on the tool to suppress page, so the tool is completely unusable for listing alerts. By contrast, list_code_scanning_alerts and list_secret_scanning_alerts work correctly.

Affected version

1.2.0

Steps to reproduce the behavior

1. Call the list_dependabot_alerts tool with only owner and repo set (no pagination arguments).
2. View the request the server generates and the API response.
3. See the error — the server appends page=1&per_page=30 and the API rejects it.

Expected vs actual behavior

Expected: the tool returns the repository's open Dependabot alerts (or an empty list), the same way list_code_scanning_alerts and list_secret_scanning_alerts do.

Actual: every call returns HTTP 400 because the server sends page/per_page, which the Dependabot alerts list endpoint does not accept. This happens even when no pagination arguments are supplied (the server defaults to page=1&per_page=30).

Likely root cause / suggested fix: the Dependabot alerts list endpoint only supports cursor pagination. The tool should use before/after/first/last and must not send page/per_page for this endpoint (or it should paginate internally via cursors).

Logs

GET https://api.github.com/repos/OWNER/REPO/dependabot/alerts?page=1&per_page=30
→ 400 Pagination using the `page` parameter is not supported. []