Log tool-surfacing outcome on every tools/list call

[swarup-padhi-glean]

What

Enhance logging on the tools/list path so the most common question — "why don't my tools appear?" — is answerable from ~/.glean/glean-server.log alone.

Before, the handler only logged on the two failure paths (connect.backend-error, tools-list.fetch-failed). The success path and both pre-auth early returns (no server URL, no token) were silent, so you couldn't tell whether an empty dynamic surface was caused by missing config, missing auth, a backend blip, or a backend that genuinely returned nothing.

Change

Emit one structured tools-list.served line on every return path of the handler, via a small serve(reason) helper:

tools-list.served {"static":3,"dynamic":7,"names":["search","read_document","chat","memory","memory_schema","user_activity","employee_search"],"reason":"fetched"}

• static — count of always-present local tools (find_skills, run_tool, setup)

• dynamic / names — the remote tools actually surfaced (freshly fetched, or served from cache on a blip)

• reason — which path produced this result:

  reason	meaning
  unconfigured	no server URL set → served static + cache, skipped remote
  unauthenticated	no token → served static + cache, skipped remote
  connect-error	couldn't open remote client → served static + last-known cache
  fetch-failed	listTools failed → served static + last-known cache
  fetched	fresh remote list succeeded

The existing connect.backend-error / tools-list.fetch-failed error lines (which carry the error msg) are kept — the new line complements them with counts + outcome.

Because the allow-list only ever drops tools outside our fixed 7-tool set, a missing allow-listed name (e.g. chat absent from names) means the backend never returned it — so the name list alone distinguishes "backend didn't serve it" from "auth/connectivity problem."

Privacy: only tool names, counts, and the reason tag are logged — never argument values (consistent with summarizeCall).

No behavior change to which tools are served on any path.

Note / tradeoff

tools-list.served fires on every tools/list, and hosts poll that on idle cycles — so it's chatty on a healthy plugin (this is consistent with the already-always-on error lines). It's exactly what you want when debugging tool-surfacing. If the noise is unwanted in steady state, an easy follow-up is to gate the reason === "fetched" case behind a debug env flag while keeping the diagnostic paths always-on. Happy to do that if preferred.

Test plan

• npm run typecheck ✓
• npm test ✓ (154 passed)
• npm run build ✓
• bash scripts/check-version-bump.sh origin/main ✓ (0.2.30 → 0.2.31, all three manifests aligned)

Version bumped to 0.2.31 across all host manifests; plugins/glean/dist/index.js rebuilt by the pre-commit hook.

[eshwar-sundar-glean]

Nice! We should make sure all these works are folding into feedback tool

[eshwar-sundar-glean]

Is it fair to call this reason, this is more of "state"

[swarup-padhi-glean]

Good call — renamed reason → state in d1f9bb3.

[eshwar-sundar-glean]

@swarup-padhi-glean - Before merging, just check this, you are mutating tools array by adding new tools, previously this was not the case. I am thinking what happens if the state keeps changing, so there will be duplicate copies. I think this might happen please do check before merge. This should probably not happen since tools array is in tools/list call, but just check once

[swarup-padhi-glean]

@eshwar-sundar-glean thanks for the careful read on both points 🙏

Mutation / duplicate copies: tools is allocated fresh on every tools/list call (const tools = [...] inside the handler), and I never mutated the module-level cachedRemoteTools — push(...cachedRemoteTools) spreads its elements into the per-call array; the cache itself is only ever reassigned. So there was no cross-call accumulation. That said, your instinct is right that keeping it non-mutating is cleaner — in d1f9bb3 I refactored serve() to return a fresh [...staticTools, ...dynamic] and dropped all .push, so the handler is now provably non-mutating (and output is identical on every path).

Folding into the feedback tool: these lines all land in ~/.glean/glean-server.log, which the feedback tool already captures — so they fold in for free, no extra wiring. Happy to add tools-list.served to whatever the feedback bundle explicitly surfaces if useful.