Skip to main content
Welcome back. In this walkthrough we’ll start a standalone MCP server in a Docker container and validate that it can reach a local kind Kubernetes cluster. The steps below assume you already have kind, Docker, and kubectl installed and that a cluster (for example, finops-cluster) is running.

​
1) Confirm kubectl connectivity and namespaces

First, verify that kubectl can communicate with the cluster and that the expected namespaces are present:
Example output:
If kubectl cannot reach the cluster, fix your kubeconfig or ensure the kind cluster is running before continuing.

​
2) Verify and pull the MCP image

The MCP image is published on Docker Hub as mcp/kubernetes:latest. The repository is MIT licensed and its README documents included tools and usage. Optional: verify the image signature using cosign before pulling:
Now pull the image:
Example output:

​
3) Prepare a container-reachable kubeconfig

By default your kubeconfig may reference localhost (or other host-local addresses). That works from the host machine but not from inside a container. For kind, generate a kubeconfig that uses the internal Docker network address so containers attached to the kind network can reach the API server:
This writes /tmp/kubeconfig-docker.yaml whose server address is reachable from containers on the kind network.
Tip: If you later run MCP as a Kubernetes pod inside the same cluster, the pod’s in-cluster configuration will handle API access for you and you won’t need to rewrite kubeconfig.
Warning: The kubeconfig file contains cluster credentials. Avoid uploading or sharing it publicly and prefer read-only mounts where possible. Remove temporary files when finished.

​
4) Run the MCP Docker container

Run MCP attached to the kind Docker network and mount the adjusted kubeconfig into the container. The command below exposes MCP on port 8000 and sets environment variables for transport and access controls:
What the important flags do: This starts the MCP server and exposes it on http://localhost:8000 on your host. The container uses the mounted kubeconfig to reach the kind cluster API.

​
5) Next steps — build and connect an agent

With MCP running, the typical next steps are:
  • Build an agent that implements the connection protocol to MCP.
  • Point the agent’s connection logic to the MCP endpoint (e.g., http://<MCP_HOST>:8000).
  • Implement request/response handling and any tool-specific integration (read-only vs. read/write behaviors, authentication, etc.).
  • Test communication between the agent and MCP and validate expected workflows.
If you need help adapting the kubeconfig or running MCP inside Kubernetes instead of Docker, I can provide commands and manifests for that scenario.

Watch Video