Fixed
- Meta-tool calls no longer rebuild the session’s catalogue from the definition source and the capability store on every call (#1225).
call_tool,describe_tool,filter_tools,list_toolsand the resource/prompt meta-tools each listed the caller’s catalogue afresh: every workflow definition was fetched from the API server twice per call (once for the tool’s arguments, once to derive its read-only hint – 8182GET workflowsin the two minutes of one agent turn with 282 workflows), and every session-authenticated server’s capabilities were read from Valkey with their ownHGETandGET(~160 round trips per call with 81 such servers). Together that was a floor of about 3 s per meta-tool call on a warm session while the backend answered in 22 ms. Now the aggregator’s own tools (core_*,workflow_<name>) are built once and kept until a workflow definition changes – through muster’s tools or, for a resource applied outside them, through the workflow reconciler – with the step tools carried on the tool so the read-only hint is derived in-process; a session’s capabilities are read with oneHGETALL, and the content-addressed documents behind the references are decoded once per process and shared by every session that references them; the servers a session is authenticated to are read with oneHKEYS. A warm meta-tool call costs two Valkey commands regardless of how many servers are registered. Toolset scoping, session-scoped visibility and the capability freshness mechanisms are unchanged. tools/call responseandErrorlog lines carryduration_s, the time since the request reached the transport, so a slow call is visible in the log without subtracting the request line’s timestamp (#1225).