[BUG] Status for secondary/watched tool server resources (`Service`/`MCPServer`) are not reflected in cluster

[onematchfox]

📋 Prerequisites

• I have searched the existing issues to avoid creating a duplicate
• By submitting this issue, you agree to follow our Code of Conduct
• I am using the latest version of the software
• I have tried to clear cache/cookies or used incognito mode (if ui-related)
• I can consistently reproduce this issue

🎯 Affected Service(s)

Controller Service

🚦 Impact/Severity

Minor inconvenience

🐛 Bug Description

When adding a "autodiscovered" tool server via a Service/MCPServer resource, the status of the reconciled resource is not reflected in cluster. The reconciliation loop for both secondary resources simply upserts to the controller database. Thus, if an error occurs, the only place to find any information about this is within the controller logs.

🔄 Steps To Reproduce

Add a misconfigured secondary tool server resource (e.g. a Service that has an incorrect kagent.dev/mcp-service-portor kagent.dev/mcp-service-protocol annotation) and attempt to find out why no tools are listed in the UI.

🤔 Expected Behavior

The status of all resources managed by the controller should be reflected within the Kubernetes cluster.

📱 Actual Behavior

No response

💻 Environment

No response

🔧 CLI Bug Report

No response

🔍 Additional Context

This was originally discussed/reported in #812 (comment) but I never got around to actually logging an issue with this until now.

📋 Logs

📷 Screenshots

No response

🙋 Are you willing to contribute?

• I am willing to submit a PR to fix this issue

[EItanya]

@onematchfox I agree with you here, I think we need to design the correct implementation here. Let's take the Service for example, where do you think we should put the information on said Service?

[onematchfox]

Let's take the Service for example, where do you think we should put the information on said Service?

Since we can't update the Service itself, the only thing I can think of is creating an owned CRD that reflects whatever is stored in the database (the resolved "Tool Server"). Given that the code already converts the Service into a RemoteMCPServer we could use that CRD. 🤷 Or, we bring back ToolServer but, if we do this then why would we keep RemoteMCPServer around?