For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

Look up the MCP server that a kagent installation ships with, the tools that it serves, and the community servers that you can add.

A kagent installation ships with one Model Context ProtocolModel Context ProtocolAn open protocol for exposing tools and resources to a model. kagent reaches an MCP server through a RemoteMCPServer resource, and an AgentTemplate binds individual tools from it.Learn more (MCP) server already registered, and you can register more of your own. This page lists what is installed, what the installed server serves, and how to narrow the set. For the schema that binds a server to an agent, see About tools.

Server that a kagent installation registers

The kagent chart installs the tool server as a subchart, which the kagent-tools.enabled Helm value turns on. The subchart creates the kagent-tool-server RemoteMCPServerRemoteMCPServerA Kubernetes custom resource pointing at a Model Context Protocol server that the cluster can reach. It is the only server kind that an AgentTemplate tool binding accepts.Learn more in the kagent namespace. The server serves tools for Kubernetes, Helm, Istio, Cilium, Argo Rollouts, Prometheus, and Kubescape. kagent does not bind the server to an agent, so an agent reaches the server’s tools only through a tool bindingTool bindingOne entry in an AgentTemplate's spec.tools list. Each binding connects the agent to one source: tools from a Model Context Protocol server, or another AgentTemplate that takes work from it.Learn more that you add to its AgentTemplateAgentTemplateA Kubernetes custom resource defining what an agent does: its model, system prompt, tools, skills, and plugins. It runs only once an Agent pairs it with a Harness.Learn more.

The kagent release pins the kagent-tool-server version, which is currently 0.3.0. For the full set of pinned component versions, see Version support.

Read the tools that a server serves

The kagent controller connects to each RemoteMCPServer, asks the server which tools it serves, and records the answer in status.discoveredTools. That status reports the tools of the server that your cluster actually runs, so the status is more reliable than any list on this page.

kubectl get remotemcpserver kagent-tool-server -n kagent \
  -o jsonpath='{range .status.discoveredTools[*]}{.name}{"\t"}{.description}{"\n"}{end}'

For the same command as the first step of binding one of these tools to an agent, see Your first MCP tool.

Turn tool discovery off for a server

The controller lists a server’s tools with the controller’s own credentials. A server that authenticates every caller individually, such as one that expects each agent’s own propagated token, does not accept any credential that the controller can present. Discovery against that server fails. Because the listing never succeeds, the RemoteMCPServer stays un-Accepted indefinitely, even though agents can reach the server at runtime.

To resolve this issue, label the server with kagent.dev/discovery=disabled. The controller accepts the server without listing its tools, and the agents that bind it resolve the tool list at runtime with their own credentials.

kubectl label remotemcpserver <name> -n <namespace> kagent.dev/discovery=disabled

The label has the following effects on the server:

• The Accepted condition becomes True with the reason DiscoveryDisabled, rather than reporting a discovery failure.
• status.discoveredTools stays empty, so the command in Read the tools that a server serves does not return tools for this server. The server’s own documentation becomes the only list of what it offers.
• The catalog keeps the server but records it as disconnected and without tools.

kagent-tool-server

One Go binary serves every tool in this section, grouped into providers. A provider’s tools shell out to the matching command line tool inside the server’s own container, so the Kubernetes, Helm, Istio, and Cilium providers act on your cluster with the server’s ServiceAccount rather than with the caller’s credentials.

Tools marked * perform write operations, and --read-only skips them at registration. The following sections list each provider’s tools by the name that an agent sees.

Kubernetes

Agents use the Kubernetes provider the most. The provider covers both inspection and modification of any resource that kubectl can reach.

Helm

The Helm provider manages releases and chart repositories with the Helm configuration inside the server’s container, so a repository that one tool adds is available to the others.

Istio

Istio’s tools wrap istioctl, and most of them read mesh state rather than change it. Waypoint management is the exception, because generating a waypoint resource and applying it are separate tools.

Argo Rollouts

Argo Rollouts tools cover progressive delivery. A rollout tool fails confusingly when the controller or one of its plugins is missing, so several of the tools verify the installation instead of acting on a rollout.

Cilium

Cilium is the largest provider, with tools ranging from installation to individual BPF maps. An agent that can see every tool spends its context on tool descriptions, so bind only the tools that an agent needs.

Prometheus

The Prometheus provider queries a Prometheus server directly. Each tool takes the server’s URL as an argument, and that argument defaults to http://localhost:9090. The default address does not resolve from inside the tool server’s container, so have the agent pass the in-cluster address.

Kubescape

Kubescape’s tools read scan results that the Kubescape operator has already produced, so the tools do not return useful results until that operator is installed and has completed a scan. Start with kubescape_check_health, which reports whether the rest of the provider can work.

Utilities

The utility tools do not belong to any product. shell runs an arbitrary command in the server’s container with the server’s ServiceAccount, so treat it as the widest permission that this server grants.

Narrow what kagent-tool-server serves

Serving every tool costs an agent context on every turn, and the full tool set grants the server broad authority over your cluster. Independent settings narrow the server, and each one acts at a different layer.

kagent-tools:
  tools:
    enabledTools:
      - k8s
      - helm
    args:
      - "--read-only"
  rbac:
    readOnly: true
    additionalRules:
      - apiGroups: ["networking.istio.io"]
        resources: ["virtualservices", "destinationrules", "gateways"]
        verbs: ["get", "list", "watch"]

Because the settings are per-installation, they change what every agent sees. To give one agent a smaller set while leaving the server intact, list the tools on the tool binding instead, as described in About tools.

The kagent and Codex harnesses both honor this tool list. On the Claude HarnessHarnessA Kubernetes custom resource defining how an agent is allowed to run: which harness executes the agent, its workload image, and its WorkerPool and snapshot storage. An Agent pairs it with the AgentTemplate that it runs.Learn more, a tool binding’s tool list does not narrow the server, so an agent on Claude reaches every tool that kagent-tool-server serves. Narrow the server with tools.enabledTools or --read-only instead. For more information about this behavior, see Tool selection on the Claude harness.

Reach kagent-tool-server from another namespace

The chart creates the kagent-tool-server RemoteMCPServer in the release namespace, and a RemoteMCPServer admits references only from its own namespace. Where an AgentTemplate in another namespace binds the server, the controller cannot resolve the binding, and the Agent that runs that template does not become ready. To admit another namespace, set allowedNamespaces on the RemoteMCPServer that the chart creates.

kagent-tools:
  remoteMCPServer:
    allowedNamespaces:
      from: Selector
      selector:
        matchLabels:
          kagent-tools: allowed

The selector follows the Gateway API pattern for cross-namespace attachment, so the label belongs on the Namespace rather than on the AgentTemplate that binds the server.

kubectl label namespace my-agents kagent-tools=allowed

Community and contributed servers

kagent’s repository contains example servers in contrib/tools. Each server is an unsupported starting point. The manifests target different kagent API versions, so check the apiVersion before you apply one.

To register any other MCP server, write a RemoteMCPServer that points at its URL. For a complete example, see Your first MCP tool. To give agents Grafana tools, run Grafana’s own server from the upstream mcp-grafana project, and register it in the same way.

Next steps