Skip to main content
Welcome back. This lesson walks through the small but important code changes that enable our FinOps agent to interact with the tracker MCP so it can create and list issues. The update enforces a structured prompt, restricts the agent tool surface, and wires in a tracker MCP endpoint so the agent produces one ticket per non-compliant resource and then lists issues. Start by opening the repository at the 08 folder, then the agents folder and inspect tracker_auditor.py:
A screenshot of a GitHub repository page showing the "sections" folder and a list of subfolders (00-course-introduction, 01-cluster-foundation, 02-airline-app-deployment, etc.) with last commit messages and dates. The browser window and repository file tree are visible on the left.
Open tracker_auditor.py. This file contains the agent prompt, the allowed tools set, the tagging rules loader, and a small async entrypoint that calls run_agent from mcp_client.py. Below is a cleaned, complete, and corrected excerpt of tracker_auditor.py showing the enforced prompt structure and how tagging rules are loaded and forwarded:
Key behaviors implemented in this file
  • ALLOWED_TOOLS intentionally limits the agent to kubectl_get, create_issue, and list_issues. This focuses agent steps on creating tickets rather than exploring other resources.
  • The PROMPT is prescriptive and scoped to exactly one kubectl_get call: deployments in the payment namespace. The prompt enforces the tagging evaluation logic and requires one create_issue call per non-compliant Deployment.
  • Tagging rules are read from tagging-rules.yaml and passed into the agent as a system-level policy message (see later), ensuring consistent evaluation.
Next, the tracker MCP wiring is implemented in mcp_client.py. The snippet below shows environment loading, default MCP URLs, and the MCP_SERVERS mapping that now includes a tracker entry using SSE transport:
Why this matters
  • Adding the tracker entry enables the client to route create/list issue operations to the tracker MCP at TRACKER_MCP_URL. The SSE transport supports streaming updates from the tracker if needed.
  • Environment variables allow overriding defaults for local and CI environments (K8S_MCP_URL, TRACKER_MCP_URL).
One important implementation detail: the tagging rules YAML is delivered to the LLM as a SystemMessage so the model treats it like policy. The code below (excerpted and corrected) shows how tools are filtered by allowed_tools, how tagging rules are injected as system-level content, and how the agent is invoked:
The tagging rules YAML is embedded as a system message so the LLM evaluates labels strictly according to that YAML. This avoids the model inventing extra policy or exclusions.
Quick reference — files and responsibilities Run and verify
  1. Ensure your environment variables are set (for example in .env): OPENAI_API_KEY, optionally K8S_MCP_URL, TRACKER_MCP_URL.
  2. Start your MCP services (k8s MCP and tracker MCP).
  3. Run the auditor: python tracker_auditor.py.
  4. The script prints a verification hint: “Done. Verify tickets at http://localhost:8085”. Confirm the tracker UI shows created tickets.
  5. The agent must issue one create_issue call per non-compliant Deployment in the result set and call list_issues exactly once before stopping.
Important: The agent is intentionally restricted. If MCP tools required by ALLOWED_TOOLS are not available, run_agent will raise an error. Make sure the tracker MCP service is reachable at TRACKER_MCP_URL.
Why these changes improve the system
  • Structured prompt: Forces a predictable plan (collect → evaluate → create tickets → list issues), which reduces hallucination and ensures consistent ticket creation.
  • Small tool surface: By restricting tools, the agent focuses on remediation (creating issues) rather than additional discovery.
  • System-level tagging rules: Passing policy as a SystemMessage ensures the LLM evaluates resources according to authoritative YAML, preventing ad-hoc judgments.
  • Tracker MCP integration: Enables end-to-end ticket creation and verification against a dedicated tracker service.
References That covers the code changes and how they work together to produce actionable tickets from non-compliant Deployments. See you in the next lesson.

Watch Video