Why
KShield's value today is gated behind the git pre-commit hook. AI coding agents (Claude Code, Cursor, etc.) can't call the scan engine directly mid-session — they only see results after a commit is blocked. An MCP server would expose the existing local backend as callable tools, letting an agent check code for secrets/access-control issues/hallucinated deps before writing more code, not just at commit time.
Proposed scope
- New package, e.g.
mcp-server/ (Node, using the official MCP SDK), acting as a thin proxy over the existing FastAPI backend — no engine logic duplicated.
- Tools to expose:
kshield_scan(filename, content) → wraps POST /api/v1/scan
kshield_history(limit) → wraps GET /api/v1/scans
kshield_suppress(rule_type, justification) → wraps POST /api/v1/actions/suppress
- Needs a decision on backend lifecycle: should the MCP server auto-spawn
kshield-backend if not already running, or fail fast with a clear "run kshield init" message? Leaning toward fail-fast for v1 to avoid managing a child process.
- Package for both npm (
npx kshield-mcp) and inclusion in the existing CLI distribution channels (homebrew/pip) as a follow-up.
Out of scope for v1
- Auto-remediation via the agent (
apply-patch endpoint) — revisit once read-only scanning is solid.
Why
KShield's value today is gated behind the git pre-commit hook. AI coding agents (Claude Code, Cursor, etc.) can't call the scan engine directly mid-session — they only see results after a commit is blocked. An MCP server would expose the existing local backend as callable tools, letting an agent check code for secrets/access-control issues/hallucinated deps before writing more code, not just at commit time.
Proposed scope
mcp-server/(Node, using the official MCP SDK), acting as a thin proxy over the existing FastAPI backend — no engine logic duplicated.kshield_scan(filename, content)→ wrapsPOST /api/v1/scankshield_history(limit)→ wrapsGET /api/v1/scanskshield_suppress(rule_type, justification)→ wrapsPOST /api/v1/actions/suppresskshield-backendif not already running, or fail fast with a clear "runkshield init" message? Leaning toward fail-fast for v1 to avoid managing a child process.npx kshield-mcp) and inclusion in the existing CLI distribution channels (homebrew/pip) as a follow-up.Out of scope for v1
apply-patchendpoint) — revisit once read-only scanning is solid.