01Safety
0.0 / 30
What changed in the harness
Selection accuracy 88→84, token cost up 4%, 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
26.1 / 30
03Economics
20.0 / 20
04Discoverability
12.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.
3 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 |
|---|---|---|
openclaw_status |
no_return_description |
Get OpenClaw gateway status and health information for the specified instance, returning fields such as connectivity/reachability state, uptime, and version information. |
openclaw_task_list |
no_return_description |
List tasks, optionally filtered by status, session, or instance, returning an array of task records (task_id, status, session_id, instance, and result if completed). |
openclaw_task_cancel |
no_return_description |
Cancel a pending task that has not yet started running, returning the task's updated status, or an error if the task has already started or completed. |
Selection evidence
Confusable tool pairs.
5 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
openclaw_chat |
openclaw_chat_async |
high | Both send a message to OpenClaw with identical message/session_id/instance params; an agent asked to 'send a message' with no explicit sync/async requirement could easily pick the wrong one, especially since the async variant's benefit (long-running tasks) isn't always obvious from the task phrasing. |
openclaw_status |
openclaw_task_status |
medium | Both are named '*_status' and return status info; a request like 'check the status' is ambiguous between gateway health (openclaw_status) and a specific async task's status (openclaw_task_status) unless the user clearly references a task_id. |
openclaw_task_list |
openclaw_task_cancel |
low | Both operate on tasks but have clearly distinct verbs (list vs cancel) and different required params (task_id required for cancel), making confusion unlikely except in very vague phrasing like 'handle my tasks'. |
openclaw_task_status |
openclaw_task_list |
low | A vague request like 'what's happening with my tasks' could map to either checking one task's status or listing all tasks, though task_status requires a specific task_id which usually disambiguates intent. |
openclaw_task_status |
openclaw_task_cancel |
low | Both require a task_id and relate to a specific task, but 'check' vs 'cancel' verbs are distinct enough that confusion is unlikely except in terse or malformed requests. |
Compare the field