Related Servers

Each tool maps to a distinct action in the memory lifecycle: create (record_memory), read single (get_memory), read bulk (retrieve_context vs search_memory), mutate links (link_memories), transition state (change_status), add/re-verify evidence (attach_evidence vs verify_evidence), and proactive diff analysis (list_affected). The descriptions explicitly police the risky boundaries — search_memory states it is not the tool for building context, list_affected contrasts itself against both read paths, and link_memories vs change_status/supersedes_link_to is called out directly. The `scope` parameter's differing semantics per tool (disambiguator vs filter) are also documented rather than left implicit.

All nine tools follow a strict snake_case verb_noun pattern (attach_evidence, get_memory, link_memories, change_status, record_memory, list_affected, verify_evidence, retrieve_context, search_memory). Verbs are conventional and non-overlapping in meaning, so names alone convey the action. No camelCase or stylistic drift anywhere in the set.

Nine tools is well within the ideal band and each one earns its place: a create, three read paths with genuinely different purposes, two evidence operations, a link operation, a status transition, and a diff-driven risk report. No tool appears redundant or bolted on, and nothing essential to the described workflow is crammed into an overloaded multi-purpose tool.

The lifecycle is essentially closed: create, read, enrich with evidence, link, transition to terminal states (superseded/invalidated/abandoned/archived), proactively detect invalidation, and explicitly re-verify. Minor gaps remain — there is no way to edit a memory's statement text in place (only supersede and re-record), no unlink operation to undo an erroneous link_memories, and no enumeration/stats tool to browse the store without a query. These are workable around but would cost an agent extra steps in edge cases.