Add tools discovery

Settings → Add tools brings the existing setup paths into one browse screen. It does not install, connect, enable, or authorize anything itself. Each result opens the existing Feature Packs, Skill Store, Connectors, MCP Servers, or Built-in Tools screen, where the user can finish setup and inspect details.

The screen reads installed Feature Packs from listPluginPacks, skill eligibility from getSkillStatus, configured MCP servers and connection state from getMCPSettings and getMCPStatus, and discoverable entries from the pack, skill, MCP, and (for a non-empty query) ClawHub registries. Native integration names and descriptions share the catalog used by Connectors. Existing messaging channels link to their matching channel settings; their setup and message delivery remain unknown until those settings or a real task provide evidence. Registry entries have no live readiness signal, so they show unknown. An enabled pack or eligible skill still has unknown workflow success; a connected MCP server still has unknown action success. The screen shows source-supported missing skill requirements, recommended pack connectors, MCP errors, and disabled state, then links to the relevant setup surface for repair. Selecting a result carries its stable catalog identity into that screen and opens or focuses the matching entry where the existing UI supports it.

The current renderer APIs expose inventory and setup signals, not action-specific readiness. getSkillStatus reports eligibility and missing requirements, while MCP APIs report configured servers, connection state, and advertised tools. The runtime's evaluateToolAvailability needs a task-specific policy context, but there is no renderer API that returns an auditable decision for a particular capability identity, action, route, and task context with provenance. Therefore Add tools does not infer that an action is ready from connection state, an enabled flag, or a tool name. A trustworthy action-readiness view would need a read-only operation-evidence contract that includes the effective route/context, prerequisite checks, timestamp/source, and a repair path, with matching runtime policy and permission semantics.

Registry search is limited to the first returned page of packs and skills. The browse screen caps visible matches at 30 and directs users to the full catalogs for further exploration. If a source request fails at the renderer boundary, its status is reported as unavailable. Some registry APIs normalize internal failures to an empty result, so an empty search is described as “No results were returned”; it does not prove the catalog had no matches. Permissions and approvals remain in System & Security.