dependabot-alerts.mjs's openAlerts() has no error handling for a rate-limited or partially-failed GitHub API response

Which version line?

v2 — current (@modelcontextprotocol/inspector@latest)

Which client?

All / shared core

Inspector version

2.7.0 (git tag) — static code-review finding, not run locally

Node version

N/A — static code review, no live run performed

Operating system (and browser, for the web client)

N/A — static code review

Transport

Not applicable / never connected

MCP server under inspection

N/A — this is a static code-review finding against the 2.7.0 tag's scripts/dependabot-alerts.mjs, not a live reproduction against a running MCP server.

Steps to reproduce

Found via static review of the 2.7.0 tag source, not a live run.

1. scripts/dependabot-alerts.mjs's isPermissionDenied() (~line 737) explicitly detects and handles rate-limiting for the "is Dependabot security-fixes enabled" check, and main() has a test covering "continues, reporting UNVERIFIED, when the token cannot read the setting."
2. The actual alert-listing function, openAlerts() (~lines 797-805), calls gh api --paginate --slurp repos/${repo}/dependabot/alerts?state=open&per_page=100 with no try/catch or equivalent handling around that call, unlike the permission-check path.
3. A repo-wide read of the co-located scripts/dependabot-alerts.test.mjs finds tests for the permission-check rate-limit path but no negative-path test exercising openAlerts() itself against a rate-limited (403/429) or partially-failed (paginated request cut off mid-stream) GitHub API response.
   No live run against the GitHub API was performed; this is based on reading the script and its test file against the 2.7.0 tag.

Expected behavior

openAlerts() handles a rate-limited (403/429) or partially-failed paginated response from the GitHub API the same deliberate way isPermissionDenied() already handles rate-limiting for the security-fixes-setting check — either surfacing a clear, non-crashing error/UNVERIFIED result, or retrying — rather than letting an unhandled exception propagate out of gh api.

Actual behavior

openAlerts() calls gh api --paginate --slurp repos/${repo}/dependabot/alerts?state=open&per_page=100 with no try/catch and no test covering what happens when that call is rate-limited or fails partway through a paginated response — in contrast to the permission-check path a few functions away, which explicitly detects and handles rate-limiting (isPermissionDenied(), covered by tests at lines 234-253 of the test file).

Suggested fix: wrap openAlerts()'s gh api call in the same kind of error handling as the permission-check path (detect rate-limit/partial-failure, surface a clear error or retry), and add a negative-path test for it alongside the existing rate-limit test for isPermissionDenied().

Logs, errors, or screenshots

No response

Already prototyped a fix?

No response

Before you submit

• I searched existing issues and this is not a duplicate.
• This is not a security vulnerability report (those go through the private advisory process).

Start with openAlerts() in scripts/dependabot-alerts.mjs and compare its gh api call with isPermissionDenied() and the existing handling. Run scripts/dependabot-alerts.test.mjs, then add coverage for rate-limited and partially failed paginated responses. Done means failures are handled deliberately without an unhandled exception and the negative-path tests pass.