How an agent finds the one tool it needs among everything the mesh answers, and how a call names
exactly what it asks — a role the mesh holds once, a role every machine holds, or one assignment of a
module on one machine — rather than receiving the whole catalogue and a name that can mean several
things.
Why
The operator's observation on 2026-10-03: Claude should not see all tools at once; they should be
discoverable — and postgres.list_databases is wrong, asking one machine's postgres is not asking
another's. Measured the same day from the console's own answer:
modules reported "not answering", most with no tools and several retired
47
The two stateful modules on two machines are listed once, with node optional and whichever
answers when it is left out — though their two instances hold different databases. Design 34 §3 says
such a module is listed once per machine; the live console does not do that. The list is taken once
per session, so a tool that arrives later is invisible until the client reconnects. And only Claude
Code's own deferral of long tool lists keeps the 228 from the model's context; another MCP client
would receive them whole.
Options
Keep the flat list; rely on the client to defer it. Rejected: a property of one client, and it
leaves the ambiguity and the stale list.
One flat tool per assignment (ace_postgres_list_databases). Removes the ambiguity, multiplies
the list, and runs into the API's tool-name limit (letters, digits, _, -, 64 characters).
A small fixed set of tools that walk the mesh's own structure, with the full address as an
argument: the mesh's seats; a machine's node seats and assignments; a search; a description; a
call. Chosen — see ADR 0195.
MCP resources or prompts for discovery. Clients support them unevenly, and an agent acts
through tools; a resource it cannot be relied on to read is not a discovery path.
