Demo Whiteboarding MCP Design

​

What we built so far

• An MCP layer running Supergateway that authenticates using a local kubeconfig for testing.
• The MCP is packaged and executed via Docker.
• Basic connectivity validated: the MCP can reach the Kubernetes API and return data (we used curl as a quick verification method).

​

Current interaction pattern

• Today, the MCP communicates directly with Kubernetes using raw HTTP calls (e.g., curl) to query cluster resources.
• This pattern is suitable for smoke tests, but it is not the final user-facing workflow.

# Example: query the Kubernetes API server for pods in the default namespace
curl --cacert /path/to/ca.crt \
  --header "Authorization: Bearer $(cat /path/to/token)" \
  https://<KUBERNETES_API_SERVER>/api/v1/namespaces/default/pods

​

Planned (target) interaction and end-to-end flow

1. A user sends a natural language prompt to the LLM.
2. The LLM decides to call an external tool — the MCP client — to perform specific Kubernetes API calls (for example, read labels, list pods, or inspect resources).
3. The MCP client performs the API requests against the Kubernetes cluster and returns structured results.
4. The LLM consumes the results, formats a final response, and returns it to the user.

# Pseudocode illustrating the LLM invoking an MCP tool
tool_response = mcp_client.call(
    action="read_labels",
    namespace="default",
    resource="pods",
    name="my-app-pod"
)
# LLM processes `tool_response` and generates user-facing text

​

Diagram notes

• The prompt flow goes: User → LLM → MCP → Kubernetes API.
• Responses travel back along the same path: Kubernetes → MCP → LLM → User.
• Arrows between LLM and MCP, and between MCP and Kubernetes, are bidirectional in the diagram to emphasize request/response semantics.
• MCP-specific arrows are visually distinguished to clarify which communication paths are handled by the MCP layer versus standard Kubernetes traffic.

​

Components at a glance

​

Next steps (high level)

• Implement the LLM-to-MCP tool interface so prompts can trigger Kubernetes operations via the MCP client.
• Replace brittle kubeconfig-based local testing with secure credential handling (short-lived tokens, service accounts, or a secrets manager).
• Replace curl-based tests with full LLM-driven flows and end-to-end integration tests.

​

Links and references

• Kubernetes Basics
• Kubernetes Authentication and Authorization
• Consider LLM tool-call patterns (e.g., OpenAI tool calling / custom tool integration approaches) when designing the MCP-to-LLM interface.