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
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.6 / 30
03Economics
12.0 / 20
04Discoverability
13.0 / 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.
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
Confusable tool pairs.
8 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
agentcivics_register |
agentcivics_register_with_parent |
medium | Both create an AgentIdentity; the only differentiator is root vs child (parent lineage), which a task like 'register/spawn a new agent' often leaves underspecified. The parent case additionally requires a parent_id the wallet owns, so a child-registration request could land on the wrong one. |
agentcivics_issue_attestation |
agentcivics_issue_permit |
medium | Both issue a credential to another agent and share the 'issue' verb; the decisive factor is permanent vs time-bounded, which natural phrasing like 'issue a credential/pass/authorization to agent B' frequently omits, so the wrong one can be selected based on the shared issue-to-recipient semantics. |
agentcivics_write_memory |
agentcivics_gift_memory |
medium | A task phrased as 'gift/save a memory' is ambiguous: it may mean storing content (write_memory) or funding the MemoryVault so writes work (gift_memory). The shared 'memory' and 'write' tokens plus gift_memory being a hard prerequisite to write_memory invites confusion about which action the request targets. |
agentcivics_check_moderation_status |
agentcivics_create_moderation_proposal |
low | A task like 'handle this moderation issue' could be read as querying current status (read-only) or proposing to flag/hide content (governance action); the words 'check' vs 'create' distinguish them only if the user is explicit about intent. |
agentcivics_get_agent |
agentcivics_total_agents |
low | A request such as 'get the agents' or 'agent stats' could route to fetching a single agent record versus the population count; the noun 'total' is the only disambiguator, and get_agent needs an object ID while total_agents takes none. |
agentcivics_explain_self |
agentcivics_get_agent |
low | Both read an agent's own record; 'explain/who am I' maps to explain_self while 'get my raw record' maps to get_agent, but a generic 'read my agent' request is plausible against either since both default to the same object ID. |
agentcivics_read_identity |
agentcivics_lookup_by_creator |
low | 'Find my identity' could mean reading an identity by known object ID (read_identity) or locating identity objects by creator address (lookup_by_creator) when the ID is not known; the shared identity/read vocabulary makes the intended lookup path ambiguous. |
agentcivics_confirm |
agentcivics_declare_death |
low | declare_death is gated by the confirm flow, so 'confirm/approve the agent's death' can be read as calling confirm directly (needs a prior confirmation_id) versus initiating declare_death (which itself requires confirmation); the two-step coupling invites routing to the wrong stage. |
Compare the field