Skill analysis: persistent 503 from /hidden/mcp-scan analysis endpoint (0.5.15 and 0.5.16)

[neeohh]

Every skill analysis fails with Could not reach analysis server: 503 - Service Unavailable, consistently since 2026-08-03, across both 0.5.15 and 0.5.16. MCP-server analysis on the same run and the same token is unaffected.

Symptom

A full scan returns analysis_error for 100% of skill entities:

280 analysis_error  | Could not reach analysis server: 503 - Service Unavailable
 11 user_declined   | stdio server not started
  8 server_startup  | could not start server

--no-skills on the same host completes cleanly with zero errors, so the failure is isolated to the skill-analysis path.

Diagnostics already done

• Reproduced 5 times over ~6 hours, plus an earlier occurrence on 2026-08-03 (273 skills, same error).
• Client is current: 0.5.16 is the released stable version.
• Token is valid: GET https://api.snyk.io/rest/openapi returns 200 with the same credential.
• Not auth: 503 rather than 401/403.
• status.snyk.io reported all systems operational throughout.
• The scanner logs the endpoint as api.snyk.io/hidden/mcp-scan/.... Since that path returns 503 while adjacent paths return 404 from the same gateway, the route appears to exist with an unavailable upstream.

Question

Is skill analysis expected to be generally available on this endpoint, or is it gated (entitlement/rollout) in a way that surfaces as 503 rather than 401/403/404? A distinguishable status or error body would make this diagnosable without guessing.

Environment: macOS, snyk-agent-scan 0.5.16 (Homebrew), ~280 skills, ~19 MCP servers.

[neeohh]

Correction / important additional data: the 503 appears to be volume-dependent, not a flat outage. Three runs on the same host with the same token, minutes apart:

flags	analysed OK	failed (503)
--no-skills --dangerously-run-mcp-servers	13	0
--skills --dangerously-run-mcp-servers	0	291
--skills (servers declined)	0	280

A small burst (13 analyses) succeeds completely. A large burst (~291) fails completely, and it takes the MCP-server analyses down with it — the 291 is 280 skills plus the 11 servers that only declined in the earlier run.

So this reads more like a rate limit, concurrency cap, or quota surfacing as 503 than an unavailable backend. Two consequences worth flagging:

1. Enabling --skills on a host with a few hundred skills does not merely lose skill coverage, it also destroys MCP-server coverage in the same run, because both share the request burst.
2. A 429 with Retry-After, or client-side batching/backoff, would make this self-correcting. As it stands the failure is indistinguishable from an outage, which is what sent me looking at your status page first.

Host has ~280 skills (34 user + ~450 plugin SKILL.md, 280 analysed) and ~19 MCP servers.