Explain Hermes's "faces not registered" report: a stale session, not the bridge

A raw MCP client and a fresh `hermes mcp test robot` both list faces, look and
list_people, and Hermes's own log shows it registering all of them at 01:18:46 after
the robot restart and a later session calling faces() fine. The reporting session
started at 00:35, before faces existed, and keeps its start-time snapshot of the tool
table. Record the cause and the fix (start a new Hermes session) in the README
troubleshooting and CONTEXT.md, and note why the bridge keeps stateful sessions.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AFN8nRRCiDiMN7ChBpHJhs

CONTEXT.md

@@ -274,6 +274,21 @@ owner wants it); detecting people, objects or motion (only faces exist, and `rob
 `look()`'s default was not flipped to JSON-only, because the image is what lets Hermes describe a
 scene; that default is the owner's call.
 
+### Hermes bug report: "faces and list_people are not registered" (2026-10-05) — not a bridge bug
+
+Checked, not assumed: a raw MCP client lists `faces`, `look`, `list_people`; `hermes mcp test robot`
+(fresh connection) discovers all three; there is no tool filter in `~/.hermes/config.yaml`. Hermes's own
+`agent.log` explains the report: my robot restart at 01:17 ended the MCP session (`keepalive failed ...
+Session not found`), Hermes reconnected and logged `registered 7 tool(s): mcp__robot__faces, look,
+list_people, ...` at 01:18:46, and a session that started afterwards (`...011845...`) called
+`mcp__robot__faces` fine. The reporting session (`...003532...`) started at 00:35, before `faces`
+existed, and keeps its start-time snapshot of the tool table: it still reaches live things
+(`list_prompts`, `read_resource`) but gets `'mcp__robot__faces' is not a known tool name`. Fix on the
+owner's side: start a new Hermes session after the robot's tool set changes. For Hermes: refresh a
+session's tool table (and its deferred-tool index) when the MCP server is re-registered. We keep the
+bridge's stateful sessions on purpose: the `Session not found` after a restart is what makes Hermes
+reconnect and re-register (stateless HTTP would hide a changed tool set from a connected client).
+
 ## Face recognition (opt-in)
 
 `hermes_vision.recognize` / `people`: SFace embeddings on YuNet's landmarks. Nothing is stored until

README.md

@@ -171,6 +171,11 @@ about 0.5 px is good. `sudo systemctl restart robot` to load it.
 - **`ros2 node list` shows only some nodes:** use `ros2 node list --no-daemon --spin-time 6`.
 - **The Pi's clock is wrong with Wi-Fi off:** there is no internet to sync from; it stays roughly right
   but unsynchronised.
+- **Hermes says `faces` (or another new tool) is "not a known tool name":** a Hermes session takes a
+  snapshot of its tool table when it starts. If it began before the robot offered the tool (or before a
+  robot restart that added it), it never sees it, even though `robot://status`, `list_prompts` and a fresh
+  `hermes mcp test robot` all show it. Start a new Hermes session. (Hermes's log shows the reconnect
+  and "registered N tool(s)" for the whole process; only that old session keeps its stale table.)
 - **A one-off message to the face is ignored:** ROS drops a message published before the connection
   matches. Republish it, as `hermes_mcp` does every second.