Skip to content

feat(mcp): add depsight_rescan tool to trigger a repo scan from MCP#83

Merged
LanNguyenSi merged 1 commit into
masterfrom
feat/mcp-depsight-rescan
Jun 26, 2026
Merged

feat(mcp): add depsight_rescan tool to trigger a repo scan from MCP#83
LanNguyenSi merged 1 commit into
masterfrom
feat/mcp-depsight-rescan

Conversation

@LanNguyenSi

Copy link
Copy Markdown
Owner

What

The depsight MCP server was read-only — an agent couldn't close the fix → rescan → verify loop without the web UI. Adds depsight_rescan({ repoId }) that POSTs to the existing /api/scan endpoint and returns scanId + status, so the caller can then poll depsight_get_cves.

  • mcp/src/client.ts: rescan(repoId) → POST /api/scan with the same dsat_ Bearer token the read tools use.
  • mcp/src/tools/rescan.ts: depsight_rescan tool (zod repoId min(1); per-repo only — no all-repos mode).
  • mcp/src/server.ts: registers the tool.

Auth / safety (verified by reviewer)

  • /api/scan authenticates via resolveRequestUser(), which already accepts the dsat_ Bearer token identically to the read routes — zero endpoint changes needed.
  • scanRepository scopes the scan to repos owned + tracked by the token's user → no cross-user IDOR.

Tests

  • Client: path/method/Bearer/body + 401/400/500 → HttpError.
  • Tool wrapper: success-envelope mapping, status/dependabotDisabled defaulting, and HttpErrorisError result.
  • tsc build clean, 28/28 mcp tests green.

Out of scope → follow-up (task 5e9a27bc)

Reviewer noted two pre-existing backend behaviors the tool merely relays: access-denied returns 500 (not 403/404), and there's no already-running scan guard. Both filed as a follow-up; not touched here.

Note: a version bump/publish of @opentriologue/depsight-mcp is left to the release process (the running MCP server picks up the new tool on restart).

Refs: task bbbc70b1

The depsight MCP server was read-only, so an agent could not close the
fix -> rescan -> verify loop without the web UI. Add depsight_rescan({repoId})
which POSTs to the existing /api/scan endpoint with the same dsat_ Bearer
token the read tools use (resolveRequestUser already accepts it server-side,
and scanRepository scopes the scan to the token user's own repos), returning
scanId + status so the caller can then poll depsight_get_cves.

Tests cover the client (path/method/Bearer/body + 401/400/500 -> HttpError)
and the tool wrapper (success envelope, status/dependabotDisabled defaulting,
and HttpError -> isError mapping).

Out of scope, filed as follow-up (task 5e9a27bc): access-denied currently
returns 500 instead of 403/404, and there is no already-running scan guard.

Refs: task bbbc70b1

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@LanNguyenSi LanNguyenSi merged commit 48b2bbb into master Jun 26, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants