2026-08-29
MCP server 0.2.0 migration guide
propose_fix and apply_fix now require an explicit scan_id argument. The other three tools are unchanged. This page walks through what changed, why, and how to upgrade.
What changed
As of @security-scanner/mcp-server@0.2.0, the two tools that fix a finding — propose_fix and apply_fix — take scan_id as a required UUID argument. The MCP server no longer tracks the most recent scan per process.
scan_target, get_scan_status, and list_findings are unchanged. scan_id was already a required arg on those three; this change just extends the same contract to the fix tools.
Why we made this change
The previous MCP server kept a module-level currentScanId global. In hosted SSE mode (one server, many concurrent users), one user's list_findings could overwrite another's scan context — their next propose_fix would then route to the wrong scan.
That bug was a wrong-scan route, not a cross-user data read. But a multi-tenant server relying on process-level state is a footgun we wanted to remove. The fix: make every tool take the scan it needs as an explicit argument, the same way get_scan_status already did.
Who is affected
- Anyone whose AI editor calls
propose_fixorapply_fixwithout passingscan_id. The call will now fail with a Zod validation error. - Anyone who copy-pasted the old quickstart or blog-post examples. Those examples showed
propose_fix <finding_id>; the new contract ispropose_fix <scan_id> <finding_id>. - Anyone with a custom agent prompt that omitted
scan_id. Update the prompt.
stdio users (Cursor, Claude Code, Windsurf) were largely fine if they were already passing scan_id from thescan_target response. Hosted SSE users on mcp.inscan.space were the most affected.
How to upgrade
Pull the new version of the MCP server:
npx -y @security-scanner/mcp-server@0.2.0Then update the calls in your AI editor's prompts or scripts:
Before (no longer works):
propose_fix <finding_id>
apply_fix <finding_id>After:
propose_fix <scan_id> <finding_id>
apply_fix <scan_id> <finding_id>scan_id is the UUID returned by scan_target and surfaced in list_findings output. Your AI editor already has it — it just needs to thread it through.
FAQ
Will my existing scripts break?
Yes, until you pass scan_id. The error will look like ZodError: invalid_type at scan_id; expected string, received undefined. Add scan_id as the first arg.
What about Pro/Business tier gates?
Unchanged. propose_fix still requires Pro+; apply_fix still requires Business+.
What about the hosted SSE server at mcp.inscan.space?
Same contract. Hosted SSE was the most-affected surface for the original bug, so the fix is identical there.
Next steps
- Quickstart
- Tools reference
- CHANGELOG (on the standalone repo, when it's public)