The agents page invites building and contributing agents to the registry. All current agents under helm/agents/ use the built-in tools — so before opening a PR I would like to ask: would you welcome a community agent that depends on an external (read-only, no-credential) MCP server?
Concretely: a release-triage agent that flags which CNCF components in the cluster need action, backed by ratatosk-mcp. It answers questions like "we run kubernetes v1.36.0 and cilium v1.17.18 — anything that needs action before we upgrade?" with severity-ranked facts, each carrying a verbatim quote from the release note and a source URL. The check_stack tool compares running versions locally, so cluster versions never leave the process.
Shape-wise it would follow the helm/agents/ chart pattern; the agent chart would be self-contained (server Deployment + RemoteMCPServer + Agent), needs no RBAC or secrets, runs clean under PSS restricted, and the setup is verified on a live kagent cluster (manifests, also available as a kagent.enabled toggle in our own chart).
Full disclosure: I am the author of the MCP server. If external-dependency agents are not a fit for the registry, no problem at all — it lives happily in our own repository, and a pointer on where such integrations belong would already help. Thanks!
The agents page invites building and contributing agents to the registry. All current agents under
helm/agents/use the built-in tools — so before opening a PR I would like to ask: would you welcome a community agent that depends on an external (read-only, no-credential) MCP server?Concretely: a release-triage agent that flags which CNCF components in the cluster need action, backed by ratatosk-mcp. It answers questions like "we run kubernetes v1.36.0 and cilium v1.17.18 — anything that needs action before we upgrade?" with severity-ranked facts, each carrying a verbatim quote from the release note and a source URL. The
check_stacktool compares running versions locally, so cluster versions never leave the process.Shape-wise it would follow the
helm/agents/chart pattern; the agent chart would be self-contained (server Deployment + RemoteMCPServer + Agent), needs no RBAC or secrets, runs clean under PSSrestricted, and the setup is verified on a live kagent cluster (manifests, also available as akagent.enabledtoggle in our own chart).Full disclosure: I am the author of the MCP server. If external-dependency agents are not a fit for the registry, no problem at all — it lives happily in our own repository, and a pointer on where such integrations belong would already help. Thanks!