[BUG] RemoteMCPServer should be disabled when kagent-tools is disabled

[Sartigan]

📋 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

🐛 Bug Description

In the helm chart, it is possible to disable kagent-tools using .Values.kagent-tools.enabled: false

However the template for the default RemoteMCPServer still exists and there are no conditions or anything to disable it.

I think adding an if Statement on .Values.kagent-tools.enabled should be done in the template

https://github.com/kagent-dev/kagent/blob/main/helm/kagent/templates/toolserver-kagent.yaml

🔄 Steps To Reproduce

Install the helm chart with the kagent-tools disabled causes the controller to constantly output error about the RemoteMSCPServer being invalid.

Because there are no way to disable the RemoteMCPServer connected to the kagent-tools, this is a bug.

🔍 Additional Context

The default RemoteMCPServer should not be deployed when kagent-tools is disabled

📋 Logs

{"level":"error","ts":"2026-01-26T20:19:21Z","logger":"reconciler","msg":"failed to upsert tool server for remote mcp server","remoteMCPServer":"kagent-system/kagent-tool-server","error":"failed to fetch tools for toolServer kagent-system/kagent-tool-server: failed to connect client for toolServer kagent-system/kagent-tool-server: calling \"initialize\": rejected by transport: sending \"initialize\": Post \"http://kagent-tools.kagent-system:8084/mcp\": dial tcp: lookup kagent-tools.kagent-system on 10.43.0.10:53: no such host","stacktrace":"github.com/kagent-dev/kagent/go/internal/controller/reconciler.(*kagentReconciler).ReconcileKagentRemoteMCPServer\n\t/workspace/internal/controller/reconciler/reconciler.go:415\ngithub.com/kagent-dev/kagent/go/internal/controller.(*RemoteMCPServerController).Reconcile\n\t/workspace/internal/controller/remote_mcp_server_controller.go:49\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Reconcile\n\t/root/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.23.0/pkg/internal/controller/controller.go:222\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).reconcileHandler\n\t/root/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.23.0/pkg/internal/controller/controller.go:479\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).processNextWorkItem\n\t/root/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.23.0/pkg/internal/controller/controller.go:438\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Start.func1.1\n\t/root/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.23.0/pkg/internal/controller/controller.go:313"}

🙋 Are you willing to contribute?

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

[onematchfox]

I think adding an if Statement on .Values.kagent-tools.enabled should be done in the template

Whilst this would solve the problem, I think a better solution would be to move the resource to the tools Helm chart. That way we could also ensure that the url is always correctly set (since this ultimately relies on the template used to generate the fullname and namespace of the tools deployment).

Related to #1192

[EItanya]

I think adding an if Statement on .Values.kagent-tools.enabled should be done in the template

Whilst this would solve the problem, I think a better solution would be to move the resource to the tools Helm chart. That way we could also ensure that the url is always correctly set (since this ultimately relies on the template used to generate the fullname and namespace of the tools deployment).

Related to #1192

I agree and disagree. Technically the tools server doesn't rely on kagent, so shipping the kagent CR in there could be confusing. Another option could be to just switch to an MCPServer resource instead of the RemoteMCPServer

[onematchfox]

Technically the tools server doesn't rely on kagent, so shipping the kagent CR in there could be confusing.

I get your point. However, the pattern of installing external CRDs as part of a "product" Helm chart is fairly well established. As an example, I wouldn't expect to be able to install Prometheus ServiceMonitor resources for, say ArgoCD, as part of the install of Prometheus itself. Instead I expect to be able to do this when installing ArgoCD - even though ArgoCD doesn't rely on Prometheus¹. You'll find plenty other examples in the wild related to resources for other common services like Istio, Gateway API, etc. etc.

Footnotes

1. Note the use of .Capabilities.APIVersions.Has in the template linked above (alongside .values.xxx.enabled). This ensures that the resource is only rendered if the cluster has the appropriate CRD installed. ↩