[Feature] Route the managed Codex skill across optional MCP toolsets

[morluto]

Motivation

The managed Codex skill currently tells the client to discover GitContribute tools and fall back when no advertised tool fits. That works when the required tool is in the selected MCP catalog, but GitContribute intentionally separates specialized capabilities into optional toolsets.

With the default contribute registration, implementation inspection, base/candidate validation, external architecture research, authored-PR follow-up, and search diagnostics are not advertised. A client can therefore mistake “available in a disabled toolset” for “not supported” and silently switch to a less suitable workflow.

This is a follow-up to #24. It is distinct from the general MCP routing work in #19 and #22: the missing decision happens after GitContribute has already been selected, at the boundary between its optional toolsets.

The current generated skill is defined in internal/setup/setup.go, while the toolset ownership map lives in internal/mcpserver/catalog.go.

Proposed Solution

Add a compact intent-to-toolset map to the generated skill:

Issue/PR discovery and evidence     → contribute
Implementation/code inspection      → code
Base/candidate tests and profiling  → code
External architecture research      → research
Authored PR follow-up                → portfolio
Search-ranking diagnosis             → diagnostics

When the required toolset is not advertised, the skill should distinguish that state from an unsupported capability. It should name the missing toolset and the exact configuration or restart action needed to enable it. A fallback can remain available, but it should not make the GitContribute capability look absent.

Acceptance criteria:

• The generated skill contains the compact routing map without reproducing operational tool schemas.
• It distinguishes a disabled toolset from a capability GitContribute does not provide.
• It keeps the current default catalog small and does not grant additional authority.
• Setup tests cover the generated routing text and its enablement guidance.

Alternatives Considered

• Expose every toolset by default. This removes the routing ambiguity but gives up the smaller-catalog design and increases tool overlap and context cost.
• Repeat every operational schema in the skill. This would become stale and duplicate the MCP catalog. The skill only needs ownership and escalation guidance.
• Rely on the README or server initialization instructions. Those help once their content is visible, but they do not reliably explain why a relevant optional tool is absent from discovery.

Impact

This should primarily affect the managed skill text, setup tests, and setup documentation. It should not change corpus state, GitHub state, network behavior, or the side effects of any existing tool.

[morluto]

A TileLang bug-fix workflow provides a concrete acceptance scenario for this
routing gap. The task explicitly called for isolated worktrees, base/candidate
proof, review, and PR preparation. GitContribute was available, but the
advertised default catalog did not expose workspace adoption or validation, so
the workflow fell back to native Git worktrees and shell commands even though
GitContribute already has relevant capabilities behind the code toolset.

The useful routing decision would have been:

issue/PR research                 -> contribute
adopt worktrees + compare proof  -> code
prepare contribution evidence    -> contribute

This is not evidence that the capability is absent; it is evidence that the
client could not distinguish “disabled toolset” from “unsupported.” A focused
evaluation could assert that a request containing “worktrees” and
“base/candidate validation” names code and gives the exact enablement action
instead of silently abandoning the GitContribute workflow.

[morluto]

Closing because the premise changed: GitContribute will present one unified catalog instead of requiring the managed skill to route across disabled profiles. Current Codex defers model-visible MCP tools behind host-native tool_search when the model/provider supports it, and Claude Code automatically enables MCP tool search when tool definitions cross its configured context threshold. That removes the disabled-vs-unsupported ambiguity without duplicating operational schemas or adding setup-time routing instructions.

The focused toolsets can remain an expert compatibility/evaluation control for hosts without tool search, but they are no longer the managed default. The catalog-selection behavior will be evaluated under #197.