Skip to main content
Welcome back. In this lesson we’ll run an automated label-audit against a Kubernetes cluster using the MCP (Multi-Cluster Proxy) agent. The audit is performed by a small Python script, label_auditor.py, which calls an LLM-backed ReAct-style agent via the MCP client. The agent enumerates namespaces and resources, inspects labels, flags missing governance labels (owner and cost-center), and returns a human-friendly summary. Below is the script used for this audit (complete and ready to run):
Key points about the script:
  • The prompt directs the agent to use only data returned by the MCP/Kubernetes tools (no hallucination).
  • max_tokens=2048 is set because the agent will both receive rich tool outputs and must return a detailed audit.
  • The script uses asyncio.run(...), so Python 3.7+ is required.
Before running the script, ensure your MCP server is running and reachable (for example at http://localhost:8000/mcp), and that your virtual environment includes the required packages. The script expects mcp_client.run_agent to be available.
Running the script in your terminal:
Representative logs (sanitized and consolidated) that show the interaction with MCP and the LLM:
How the audit flow works (step-by-step):
  1. The script connects to the configured MCP server and discovers available tools (e.g., kubectl_get, kubectl_describe).
  2. It lists all namespaces, filters application namespaces (skips kube-* and local-path-storage), and for each application namespace runs:
    • kubectl get for deployments, configmaps, and persistentvolumeclaims (JSON output).
    • kubectl describe for individual resources where more label metadata is required.
  3. The collected tool outputs are sent to the LLM via chat/completions; the LLM analyzes the data and produces:
    • A per-resource registry of labels as returned by the tools.
    • Flags for resources missing owner or cost-center.
    • A plain-English summary of findings.
Below is a representative audit report produced by the agent. This output is derived only from the tool responses returned by MCP; the agent formats and summarizes those results.

Kubernetes Resource Labels — FinOps Governance Audit Report

Executive Summary

This audit inspected 30 Kubernetes resources across 6 application namespaces (airline, booking-api, default, flight-search, inventory, payment) to check for required FinOps labels. The focus was on two required labels used for cost allocation and ownership: owner and cost-center.

Detailed Resource Inventory

NAMESPACE: airline


NAMESPACE: booking-api

Namespace Summary: 4 resources, 4 flagged (100% missing owner label)

NAMESPACE: default

Namespace Summary: 5 resources, 5 flagged (100% non-compliant)
Namespace Summary: 4 resources, 4 flagged (100% non-compliant)

NAMESPACE: inventory

Namespace Summary: 4 resources, 1 flagged (75% compliant)

NAMESPACE: payment


Observations and recommended next steps:
  • The agent-produced report provides a quick first-pass inventory and highlights missing labels. Because the agent is restricted to using only returned tool data, results are limited to what Kubernetes APIs returned.
  • For consistent, audit-ready checks, pair the agent output with a machine-readable tagging policy (a ruleset). That enables deterministic checks and easy enforcement across teams.
  • Next, we will show how to merge agent-collected label data with an explicit tagging policy so you can produce deterministic, actionable reports (and drive automated remediation or alerts).
That’s it for this lesson — you now have a compact script and workflow to audit Kubernetes labels via an MCP-connected ReAct agent.

Watch Video

Practice Lab