memory-health · diff
git:20260824.f3534e5 to git:20260903.008c305
1 added, 1 removed. Audit A to A.
---
name: memory-health
- description: Report what is actually in Mubit memory — entry counts, staleness, contradictions and per-section health. Use when memory looks empty or stale and you need to know whether anything was ever stored, rather than whether the instance is reachable.
+ description: "Report what is actually stored: counts, staleness, contradictions; use when the question is whether anything was ever stored."
disable-model-invocation: false
tools: ["mcp__plugin_mubit-memory_mubit__mubit_memory_health", "mcp__plugin_mubit-memory_mubit__mubit_status"]
---
Call `mubit_memory_health` — `POST /v2/control/memory_health` — and report what it says about
the store. `limit` (1 to 500) is how many entries it samples; the default is enough unless the
user is specifically asking about an old part of a large run.
## This inspects the store. `mubit_status` inspects the connection.
The two answer different questions and are easy to confuse, because both fail as "memory
isn't working".
- **`mubit_status`** dials the instance. It tells you whether there is something at the other
end, whether the key is accepted, and which typed `ConnState` applies. It knows nothing
about what is stored.
- **`mubit_memory_health`** asks what is in there: how many entries, how stale they are,
whether any of them contradict each other, and how each section is doing. It says nothing
about the connection — if the instance is unreachable this call does not answer at all.
So a healthy connection over an empty store and a full store behind a dead endpoint look
identical from the status line, and they have opposite fixes. Answer the question the user
actually asked before offering a remedy for the other one.
## Reading the answer
- **Zero entries, connection fine.** Nothing was ever written. Check that capture is on, and
remember that an accepted ingest is *queued*, not stored — a run that just started can be
legitimately empty for a minute.
- **Entries present, but recall keeps returning nothing.** The store is not the problem.
That is a retrieval or scope question: go to `/mubit-memory:doctor` step 1 and read
`recall.empty_reason` from the local status marker, which names the cause outright.
- **Contradictions.** Two stored lessons that disagree. Neither is automatically wrong and
deleting both loses the argument: prefer a negative `mubit_outcome` on the one that turned
out false, or `/mubit-memory:forget` if it should never have existed. Report the pair to the
user rather than picking a winner yourself.
- **Staleness.** Old is not broken. Say so — a lesson that has not been touched in months is
usually one that has not been contradicted either.
`session_id` and `user_id` are best left out: the launcher already passes this run's id, and
`user_id` is a retrieval filter, so supplying a value nothing was captured under reports an
empty store that is not empty.
This is step 3 of `/mubit-memory:doctor`, which walks the whole ladder cheapest check first.
Use the doctor skill when the complaint is vague; use this one when the question is already
narrowed to what memory contains. Do not poll it in a loop — it samples the store, and the
answer does not change between turns.