> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Demo Start and Validate MCP

> Walkthrough to run an MCP server in Docker, configure container-accessible kubeconfig for a kind cluster, pull and run the image, and validate connectivity.

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:

```bash theme={null}
kubectl get ns
```

Example output:

```bash theme={null}
NAME                 STATUS   AGE
airline              Active   3h29m
booking-api          Active   3h29m
default              Active   3h29m
flight-search        Active   3h29m
inventory            Active   3h29m
kube-node-lease      Active   3h29m
kube-public          Active   3h29m
kube-system          Active   3h29m
local-path-storage   Active   3h29m
payment              Active   3h29m
```

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:

```bash theme={null}
COSIGN_REPOSITORY=mcp/signatures \
cosign verify mcp/kubernetes --key https://raw.githubusercontent.com/docker/keyring/refs/heads/main/public/mcp/latest.pub
```

Now pull the image:

```bash theme={null}
docker pull mcp/kubernetes:latest
```

Example output:

```bash theme={null}
latest: Pulling from mcp/kubernetes
Digest: sha256:5ffbf7f0a8aa7a58dfcf8d34807fd42a9cd7d88d88a5de88f472edfc3133af73
Status: Image is up to date for mcp/kubernetes:latest
docker.io/mcp/kubernetes:latest
```

## 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:

```bash theme={null}
kind get kubeconfig --name finops-cluster --internal > /tmp/kubeconfig-docker.yaml
```

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:

```bash theme={null}
docker run --rm -p 8000:8000 --network kind \
  -v /tmp/kubeconfig-docker.yaml:/home/appuser/.kube/config:ro \
  -e ENABLE_UNSAFE_STREAMABLE_HTTP_TRANSPORT=1 \
  -e PORT=8000 \
  -e HOST=0.0.0.0 \
  -e ALLOW_ONLY_READONLY_TOOLS=true \
  mcp/kubernetes:latest
```

What the important flags do:

| Flag | Purpose | Example |
| - | - | - |
| `--rm` | Remove the container when it exits | `--rm` |
| `-p 8000:8000` | Map container port 8000 to host port 8000 | `-p 8000:8000` |
| `--network kind` | Attach container to the `kind` Docker network so the internal kubeconfig address is reachable | `--network kind` |
| `-v /tmp/kubeconfig-docker.yaml:/home/appuser/.kube/config:ro` | Mount the adjusted kubeconfig into the container read-only | `-v /tmp/kubeconfig-docker.yaml:/home/appuser/.kube/config:ro` |
| `-e ...` | Environment variables to configure MCP behavior | `-e PORT=8000`, `-e ALLOW_ONLY_READONLY_TOOLS=true` |

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.

## Links and references

* [kind — Kubernetes in Docker (kind.sigs.k8s.io)](https://kind.sigs.k8s.io/)
* [cosign — Container image signing](https://github.com/sigstore/cosign)
* [Docker Hub — mcp/kubernetes](https://hub.docker.com/)
* [kubectl — Kubernetes CLI](https://kubernetes.io/docs/reference/kubectl/)

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](https://learn.kodekloud.com/user/courses/building-kubernetes-finops-ai-agent/module/d9a1ac50-d5f4-4cc1-a8d4-379664950054/lesson/cd48f5c9-cc82-483b-9c1f-dc42144854d6)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.