novox/hq
6
0
Fork 0
Code Issues 5 Pull Requests 2 Releases Wiki Activity

Issue 229: the stale tool list is a connection opened before discovery; the fix is list-changed

Browse Source
This commit is contained in:
jochen
2026-10-04 11:01:50 +02:00
parent f23a71e0d7
commit 0c2eae07c5
1 changed files with 11 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
04-ISSUES/229-a-rollout-cannot-be-followed-through-the-meshs-tools/00-report.md
+11 -11
View File
@@ -11,7 +11,7 @@ amended-design:
## What was observed
2026-10-04, rolling out to-be 41. An agent drove the rollout through the mesh's MCP tools: the
controller seat's `status`, `plans`, `command`, and the forge's merge. Five times it left those tools
controller seat's `status`, `plans`, `command`, and the forge's merge. Four times it left those tools
and posted JSON-RPC by hand to the node console's HTTP endpoint with `curl`:
1. **To wait for a plan.** `plans` answers once, with prose. Nothing waits for a plan to reach a tier,
@@ -24,13 +24,12 @@ and posted JSON-RPC by hand to the node console's HTTP endpoint with `curl`:
3. **To read one module out of `module list`,** whose output was too long to read whole for one line.
4. **To call a tool that arrived after the agent's session began.** The modules rolled out in that same
session added `node-login-shell.execute` and `zsh.zsh_config` to one machine. The agent's MCP
connection to the mesh had listed its tools once, when the session started, and never listed them
again: no list-changed notice reached it, and a search of its tools found neither verb. So the only
way to prove the new verb through the mesh was the console's `mesh_call`, posted by hand.
5. **To reach the console's own generic tools at all.** The console serves `mesh_overview`,
`mesh_machine`, `mesh_search`, `mesh_describe` and `mesh_call`. The MCP connection the agent had
flattens every module's tools into one list, and exposes none of those five. The one surface that
can reach any tool by address is therefore missing from the connection agents use.
connection had been opened before the console moved to discovery ([ADR 0195](../../02-DECISIONS/0195-the-meshs-tools-are-found-by-address-not-announced-whole.md)).
It still held the flat catalogue the console announced then, which lacks both the new verbs and the five discovery tools (`mesh_call` among
them) the console announces now. Clearing a session does not reconnect its MCP servers, and the
console never sends a list-changed notice, so nothing told the client its list was stale. The agent
posted `mesh_machine` and `mesh_call` by hand. Reconnecting the server would have given it the
discovery tools, which reach any tool by address the moment it exists.
The calls were authorised, because the console is the operator's own surface. But each is a raw call
the mesh's tools were meant to make unnecessary ([ADR 0154](../../02-DECISIONS/0154-the-meshs-own-verbs-are-the-controller-seats-tools.md)
@@ -54,8 +53,9 @@ rollout needs.
around it.
- Whether `command`'s generic answer should take a filter, or whether the verbs it is used for most
(`module list`, `node show`) deserve verbs of their own.
- **A tool list that follows the mesh.** When a module's tools arrive or leave, the connection says so
(MCP's list-changed notification). Failing that, it always carries the console's addressable
`mesh_call` and `mesh_describe`, so a new verb is reachable without leaving the agent's tools.
- **A client is told when the console's own surface changes.** The console announces `listChanged`
and sends the notice when what it lists changes, for example after an upgrade that changes its
tools. A long-running session then never keeps a list the console no longer serves. Discovery
already makes every module's tools reachable without the list changing.
How each is checked belongs to the record that settles it.