mait.sh1.132.1

Private beta: features and content may change. No warranty; use at your own risk.

Install and configure mcp-kubectl

Connect MCP Kubectl to your cluster, check it yourself, then let your agent ask the same cluster a question.

Beta
MCP Kubectl

Examples are illustrative; names, counts, tool responses and agent wording vary. Check the actual result in your intended cluster.

Steps

Five steps from install to your first cluster question.

MCP Kubectl is an MCP tool: you point it at a cluster, check it, and then ask in plain language. It needs a cluster you can already reach, and no root access.

  1. Choose the cluster
    $ export KUBECONFIG=/path/to/kubeconfig
    Step 1 of 5

    Point it at a cluster

    mcp-kubectl has no configuration file of its own. It uses the file named by KUBECONFIG, or ~/.kube/config, or in-cluster credentials when it runs inside a pod.

    What you get

    A cluster identity chosen once, which both the agent and you will use.

  2. Illustrative
    Check the version
    $ mcp-kubectl version
    mcp-kubectl X.Y.Z
    Step 2 of 5

    Check that it arrived

    The MAIT image ships mcp-kubectl and updates it with the image. The check needs no cluster credentials.

    What you get

    The program answers with its version.

  3. Illustrative
    Read pods as the operator
    $ mcp-kubectl cli get pods -n shop
    NAME READY STATUS RESTARTS AGE
    api-7c9d8f5b6c-m4h2p 1/1 Running 0 2d
    web-5d8f7c9b6d-x2k4q 2/2 Running 0 1d
    Step 3 of 5

    Read the cluster yourself

    Pass the namespace explicitly. This example is trimmed to a few rows.

    A Forbidden answer means your identity lacks permission, not that the namespace is empty.

    What you get

    Proof that the identity reaches the cluster, from the operator commands.

  4. mcpServers entry
    {
      "mcpServers": {
        "kubectl": {
          "command": "mcp-kubectl",
          "args": ["serve"],
          "env": { "KUBECONFIG": "/path/to/kubeconfig" }
        }
      }
    }
    Illustrative conversation
    YouIs the web deployment in shop healthy, and are the nodes ready?
    Tool callkubectl_deploy_status { "deployment": "web", "namespace": "shop" }
    What happensreplicas 1, ready_replicas 1, updated_replicas 1, available_replicas 1, status healthy.
    Tool callkubectl_cluster_health {}
    What happenstotal_nodes 1, ready_nodes 1, not_ready_nodes 0, status healthy.
    AgentThe web deployment has its one replica ready, and the one node is ready.
    Step 4 of 5

    Connect it to your agent and ask

    Any client that accepts an mcpServers launch entry uses this shape. Set KUBECONFIG in the entry rather than assuming the client inherits your terminal export, place it where your client keeps server configuration and restart the client.

    If you reach your tools through the registry instead, add kubectl once with mcp_registry_add and the tools carry the kubectl__ prefix (registry guide). Then ask in plain language.

    What you get

    An answer from the live cluster, as fields the agent reads directly.

  5. Illustrative conversation
    YouDelete the crashing pod.
    What happensThe tool list holds kubectl_get_pod_status, kubectl_deploy_status, kubectl_cluster_health and kubectl_resource_summary, and nothing that changes the cluster.
    Tool callkubectl_delete_pod { "name": "x" }
    What happensInvalid arguments: Tool not found: kubectl_delete_pod
    AgentI cannot delete anything with this server. You can run the delete yourself with the cli commands.
    Step 5 of 5

    See the boundary

    The client lists exactly four tools, and all of them read. Asking the server for a delete tool fails.

    What you get

    Four inspection tools from this server. Changes through mcp-kubectl cli or other agent capabilities remain subject to your permissions and task controls.

Result

Cluster inspection through four read-only tools.

You confirmed the program, your cluster access and an agent answer from the same cluster identity. Pass an explicit namespace to every call: when you leave it out, pod and deployment tools use the configured namespace, which may itself be default; resource summary instead counts literal default. There is no retry in another namespace when a resource is not found.

Next

Where to go next.