Security alert list tools return inconsistent JSON response shapes

[LurigeLars]

Describe the bug

The security alert list tools expose inconsistent JSON response shapes.

list_code_scanning_alerts and list_secret_scanning_alerts return their text payload as a bare JSON array:

[{"number":274,"rule":{"id":"py/unused-import"}}]

while list_dependabot_alerts returns an object:

{"alerts":[{"number":16}],"pageInfo":{"hasNextPage":false,"hasPreviousPage":false}}

This makes closely related security-list tools difficult to consume uniformly and can cause a client to interpret real findings as an empty result when it expects the Dependabot-style alerts property.

The implementation difference appears to be:

• pkg/github/code_scanning.go marshals alerts directly
• pkg/github/secret_scanning.go marshals alerts directly
• pkg/github/dependabot.go builds an object containing Alerts and PageInfo

Affected version

v1.14.0

Steps to reproduce the behavior

1. Call list_code_scanning_alerts for a repository with an open finding.
2. Observe that the text payload is a bare JSON array.
3. Call list_secret_scanning_alerts and observe the same shape.
4. Call list_dependabot_alerts and observe { "alerts": [...], "pageInfo": {...} } instead.

We reproduced this during a repository-wide Security & Quality audit. A real open CodeQL finding was present in the returned array but was initially missed by a consumer expecting the Dependabot response shape.

Expected vs actual behavior

Expected: the related security alert list tools expose a consistent top-level contract, preferably { "alerts": [...], "pageInfo": {...} } where pagination metadata applies.

Actual: Code Scanning and Secret Scanning return bare arrays, while Dependabot returns an object.

If the difference is intentional, documenting it explicitly would also help clients avoid incorrect assumptions.

Logs

No server error is produced; this is a response-shape inconsistency.

We currently normalize the two bare-array responses in a local compatibility gateway, but an upstream-consistent contract would remove the need for that workaround.