Summary
Companion to traverse-framework/registry#103 (umbrella) and #102 (registry search only matches namespace/id substrings, no discovery over what a capability actually does).
traverse-mcp already exists (spec 209, crates/traverse-mcp/src/tools/capabilities.rs) with list_capabilities/get_capability tools — list_capabilities already returns each capability's description, but only filters on service_type/permitted_targets, no free-text search over description or use cases.
Ask
Add a search_capabilities(query: String) MCP tool (or extend list_capabilities's filter with a query param) that matches against each capability's description (and, once traverse-framework/registry#104 lands, its use_cases scenario text) rather than only structural filters. Should query capabilities resolved from the synced public registry index (registry sync), not just an in-process dev registry, so it actually reflects everything published — verify this against how CapabilityRegistry::discover/LookupScope currently source their data before assuming it already covers the public index.
Context
Decided via /brainstorm with the registry repo owner (2026-07-29): rather than build a new, separately-hosted MCP server (which GitHub Pages cannot run — it's static-hosting only, no server process), extend the MCP server that already exists and already runs the normal way (local stdio process, launched by the agent's own host). See traverse-framework/registry's docs/decision-log.md entry 40 for full reasoning.
Related, not duplicated
traverse-framework/registry#99 / traverse-framework/Traverse#865 is a separate, already-open effort for workflow/content-group discovery aimed at kit/OS-shell MCP consumers — different scope (capability-level search vs. workflow catalog), kept deliberately separate but should reuse this search infrastructure once both exist, rather than rebuilding it twice.
Summary
Companion to
traverse-framework/registry#103(umbrella) and#102(registry search only matches namespace/id substrings, no discovery over what a capability actually does).traverse-mcpalready exists (spec 209,crates/traverse-mcp/src/tools/capabilities.rs) withlist_capabilities/get_capabilitytools —list_capabilitiesalready returns each capability'sdescription, but only filters onservice_type/permitted_targets, no free-text search over description or use cases.Ask
Add a
search_capabilities(query: String)MCP tool (or extendlist_capabilities's filter with aqueryparam) that matches against each capability'sdescription(and, oncetraverse-framework/registry#104lands, itsuse_casesscenario text) rather than only structural filters. Should query capabilities resolved from the synced public registry index (registry sync), not just an in-process dev registry, so it actually reflects everything published — verify this against howCapabilityRegistry::discover/LookupScopecurrently source their data before assuming it already covers the public index.Context
Decided via
/brainstormwith the registry repo owner (2026-07-29): rather than build a new, separately-hosted MCP server (which GitHub Pages cannot run — it's static-hosting only, no server process), extend the MCP server that already exists and already runs the normal way (local stdio process, launched by the agent's own host). Seetraverse-framework/registry'sdocs/decision-log.mdentry 40 for full reasoning.Related, not duplicated
traverse-framework/registry#99/traverse-framework/Traverse#865is a separate, already-open effort for workflow/content-group discovery aimed at kit/OS-shell MCP consumers — different scope (capability-level search vs. workflow catalog), kept deliberately separate but should reuse this search infrastructure once both exist, rather than rebuilding it twice.