Tool on-demand activation: deferLoading hides tools with no activation channel (DeepSeek Messages API)

[leesocrates]

Environment: dsh runtime 0.2.0-rc.2, DeepSeek Messages API, tools defined via dsh-tools defineTool().

Problem: defineTool({ deferLoading: true }) currently has the practical semantics of completely hiding the tool from the model's function surface on the DeepSeek Messages API. Serialization still happens normally and the flag is carried through, but the tool never appears in the model-visible tool list, and there is no activation mechanism of any kind — no built-in tool_search meta-tool, no reference-based activation. Net effect: enabling deferLoading breaks the tool (calling it by name fails). Verified over three empirical rounds (24-tool listing with exactly the 6 deferred tools missing; direct name-call attempts fail).

Meanwhile the agent loop already supports mid-session registry changes → tool-addition developer messages, so the "second half" of dynamic loading (broadcasting newly available tools) already exists. What's missing is an officially supported activation path.

Ask: provide a supported on-demand tool activation mechanism, in any of these forms:

1. A built-in tool_search meta-tool (BM25-quality retrieval is sufficient); matches activate the full schema via tool reference — aligned with Anthropic's tool search / Claude Code Agent SDK shape (https://code.claude.com/docs/en/agent-sdk/tool-search).
2. Or: keep a "directory line" (name + one-line summary) resident for deferred tools, activating the full schema on first mention.
3. Or: expose a stable plugin API allowing a shell tool's execute to register a family of real tools, broadcast through the existing tool-addition message (mechanism already works; it lacks official backing and documentation).

Motivation / measured data: ~50 tools ≈ 10–20K tokens of resident per-request cost; on a full dsh tool surface (~16.5K tokens) every family is injected unconditionally even though most sessions never use it. Crucially, tool demand cannot be reliably classified at session start — a single session may pivot into browser operation mid-way (observed in production on 2026-10-08: a doc-research session switched to live browser testing mid-session). Host-side pre-loading/pre-pruning will therefore always misclassify; the ask is model-side on-demand activation, not host-side prediction.