Skip to main content
Welcome back. This lesson walks through running the FinOps audit agent to:
  • collect Deployments from a Kubernetes cluster,
  • evaluate resources against FinOps tagging rules,
  • and create issues in the issue tracker for non-compliant resources.
Prerequisites
  • Ensure your Kubernetes MCP(s) and the issue tracker service are running and reachable (Uvicorn endpoints for the tracker).
  • Confirm the tracker currently has no tickets before starting.
Quick check (tracker empty):
Ensure your MCP servers and issue tracker container are running (Uvicorn / MCP endpoints reachable) before running the audit agent. If the tracker or MCP is down, the agent cannot create tickets.
Running the auditor Execute the tracker auditor script from the project root:
Representative runtime output You should see the tracker and MCP services start, followed by the agent discovering MCP tools and connecting to MCPs. Example (condensed):
Note: You might see a deprecation warning that the tracker MCP uses SSE transport. SSE is deprecated for MCPs as of 2025-03-26 — consider migrating the tracker MCP to streamable_http.
MCP server “tracker” is using SSE transport (deprecated). Consider migrating to streamable_http to avoid future incompatibilities.
MCP discovery logs The agent will log its connections to MCP servers and list the tools available from each MCP. Kubernetes MCP example:
Tracker MCP example:
Agent execution flow The auditor performs a small, deterministic set of steps defined by its prompt. In this lesson the prompt limited the agent to a single kubectl_get call scoped to the payment namespace, then evaluated labeling compliance and created tickets. Example agent actions (condensed):
  • Request Deployments (single kubectl_get):
  • Create issues on the tracker MCP (example payload):
Run summary — first (payment-only) run The following summarized what happened during the first run (when the agent was restricted to the payment namespace):
  • Step 1 – Collected Deployments in payment: 3 found
    • payment-gateway
    • payment-gateway-api
    • payment-processor
  • Step 2 – Evaluated each Deployment against the FinOps tagging policy. None of the three contained a labels field, so required tags (owner, environment, cost-center, application, tier, slack-channel) could not be matched — all three were non-compliant.
  • Step 3 – Created 3 tickets (category: missing-labels, priority: high), one per Deployment:
    • FINOPS-0001 – payment/payment-gateway
    • FINOPS-0002 – payment/payment-gateway-api
    • FINOPS-0003 – payment/payment-processor Each ticket suggested payment-team as owner and payment as cost-center based on namespace context.
  • Step 4 – Confirmed via list_issues: 3 total issues, all in backlog, 0 estimated monthly savings recorded.
Summary table (first run) Why the agent only evaluated the payment namespace Open the Python auditor file and inspect the prompt and allowed tools. The PROMPT explicitly constrained the collection to a single kubectl_get against namespace=payment. The agent follows the prompt literally and therefore limited its scope accordingly. Relevant excerpt from the Python auditor (kept concise):
How to run the auditor across all namespaces To audit Deployments across all namespaces with a single kubectl_get, update Step 1 in the PROMPT to request all namespaces (e.g., set allNamespaces=True or remove the namespace constraint so the tool uses allNamespaces=True). Example conceptual change:
Re-run the auditor after saving the change. The agent will then collect Deployments cluster-wide in a single call and create issues for non-compliant resources across namespaces. Representative summary — all-namespaces run After changing to collect all namespaces in Step 1, a follow-up run produced the following condensed results:
  • Step 1 – Collected: 9 Deployments across all namespaces via one kubectl_get call.
  • Step 2 – Evaluated against tagging rules: 2 Deployments were excluded by excluded_namespaces (e.g., kube-system and local-path-storage); the remaining 7 had zero labels and were non-compliant.
  • Step 3 – Created 7 new tickets (in addition to the 3 pre-existing payment tickets from the prior run):
    • FINOPS-0004 — booking-api/booking-api — missing-labels — high
    • FINOPS-0005 — default/analytics-collector — missing-labels — low
    • FINOPS-0006 — flight-search/flight-search-service — missing-labels — medium
    • FINOPS-0007 — inventory/inventory-service — missing-labels — medium
    • FINOPS-0008 — payment/payment-gateway — missing-labels — critical
    • FINOPS-0009 — payment/payment-gateway-api — missing-labels — critical
    • FINOPS-0010 — payment/payment-processor — missing-labels — critical
  • Step 4 – list_issues confirmed: 10 total open tickets in backlog (0 in progress/done), all missing-labels.
Note: Some resources (e.g., payment-gateway-api) may appear duplicated across runs with slightly different metadata. Add deduplication logic in the tracker integration or agent to avoid duplicate tickets for the same resource. Next steps and operational notes
  • Triage: Engineering teams can triage issues, assign owners, estimate savings, and progress tickets (backlog → in-progress → done).
  • Remediation: Applying the required labels to Deployments resolves FinOps issues and enables cost attribution.
  • Automation: Consider deduplication, severity heuristics, and automatic reassignment rules in the tracker integration to reduce noise.
  • Architecture: Update your documentation to reflect the actual flow used here — collector agent → Kubernetes MCP(s) → LLM-based evaluation using tagging rules → issue tracker MCP → ticket board.
Links and references Congratulations — you completed the end-to-end flow: the audit agent collected cluster state, evaluated resources against FinOps tagging rules, and created actionable tickets in the issue tracker. See the tracker UI at http://localhost:8085 to review and triage created issues.

Watch Video

Practice Lab