Bug description
kubectl get mcpgroups prints a SERVERS column from .status.serverCount. That field only counts MCPServer members.
A group that contains only MCPRemoteProxy objects (or a mix) looks empty / wrong:
status.remoteProxyCount / status.remoteProxies are populated
status.serverCount / status.servers are unset
- the table column therefore shows a blank
SERVERS value
Operators then think the group has no members, even though vMCP discovery and the CR status both know about the proxies.
Steps to reproduce
- Create an
MCPGroup (empty spec is enough).
- Create one or more
MCPRemoteProxy objects with spec.groupRef.name pointing at that group. Do not add any MCPServer.
- Wait until the group is Ready.
kubectl get mcpgroup <name> -n <ns>
kubectl get mcpgroup <name> -n <ns> -o jsonpath='{.status}' ; echo
Expected behavior
The default table should show how many members the group actually has.
Either:
SERVERS = serverCount + remoteProxyCount (and document that), or
- add a
PROXIES / MEMBERS printer column, or
- always set
serverCount to the total member count (and keep the typed lists separate).
Actual behavior
CRD printer columns (v1beta1):
Servers .status.serverCount
Phase .status.phase
Checked .status.conditions[?(@.type=='MCPServersChecked')].status
Age .metadata.creationTimestamp
Observed status on a proxy-only group:
serverCount: <unset>
remoteProxyCount: 3
remoteProxies: [proxy-a, proxy-b, proxy-c]
servers: <unset>
phase: Ready
kubectl get mcpgroups shows SERVERS blank for that group, and a non-zero count only for groups that own MCPServer objects.
Environment (if relevant)
- OS/version: Talos Linux, Kubernetes
- ToolHive version: operator v0.43.0 (CRDs from the same chart)
Additional context
MCPServersChecked is True and the message says it listed MCPServers, MCPRemoteProxies, and MCPServerEntries — so the controller already walks proxies. Only the printer column / serverCount field lags behind.
Related (closed): #4617 (Ready column used the wrong condition), #4541 (Ready column on MCPRemoteProxy).
No credentials or private hostnames in this report.
Bug description
kubectl get mcpgroupsprints aSERVERScolumn from.status.serverCount. That field only countsMCPServermembers.A group that contains only
MCPRemoteProxyobjects (or a mix) looks empty / wrong:status.remoteProxyCount/status.remoteProxiesare populatedstatus.serverCount/status.serversare unsetSERVERSvalueOperators then think the group has no members, even though vMCP discovery and the CR status both know about the proxies.
Steps to reproduce
MCPGroup(empty spec is enough).MCPRemoteProxyobjects withspec.groupRef.namepointing at that group. Do not add anyMCPServer.Expected behavior
The default table should show how many members the group actually has.
Either:
SERVERS=serverCount + remoteProxyCount(and document that), orPROXIES/MEMBERSprinter column, orserverCountto the total member count (and keep the typed lists separate).Actual behavior
CRD printer columns (v1beta1):
Observed status on a proxy-only group:
kubectl get mcpgroupsshowsSERVERSblank for that group, and a non-zero count only for groups that ownMCPServerobjects.Environment (if relevant)
Additional context
MCPServersCheckedis True and the message says it listed MCPServers, MCPRemoteProxies, and MCPServerEntries — so the controller already walks proxies. Only the printer column /serverCountfield lags behind.Related (closed): #4617 (Ready column used the wrong condition), #4541 (Ready column on MCPRemoteProxy).
No credentials or private hostnames in this report.