Cloud Native, Data & InfrastructureConference40min
M(ake) C(lusters) P(redictable): AI-Powered Kubernetes Diagnostics using MCP protocol
The talk shows how to use MCP to give AI agents deterministic Kubernetes troubleshooting tools instead of cluster access. It covers Forge MCP, tool selection, an end-to-end investigation prompt, and Azure SSO-based authorization. Key message: give the agent tools, not kubeconfig.
talk.summaryAiDisclaimer
Athanasios NtavelisXM
talkDetail.whenAndWhere
Friday, November 20, 11:30-12:10
Room 2 - Alexandros
talks.roomOccupancytalks.noOccupancyInfo
Every Kubernetes incident starts with the same ritual: get pods, logs, describe, events, HPA, quota, Helm history. You know the sequence.
Using MCP, we can hand that sequence to an AI agent as deterministic tools. Each one runs our code and returns predictable output, so nothing about the investigation is left to the model to improvise. Our code holds the cluster connection and makes every call. The agent never sees a credential, a kubeconfig, or a shell.
We'll walk through Forge MCP, an internal Model Context Protocol server. How the agent picks which tool to use, and one well-defined MCP prompt that runs an end-to-end Kubernetes investigation on a specific namespace and deployment. Then how each tool call is authorized against the caller's Azure SSO identity before it reaches our code, so we control which tools each employee can use. Live demos from various MCP clients.
Our operating principle: give the agent the tools, not the kubeconfig.
Key takeaways
- Why a declared tool contract beats giving a model shell access.
- Why the tool description is the most consequential code in the repo.
- How to authorize tool calls against the caller's SSO identity, so each engineer gets their own tool list.
Target audience
DevOps, platform and SRE engineers who run Kubernetes and are being asked what their team is doing about AI, plus anyone who needs an AI integration to pass a security review. Comfort with kubectl and Helm is enough, no machine learning background needed.
Using MCP, we can hand that sequence to an AI agent as deterministic tools. Each one runs our code and returns predictable output, so nothing about the investigation is left to the model to improvise. Our code holds the cluster connection and makes every call. The agent never sees a credential, a kubeconfig, or a shell.
We'll walk through Forge MCP, an internal Model Context Protocol server. How the agent picks which tool to use, and one well-defined MCP prompt that runs an end-to-end Kubernetes investigation on a specific namespace and deployment. Then how each tool call is authorized against the caller's Azure SSO identity before it reaches our code, so we control which tools each employee can use. Live demos from various MCP clients.
Our operating principle: give the agent the tools, not the kubeconfig.
Key takeaways
- Why a declared tool contract beats giving a model shell access.
- Why the tool description is the most consequential code in the repo.
- How to authorize tool calls against the caller's SSO identity, so each engineer gets their own tool list.
Target audience
DevOps, platform and SRE engineers who run Kubernetes and are being asked what their team is doing about AI, plus anyone who needs an AI integration to pass a security review. Comfort with kubectl and Helm is enough, no machine learning background needed.
Athanasios Ntavelis
Athanasios Ntavelis is a DevOps engineer at XM who started his career as a software engineer. With 12 years of experience across PHP, Go, Kubernetes and AWS, he leads a team of 18 engineers. His experience ranges from how a Go application handles termination signals to how to deploy a Kubernetes cluster on AWS with Terraform. These days he focuses on automating every part of the release pipeline and infrastructure provisioning, mentoring engineers, and defining the process his team runs on.