01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100%, destructive-action safety rate 0% (baseline only -- no rewrite pass applied).
Category breakdown
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
0.0 / 30
29.5 / 30
20.0 / 20
13.3 / 20
Highest-impact fix
Estimated gain +30 pointsExpose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
0 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 |
|---|---|---|
| No description defects were flagged in this assessment. | ||
Selection evidence
2 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
glm_agent |
glm_recommend |
medium | A task phrased as 'should I use GLM or Opus for this repo task?' asks for a recommendation (glm_recommend's stated purpose), but glm_agent's description pushes itself as the default ('prefer this over doing repo work yourself') and frames GLM as cheaper-than-Opus, so an agent could misread the uncertainty question as a directive to actually run the task via glm_agent. |
glm_recommend |
glm_status |
medium | Both are free local no-GLM-call tools; glm_recommend picks a model for a task while glm_status reports the active model/config health. A task like 'which model am I on and is it the right one for my task?' or 'check my GLM setup and tell me what model to use' plausibly routes to the wrong one since status outputs the current model and recommend outputs the recommended model. |
Compare the field