Surface MCP server catalog counts in status

[matzew]

Summary

Surface the number of tools, resources, and prompts a managed MCP server exposes
in status.serverInfo.catalogCounts, collected during post-handshake discovery.

Split out of #359, which blended catalog-size metadata with progressive-discovery
behavior. This issue covers the catalog counts / size metadata half.

Motivation

From the MCP Roadmap: progressive discovery highlights the cost of large
tool catalogs. Exposing catalog counts gives operators at-a-glance visibility into
what a server offers and is a prerequisite for reasoning about catalog size.

Scope

• Extract tool/resource/prompt counts after a successful handshake
• Distinguish "capability not supported" (nil) from "supported, zero items"
• Follow pagination cursors so multi-page catalogs are counted in full

Status

Implemented by PR #364 (in review).

[matzew]

Related cross-SIG work: kube-agentic-networking PR #227 (kubernetes-sigs/kube-agentic-networking#227) tackles the adjacent problem - surfacing the full discovered tool inventory (with schema validation for policy) via a dedicated XToolInventory CRD, rather than lightweight counts in status.

Both efforts call tools/list post-handshake, so worth keeping coordinated. One design point of note: KAN deliberately chose a separate CRD over XBackend.status because not every backend controller does discovery and the backend shape is in flux. Our operator owns the full server lifecycle, so surfacing counts in status.serverInfo.catalogCounts remains reasonable for this lightweight case.

[matzew]

Prior art + caveat: Kuadrant removed an equivalent status.discoveredTools

Kuadrant/mcp-gateway had a .status.discoveredTools count on their
MCPServerRegistration and removed it in mcp-gateway PR #1187
(merged 2026-06-29, closes #629). Their stated reasons: the
controller set Ready + counts by HTTP-polling the broker's /status endpoint
(config flows one-way to the broker via a ConfigMap), which was unreliable -
counts went stale, the controller wasn't notified when tools changed, and it
would still report Ready even if the server went down.

Why that failure mode does not apply to us: their controller asked a
decoupled broker over HTTP. Our operator connects directly to the MCP
server during reconcile and reads the counts inline, then writes them
synchronously - there is no broker round-trip or status-polling lag.

Caveat that does still apply (honestly): even with inline discovery, our
count is a point-in-time snapshot taken at reconcile. Without subscribing to
tools/list_changed, it can drift between reconciles - the same "not notified
when tools change" concern #629 raised. Worth documenting the semantics as
"counts as of last successful handshake" and considering tools/list_changed
if we want them kept fresh.

cc context: raised with @davmarti (Kuadrant).