01Safety
0.0 / 30
What changed in the harness
Selection accuracy 98→94, token cost up 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
28.2 / 30
03Economics
17.9 / 20
04Discoverability
12.6 / 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.
2 defects 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 |
|---|---|---|
check_dependency |
no_return_description |
Look up a package in quantakrypto's known quantum-vulnerable dependency database (the classical crypto it exposes). Provide 'name' and optional 'ecosystem' (default npm). Returns whether the package is flagged as quantum-vulnerable and, if so, which classical algorithm(s) it relies on. |
probe_endpoint |
no_return_description |
Actively probe ONE live TLS/SSH endpoint YOU OWN for post-quantum readiness (PQC-hybrid key exchange X25519MLKEM768, classical certificate posture). REQUIRES an ownership attestation: set i_own_this=true to confirm you are authorized to test the target. Refuses CIDR ranges / wildcards / lists — one host at a time. Performs only a benign, unauthenticated handshake and never modifies the endpoint. Returns the handshake outcome: whether a PQC-hybrid key exchange was negotiated, the classical certificate/algorithm posture observed, or an error if the probe was refused or failed. NOTE: this is the ONLY quantakrypto MCP tool that opens a network connection; the server is otherwise offline. Over HTTP it is disabled unless the operator sets QUANTAKRYPTO_MCP_ALLOW_NETWORK=1. |
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 |
|---|---|---|---|
remediate_findings |
triage_findings |
high | Both take the identical 'findings' array from scan_path and produce a deterministic REQUEST bundle for the host agent to reason over; a task like 'handle these scan findings' doesn't clearly indicate whether the agent wants exposure/priority triage or fix remediation, and the tools' near-identical schemas and phrasing invite the wrong pick. |
apply_triage |
triage_findings |
medium | Both are named around 'triage' and operate on findings/verdicts; an agent asked to 'triage these findings' might call apply_triage directly without first calling triage_findings to generate verdicts, since apply_triage's description also mentions triage verdicts prominently. |
apply_triage |
apply_verified_patch |
low | Both are 'apply_*' tools that deterministically finalize an agent's prior work (verdicts vs. patches), but their domains (triage scoring vs. code patch verification) are distinct enough that confusion is unlikely except from name-pattern matching alone. |
get_fix_examples |
verify_fix |
low | Both relate to 'fix' and classical crypto code, but one returns illustrative before/after examples while the other checks a snippet for remaining vulnerabilities; a task like 'show me how to fix this' vs 'check if this fix worked' are phrased differently enough to usually disambiguate, though a vague 'fix this' request could momentarily cause hesitation. |
Compare the field