Discover and Assess Kubernetes Clusters using Azure AI Agents and Model Context Protocol (MCP)

In this blog, we will explore how to: 

• Set up a Kubernetes MCP Server using Node.js 

• Build an Azure AI agent using Semantic Kernel that interacts with this server 

• Expose it in a conversational UI using Chainlit 

 

What is Semantic Kernel? 

Semantic Kernel is an open-source SDK from Microsoft that lets you build intelligent agents using LLMs like OpenAI, Azure OpenAI, and Hugging Face, combined with traditional code and plugins. It enables hybrid reasoning, tool invocation, memory, and multi-step planning—all orchestrated through AI-driven conversations or APIs. 

Key features: 

• Plugin system to extend LLMs with real tools (like REST APIs or MCP servers) 

• Memory and planner modules for long-term context and goals 

• Python, C#, and JavaScript support 

 

What is Chainlit? 

Chainlit is an open-source framework to quickly build chat UIs for LLM applications. It allows you to: 

• Serve LLM agents (like those built with Semantic Kernel) 

• Maintain conversational memory per session 

• Visualize intermediate actions and tool calls 

Chainlit makes LLMs and agents easy to demo, debug, and deploy. 

 

What is Model Context Protocol? 

MCP lets you “control” and connect AI models to different tools, apps, and data sources, all in a standard way.

Instead of every AI system needing its own special setup, MCP gives everything a common language so they can work together smoothly.

If you're using AI to do real tasks—like answering questions, planning steps, analyzing data, or running tools—it needs access to the right information and actions at the right time.

MCP helps by:

• Giving AI access to pre-connected tools and services
• Letting you switch between AI providers easily
• Keeping your data safe and private, by running everything within your own walls (your infrastructure)

MCP plugins can be local (stdio) or remote (http), and easily integrated into agents. 

 

Use Case: Kubernetes Discovery and Assessment Agent 

We want to build an agent that can: 

• Use a Kubernetes MCP plugin to gather live cluster data
• Generate a Markdown report summarizing: 
  • Namespaces 
  • Deployments, Services, Pods 
  • Node resources (CPU, memory) 
• Serve that agent via Chainlit UI 

MCP Server for Kubernetes 

To enable intelligent Kubernetes exploration via MCP, you need a server that translates Kubernetes APIs into tools exposed to the LLM agent. Here are the two primary implementations:

Official Azure MCP Kubernetes Server 

• GitHub: Azure/mcp-kubernetes 
• Description: This official implementation from Microsoft provides a Kubernetes MCP server that uses kubectl to interact with Kubernetes clusters. It supports common cluster introspection tasks and provides a secure, production-ready setup. 
• Capabilities:
  • listNamespaces: Get all namespaces
  • listDeployments, listServices, listPods: View workload breakdown
  • getClusterInfo, getNodeMetrics: Show CPU/memory/usage/node info
  • Designed to run continuously or on demand via HTTP/MCP clients

Community MCP Kubernetes Server (Flux159) 

• GitHub: Flux159/mcp-server-kubernetes 
• Officially listed on the MCP Integrations Registry 
• Description: A lightweight MCP server for Kubernetes that uses kubectl under the hood and communicates over stdio.

In this blog post we are using Flux159/mcp-server-kubernetes.

This MCP server exposes tools like: 

• Unified kubectl API for managing resources
  • Get or list resources with kubectl_get
  • Describe resources with kubectl_describe
  • List resources with kubectl_get
  • Create resources with kubectl_create
  • Apply YAML manifests with kubectl_apply
  • Delete resources with kubectl_delete
  • Get logs with kubectl_logs
  • Manage kubectl contexts with kubectl_context
  • Explain Kubernetes resources with explain_resource
  • List API resources with list_api_resources
  • Scale resources with kubectl_scale
  • Update field(s) of a resource with kubectl_patch
  • Manage deployment rollouts with kubectl_rollout
  • Execute any kubectl command with kubectl_generic
  • Verify connection with ping

Agent Setup: Semantic Kernel + MCP Plugin 

Here's the full Python code to create the Kubernetes agent: 

import os
import semantic_kernel as sk
from semantic_kernel.connectors.ai.open_ai import AzureChatCompletion
from semantic_kernel.connectors.mcp import MCPStdioPlugin
from semantic_kernel.agents import ChatCompletionAgent
from semantic_kernel.functions import kernel_function
import utilities as util

REPORT_DIR = "./ClusterReports/"
kube_discovery_plugin = None  # Keep global reference alive

class ClusterReportPlugin:
    def __init__(self):
        pass

    Kernel_Function(
        name="generate_cluster_summary",
        description="Generate a detailed Markdown summary of the Kubernetes cluster and save it to a file."
    )
    def generate_cluster_summary(self, summary_markdown: str, save_file: bool) -> str:
        if save_file:
            os.makedirs(REPORT_DIR, exist_ok=True)
            file_path = os.path.join(REPORT_DIR, "cluster_summary.md")
            util.write_to_file_md(file_path, summary_markdown)
            return f"Cluster summary document generated: `{file_path}`"
        else:
            return summary_markdown


