memory-healthlisted

Call `mcp__mubit__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. `mcp__mubit__mubit_status` inspects the connection. The two answer different questions and are easy to confuse, because both fail as "memory isn't working". - **`mcp__mubit__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. - **`mcp__mubit__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 outside, 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. Under Codex, check the hook install first: a plugin-bundled `hooks.json` is inert until it has been merged into `$CODEX_HOME/hooks.json` and trusted, and an untrusted hook is skipped silently under `codex exec` — no