[Feature] Expose enabled and available MCP toolsets from the default catalog

[morluto]

Motivation

GitContribute's small MCP catalogs are intentional, but the default catalog currently cannot explain whether a missing capability is unsupported or merely belongs to a disabled toolset. General routing instructions describe how to use the advertised tools; they do not expose the runtime version, selected toolsets, or other toolsets available in the installed build.

That ambiguity is especially visible with the default contribute registration: the source defines additional code, research, portfolio, and diagnostics catalogs, but a client cannot discover their availability from the active catalog alone. The current ownership map is visible in internal/mcpserver/catalog.go.

This complements #19 and #24. Those changes improve routing and initial discovery; this proposal makes the installed server's capability boundary inspectable without expanding the operational catalog.

Proposed Solution

Keep one compact, read-only capability description in the default catalog. This could be a tool such as system.get_capabilities or an MCP resource, depending on which form hosts expose most consistently.

It should report:

• the installed GitContribute version;
• enabled toolsets;
• available but disabled toolsets;
• a bounded summary of each toolset's side-effect classes, such as offline reads, network reads, local writes, Git-only writes, and process execution;
• the exact configuration or restart action required to enable a disabled toolset.

The result should be deterministic and small. It should not expose all operational schemas, change toolsets at runtime, access the network, mutate local state, or execute a process.

Acceptance criteria:

• The default contribute catalog can describe the installed build's enabled and disabled toolsets.
• The response differentiates “disabled in this registration” from “not provided by this version.”
• Enablement guidance matches the actual mcp serve --toolsets syntax.
• Tests cover the default registration, a multi-toolset registration, and version reporting.

Alternatives Considered

• Enable all toolsets by default. This removes the visibility problem at the cost of the small-catalog design.
• Put a static map only in the generated skill. Static guidance cannot report the active registration or installed version and can drift from runtime configuration.
• Infer capability from failed tool lookup. Absence is ambiguous and does not provide a corrective action.

Impact

This adds a small read-only MCP contract and related documentation/tests. It should not alter corpus schemas, GitHub mutations, network access, or the authority of existing tools.

[morluto]

The TileLang workflow also gives this issue a useful end-to-end check. From the
default advertised catalog, there was no bounded way to learn that workspace
adoption and validation existed in the installed build but were disabled. The
absence looked the same as an unsupported capability.

A capability response would have made the next action mechanical: report
contribute as enabled, code as available-but-disabled, and show the exact
registration/restart command. The important assertion is that this read stays
small and read-only; it should expose capability state and authority classes,
not expand the operational catalog.

[morluto]

Closing because an enabled/disabled-toolset introspection operation is no longer needed for the managed experience. GitContribute will expose one unified catalog and rely on host-native MCP tool search in Codex and Claude Code, so capabilities remain discoverable without an additional system tool or resource.

Keeping this contract would preserve product complexity whose only purpose was explaining an optional-profile boundary. Focused profiles can remain an expert compatibility/evaluation control; #197 will define the evidence required for any future catalog split.