Loading ToolBench
MCP server that audits AI-generated code using real-attacker techniques, then fixes only the items you check.
claude-guard has 9 tools with complete input schemas and descriptions, but quality is uneven. Naming is strong (verb-first: scan, list_findings, explain, apply_fixes, rollback, redteam_probe, init, init_config, list_checks). Descriptions are present but often lack actionable context for LLM selection, e.g., 'Scan a project for security findings' doesn't explain WHEN to call scan vs redteam_probe, or what prerequisites exist. Parameters are typed and mostly described, but several lack constraint details (e.g., 'project_path' has no format guidance; 'mode' enum in apply_fixes lacks explanation of when to use each). Output schemas are not documented, LLMs cannot predict what scan() or apply_fixes() returns, forcing them to guess downstream field names. Error handling is absent from descriptions; no guidance on retryability or recovery paths. Security-sensitive tools (apply_fixes, rollback) lack permission/confirmation patterns. Composition is reasonable, tools chain logically (scan → list_findings → apply_fixes → rollback), but missing idempotency guarantees and batch variants.
Apply AST-backed safe fixes for items checked in .claude-guard/findings.md. Writes a fix branch to .claude-guard/fixes/<fix_id>/ and a rollback script.
Explain a specific finding: rule rationale, attack scenario, PoC payload, and fix guidance.
Initialize a .claude-guard directory in the project with default config and rules.
Write a default claude-guard.yml config file to the project.
List all available security checks (rules) that claude-guard can run.
Render a checkbox markdown view of the latest scan to .claude-guard/findings.md. Toggle [x] on items you want fixed, then call apply_fixes.
Run a red-team probe against a live target to verify a finding is exploitable. Requires a running server and network access to the target.
Output schemas not documented. LLMs cannot predict return types for scan(), apply_fixes(), or explain(). Descriptions mention 'Writes findings to .claude-guard/scans/<scan_id>/findings.json' but do not specify the JSON structure, field names, or types returned to the agent.
Descriptions lack WHEN/WHY context. 'Scan a project for security findings' does not explain when to call scan vs redteam_probe, what layers do, or prerequisites (e.g., 'requires semgrep/gitleaks on PATH for L1'). LLMs cannot disambiguate tool selection.
Parameter constraints missing. 'project_path' has no format guidance (absolute vs relative? must exist?). 'mode' enum in apply_fixes lacks explanation of when to use 'checked' vs 'all_safe' vs 'dry_run'. 'severity' enum in list_findings lacks ordering or impact guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Rollback a fix branch by restoring the original files from the scan artifact.
Scan a project for security findings. L1 orchestrates external tools if they are on PATH (semgrep, gitleaks). L2 runs the built-in YAML rules. The red-team probe is a separate opt-in tool (redteam_probe), not a scan layer. Writes findings to .claude-guard/scans/<scan_id>/findings.json.
Destructive operations lack confirmation/dry-run patterns. apply_fixes and rollback modify the filesystem but have no built-in confirmation step or mandatory dry_run preview. Agents can accidentally apply unsafe fixes without review.
Error handling not documented. No guidance on retryability, recovery paths, or actionable error messages. E.g., if scan fails due to missing semgrep, the description does not say 'Install semgrep or use layers=["l2"] for built-in rules only'.