01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100→100, token cost down 1%, unconfirmed writes 0%→0%.
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
29.0 / 30
03Economics
12.4 / 20
04Discoverability
11.4 / 20
Highest-impact fix
Estimated gain +30 pointsAdd explicit identity and permission preflight tools
Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
Defects and rewrites.
1 defect found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
codeinspectus_rescan |
params_unexplained |
Re-run a scan after fixes were applied and diff the results against a prior scan_id (default: the most recent scan of the same path). Reports which findings are resolved, which remain, and which were newly introduced, plus fresh technology and native-pack execution coverage. Use to verify fixes. path: absolute path to the repository or directory to rescan; prior_scan_id: scan_id of a previous scan to diff against; severity_threshold: return only findings at or above this severity (critical, high, medium, low, or info; default: all); scanners: limit which scanner classes run (sast, secret, vuln, misconfig, license, or ai; default: all); max_findings: cap the number of findings returned per category to protect agent context. Never writes to your code or repo. |
Selection evidence
Confusable tool pairs.
4 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
codeinspectus_scan |
codeinspectus_rescan |
medium | Both take a path and run the same scanners; a task like 're-scan this path and tell me what's still failing' or 'check whether my fixes worked' could land on scan instead of rescan, which is the diff-vs-prior-scan tool. |
codeinspectus_scan |
codeinspectus_compliance_report |
medium | scan already returns per-framework compliance overviews and has an include_compliance flag, so a task like 'run a compliance scan' or 'check NIST CSF for this repo' could plausibly trigger scan rather than the scan_id-based compliance_report. |
codeinspectus_scan |
codeinspectus_generate_sbom |
low | Both use offline Trivy/native Pub over lockfiles, so a task like 'scan the dependency inventory for this project' could pick generate_sbom (which writes an SBOM) instead of a vulnerability scan; most phrasings like 'SBOM' vs 'security scan' stay distinct. |
codeinspectus_compliance_report |
codeinspectus_explain_finding |
low | A task like 'explain the SOC 2 findings in scan X' could be read as either the framework-specific control-coverage report or per-finding deep-dives, but explain_finding's explicit finding_id+scan_id requirement usually disambiguates it. |
Compare the field