Memory Tools

Reading memory

Ten of the fifteen tools only read. All fifteen exist on every deployment; which ones a given client is offered depends on the permission you approve when you connect it. A connection granted mcp:read and nothing else is offered exactly these, because a tool the connection cannot call is withheld rather than advertised and then refused.

get_related_memories is the one worth knowing about. Search answers “what is relevant”; this answers “what is connected”. MemorySync records typed, confidence-weighted edges between memories — including contradiction — so an assistant can find the memory that conflicts with what it just read instead of averaging the two.

{
  "memory_id": "m_412",
  "relationship_types": ["contradiction"]
}

Writing and deleting memory

add_memory runs the same extraction pipeline as the REST API, so conversational filler is discarded and near-duplicates are merged. A skipped result is a normal outcome, not an error, and an assistant should not retry it.

update_memory edits labels only. The memory body is encrypted and embedded, so correcting a fact means calling add_memory with the correction and letting extraction supersede the stale record.

The two bulk deletes preview by default, so clearing a scope takes two deliberate steps.

delete_all_memories {}
-> { "dry_run": true, "would_delete_count": 412,
     "confirmation_required": "DELETE ALL MEMORIES" }

delete_all_memories { "dry_run": false, "confirm": "DELETE ALL MEMORIES" }
-> { "dry_run": false, "deleted_count": 412 }

Resources and prompts

A resource is context a client can attach without the model deciding to call a tool, which matters because the profile is most useful before the first question — when the model has no reason to think it needs anything. All four are read-only and derived from data the same connection could already reach.

A prompt is a ready-made message you insert from a slash menu or prompt picker. These exist so the right workflow does not depend on you knowing how to ask for it.

recall

Takes a question. Assembles your profile plus the relevant memory, then instructs the model to answer from it and to say so when the memory is silent rather than inventing an answer.

audit_memory

Takes a memory_id. Shows that memory alongside everything recorded as contradicting it, and asks the model to work out which version holds now — checking with you before deleting anything.

Scopes and read-only access

A dynamically registered MCP client may request only two scopes. It cannot ask for anything administrative.

This is a per-connection choice, not a deployment setting. The write and delete tools are always implemented; approving only mcp:read at the consent screen means this one client is not offered them, and the assistant sees a coherent read-only server rather than tools that fail when called. Connect a second client and approve mcp:write, and that client gets the full set. Tokens issued to an existing OAuth app with the equivalent memory scopes are accepted too, so an integration you already authorized keeps working without re-consent.

Call whoami from the client at any time to see exactly which scopes were granted. It is the tool to reach for when a write is refused and you need to explain why rather than guess. The sign-in section covers how consent is granted and re-granted.

Every tool declares an output schema, so a client can validate the structured result and a model can plan its next call from the schema rather than from the shape of the last response.