01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100→100, token cost up 2%, 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.3 / 30
03Economics
19.6 / 20
04Discoverability
15.1 / 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 |
|---|---|---|
memory_stats |
no_return_description |
Retrieve an overview of the stored memory and return a summary containing the total memory count, the breakdown of episodes vs consolidated prototypes, the number of learned associations, the list of domains, and average quality scores. This memory is shared across all AI tools the user has connected to Mnemoverse. Use it to orient yourself, to confirm the exact domain name before a delete, or when the user asks what you remember. Read-only — changes nothing. |
memory_delete_domain |
no_return_description |
Permanently delete EVERY memory in one domain — irreversible, and far more destructive than memory_delete. Returns a confirmation that the domain and all its memories were deleted, or an error if the safety interlock (confirm=true) was not satisfied. Use only on an explicit user request to wipe a whole topic, e.g. 'forget everything about project X' or 'wipe my benchmark experiments'. First run memory_stats to confirm the exact domain name, then pass it together with confirm=true (a deliberate safety interlock). Never call this speculatively or to 'clean up' on your own — only when the user explicitly asks. |
memory_invite_to_room |
no_return_description |
Mint a one-time invite for a room you own and return a ready-to-forward message containing the invite code (mnvr_...) and link the recipient uses to join. The user sends that message to the person they want to add (any messenger); the recipient opens the link or tells THEIR assistant the code to join. Use after memory_create_room, or whenever the user says 'invite <someone>' to an existing room. |
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 |
|---|---|---|---|
memory_delete |
memory_delete_domain |
medium | Both are destructive 'delete memory' tools sharing vocabulary (delete/irreversibly/permanently), and natural phrasing like 'get rid of that memory about project X' is genuinely ambiguous between removing a single atom_id (memory_delete) and wiping an entire domain (memory_delete_domain); the descriptions cross-reference each other but don't map an ambiguous user-facing quantity to atom vs domain, and the wrong pick ranges from leaving residue (delete on what was meant as a domain) to destructive overreach (domain wipe on what was meant as one memory). |
memory_write |
memory_create_room |
medium | memory_write touts 'write once, recall everywhere' across all tools, which blurs with room-based sharing; a task like 'remember this so my teammate can see it' could wrongly route to memory_write (optionally with a domain arg, or thinking cross-tool reach covers a person) instead of creating a shared room with memory_create_room. |
memory_feedback |
memory_delete |
medium | Both consume ids returned by memory_read, and a user saying a recalled memory is 'wrong' or 'outdated' maps equally to memory_delete ('correct a fact you stored wrongly') and memory_feedback with a negative outcome; natural language rarely signals whether the intent is permanent removal vs letting the memory fade via a learning signal. |
memory_read |
memory_stats |
low | A loosely worded ask like 'show me what you remember' could route to memory_read, whose description urges ALWAYS checking there first when unsure, instead of memory_stats, which is the overview explicitly intended for 'when the user asks what you remember'; the targeted-query vs overview distinction mostly disambiguates, but open-ended recall requests remain ambiguous. |
Compare the field