async def create_kubernetes_discovery_agent(
    instructions: str,
    deployment_name: str,
    endpoint: str,
    api_key: str
) -> ChatCompletionAgent:
    """
    Create an agent that uses MCP to discover Kubernetes cluster resources
    and can write a summary document.
    """

    global kube_discovery_plugin

    kernel = sk.Kernel()

    # Add Azure OpenAI completion service
    kernel.add_service(
        AzureChatCompletion(
            service_id="default",
            deployment_name=deployment_name,
            endpoint=endpoint,
            api_key=api_key
        )
    )

    # Initialize and start the MCP plugin
    kube_discovery_plugin = MCPStdioPlugin(
        name="kubernetes",
        description="Kubernetes discovery plugin",
        command="npx",
        args=["mcp-server-kubernetes"]
    )
    await kube_discovery_plugin.__aenter__()  

    # Register plugins
    kernel.add_plugin(kube_discovery_plugin, plugin_name="kubernetes_discovery_plugin")
    kernel.add_plugin(ClusterReportPlugin(), plugin_name="cluster_report_plugin")

    return ChatCompletionAgent(
        kernel=kernel,
        name="KubernetesDiscoveryAgent",
        description="Discovers Kubernetes namespaces, pods, services, images, and generates cluster summary document.",
        instructions=instructions
    )

 

Integration with Chainlit 

To serve this agent with a user-friendly chat UI, we can use Chainlit: 

import chainlit as cl 

@cl.on_chat_start 
async def start(): 
    agent = await create_kubernetes_discovery_agent( 
        instructions="You are a Kubernetes discovery assistant...", 
        deployment_name="gpt4", 
        endpoint="https://<your-azure-openai-endpoint>", 
        api_key="<your-azure-openai-key>" 
    ) 
    cl.user_session.set("agent", agent) 

@cl.on_message 

async def on_message(message): 
    agent = cl.user_session.get("agent") 
    response = await agent.complete(message.content) 
    await cl.Message(content=response).send() 

Run your app: 

chainlit run main.py -w

 

 

We have an AKS cluster hosted on Azure and deployed sample application from this Github Repository:
Kubernetes-Sample-App-Repo

Example Prompt

> Discover all workloads, services, and resources in the microservices-demo-dev namespace of the cluster and generate a detailed discovery report and save it to a file. Additionally, provide the information about the dependencies between the apps.

Agent will: 

• Call the Kubernetes MCP plugin tools 

• Summarize data using gpt-4o model 

• Save or display the output 

Output: Discovery Report: Source Cluster Information for `microservices-demo-dev` Namespace 

1. Workloads

The microservices-demo-dev namespace contains the following workloads:

Microservice	Deployment	Replicas	Pod	Service	Port
Cart Service	cartservice	1	cartservice-666bc7b84b-s6pl6	cartservice	7070 gRPC
Checkout Service	checkoutservice	1	checkoutservice-7768546cc4-zmbnt	checkoutservice	5050 gRPC
Currency Service	currencyservice	1	currencyservice-7fbc7898cc-gjtg7	currencyservice	7000 gRPC
Email Service	emailservice	1	emailservice-7d6dbd64b9-bt2jk	emailservice	5000 gRPC
Frontend	frontend	1	frontend-549c68c989-vkw88	frontend	80 HTTP
Payment Service	paymentservice	1	paymentservice-588c97ddc9-sg57b	paymentservice	50051 gRPC
Product Catalog Service	productcatalogservice	1	productcatalogservice-6cdf469784-kp7hp	productcatalogservice	3550 gRPC
Recommendation Service	recommendationservice	1	recommendationservice-c577fc58d-47p4x	recommendationservice	8080 gRPC
Redis Cart	redis-cart	1	redis-cart-849fdc46f6-9zc65	redis-cart	6379 Redis
Shipping Service	shippingservice	1	shippingservice-5bcf7d5cbc-p8tjh	shippingservice	50051 gRPC

2. Pod Status

• Total Deployments: 10 (All in Running State)
• Total Pods: 10 (Correlating to deployments)
• Dynamic Workloads: The namespace doesn't contain any CronJobs or Jobs.

3. App Dependencies

The application services intercommunicate primarily via gRPC, with the following dependencies:

• Frontend: Acts as the main entry point for users. Depends on:
  • CartService
  • ProductCatalogService
  • RecommendationService
  • ShippingService
• CartService:
  • Retrieves cart details and interacts with RedisCart.
• CheckoutService:
  • Communicates with CartService, PaymentService, ShippingService, and other components during the checkout process.
• CurrencyService:
  • Provides currency conversion rates.
• EmailService:
  • Sends notifications after successful orders.
• PaymentService:
  • Handles payment transactions. Independent microservice.
• ProductCatalogService:
  • Retrieves product details. Independent microservice.
• RecommendationService:
  • Provides product recommendations. Independent microservice.
• RedisCart:
  • Stores cart data (used by CartService).
• ShippingService:
  • Calculates shipping costs and stores related information.

4. Observations and Analysis

• The architecture is composed of modular microservices.
• Multiple gRPC-based communications between services ensure efficient internal interactions.
• Centralized databases (RedisCart) and services (Frontend, etc.) are pivotal as transaction hubs.

Benefits 

• No direct kubectl commands needed 

• Fully automated and conversational 

• Easily extensible for Helm, CRDs, or metrics 

• Works across any Kubernetes cloud (AKS, EKS, GKE) 

 

Conclusion 

Using MCP with Semantic Kernel, we can build rich agents that reason across live infrastructure like Kubernetes. Integrating this into Chainlit enables an intuitive chat interface for powerful AI-driven DevOps workflows. 

This is a foundational pattern to extend with: 

• Helm chart deployments 

• Health checks and alerts 

Let your agents talk to your cloud, the smart way!