Summary

MCPRemoteProxy only supports inline telemetry configuration, unlike MCPServer which supports both inline and reference-based telemetry. This means MCPRemoteProxy users cannot reference a shared MCPTelemetryConfig resource and must duplicate inline telemetry configuration across every instance.

Severity: SHOULD FIX
Area: CRD API Consistency
Breaking: No

Location

• cmd/thv-operator/api/v1alpha1/mcpremoteproxy_types.go:97-99

Problem

MCPRemoteProxy:

Telemetry *TelemetryConfig `json:"telemetry,omitempty"`

MCPServer (supports both patterns):

Telemetry          *TelemetryConfig    `json:"telemetry,omitempty"`
TelemetryConfigRef *TelemetryConfigRef `json:"telemetryConfigRef,omitempty"`

Impact

• Configuration duplication across MCPRemoteProxy instances
• Cannot use centralized MCPTelemetryConfig resources for remote proxies
• Inconsistency with MCPServer API, which supports both patterns
• If the inline Telemetry field is deprecated (as the MCPServer pattern suggests), MCPRemoteProxy has no migration path

Recommended Fix

1. Add TelemetryConfigRef to MCPRemoteProxySpec:

   // TelemetryConfigRef references a shared MCPTelemetryConfig.
   // +optional
   TelemetryConfigRef *TelemetryConfigRef `json:"telemetryConfigRef,omitempty"`

2. Add CEL validation for mutual exclusivity (matching MCPServer pattern):

   // +kubebuilder:validation:XValidation:rule=
   //   "!(has(self.telemetry) && has(self.telemetryConfigRef))",
   //   message="telemetry and telemetryConfigRef are mutually exclusive"

3. Deprecate the inline Telemetry field to match the MCPServer migration direction.

Related Issues

• MCPRemoteProxy missing Replicas field — another MCPRemoteProxy API gap