> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Demo Launch the FinOps Issue Tracker

> Demo of a FinOps issue tracker exposing an MCP server so agents programmatically create, list, retrieve, and update tickets, with example API, Kanban UI, and integration guidance

Hello and welcome back.

This page walks through the custom FinOps issue tracker we built, how it exposes an MCP (multi-capability provider) server, and the integration points agents use to convert findings into actionable tickets. The example is intentionally self-contained so you can map the same design to any issue tracker (Jira, GitHub Issues, etc.) used in your organization.

This custom tracker is a compact, demo-friendly implementation that shows common integration patterns. You can adapt the same approach to any external issue-tracking system by replacing the storage and API bindings.

Repository snapshot

Here’s the repository view where the issue-tracker service lives. The image shows the folder structure and numbered sections used in the demo repository.

![A screenshot of a GitHub repository file view showing the "sections" directory: a left sidebar file tree and a main pane listing many numbered subfolders (00–09) with their last commit messages and dates. The browser URL and GitHub header are visible along the top.](https://mintcdn.com/kodekloud-c4ac6d9a/rjGeTDj8cr6D5YbW/images/Building-Kubernetes-FinOps-AI-Agent/From-Findings-to-Actionable-Tickets/Demo-Launch-the-FinOps-Issue-Tracker/github-repo-sections-00-09.jpg?fit=max\&auto=format\&n=rjGeTDj8cr6D5YbW\&q=85\&s=7225efbdeae2bf869ed497472383bea8)

Core design and MCP server

The issue tracker exposes a set of tools via an MCP server so an agent can programmatically create, list, retrieve, and update issues. This keeps the agent code simple — the agent calls well-defined primitives and the tracker handles persistence, UI, and workflow (Kanban board: Backlog → To Do → In Progress → Done).

Below is the core MCP tool registration for creating issues (trimmed for clarity). It shows a FastMCP server being instantiated and the `create_issue` tool registered. The function constructs an IssueCreate payload and persists it via the IssueStore.

```python theme={null}
from __future__ import annotations

import sys
from pathlib import Path

sys.path.insert(0, str(Path(__file__).resolve().parent.parent))

from mcp.server.fastmcp import FastMCP

from app.models import IssueCreate, IssueUpdate
from app.store import IssueStore

store = IssueStore()

mcp = FastMCP(
    "finops-issue-tracker",
    instructions="Issue tracker for FinOps findings. Create, list, get, and update issues.",
)

@mcp.tool()
def create_issue(
    title: str,
    summary: str = "",
    body: str = "",
    namespace: str = "",
    resource_name: str = "",
    resource_kind: str = "",
    category: str = "",
    priority: str = "medium",
    cost_impact: float = 0.0,
    assignee: str = "",
    suggested_owner: str = "",
    suggested_cost_center: str = "",
    reasoning: str = "",
    source: str = "mcp-agent",
) -> dict:
    payload = IssueCreate(
        title=title,
        summary=summary,
        body=body,
        namespace=namespace,
        resource_name=resource_name,
        resource_kind=resource_kind,
        category=category,
        priority=priority,
        cost_impact=cost_impact,
        assignee=assignee,
        suggested_owner=suggested_owner,
        suggested_cost_center=suggested_cost_center,
        reasoning=reasoning,
        source=source,
    )
    # Persist the issue using the store and return the created record
    issue = store.create(payload.dict())
    return issue
```

MCP tools exposable to agents

These are the primitives the agent uses to translate FinOps findings into tickets. Below is a concise table summarizing each tool and its purpose.

| Tool name | Purpose | Example / Notes |
| - | - | - |
| `create_issue` | Create a new ticket from an agent finding | Accepts fields such as `title`, `summary`, `priority`, `cost_impact` |
| `list_issues` | List tickets with optional filters (status, assignee, category) | Useful for deduplication or showing existing work |
| `get_issue` | Retrieve a single ticket by ID | Returns full ticket metadata and audit trail |
| `update_issue` | Modify fields or status of an existing ticket | Used by agents or UI to advance workflow or fill in details |

Calling the tracker

The tracker runs as a local web service in the demo. To run it in a container:

```bash theme={null}
docker run -p 8001:8001 finops-issue-tracker:latest
```

Open the UI at:

[http://localhost:8001](http://localhost:8001)

The demo UI provides a Kanban-style board (Backlog, To Do, In Progress, Done). Tickets created by the agent appear in Backlog for engineers to triage and move through the workflow.

Example HTTP interaction

The MCP tools are exposed programmatically. A simplified example endpoint for creating an issue might look like:

POST /create-issue

Example JSON payload:

```json theme={null}
{
  "title": "Unattached PersistentVolume increasing costs",
  "summary": "Found an unattached PV in namespace `payments`",
  "body": "PersistentVolume `pv-1234` has not been bound for 7 days.",
  "namespace": "payments",
  "resource_name": "pv-1234",
  "resource_kind": "PersistentVolume",
  "category": "storage",
  "priority": "high",
  "cost_impact": 42.5,
  "suggested_owner": "sre-team"
}
```

Then the registered `create_issue` tool will persist the record and return the created ticket object (including ID and metadata).

Integration notes and best practices

When mapping this demo to a production issue tracker (e.g., Jira or GitHub Issues), keep the MCP tool signatures stable and translate payload fields at the service boundary. This lets agents remain unchanged while you swap or upgrade the backing issue-tracking implementation.

* Keep agent calls idempotent: use `list_issues` / `get_issue` to deduplicate before creating a new ticket.
* Include structured fields (namespace, resource\_kind, resource\_name, cost\_impact) so engineers can quickly triage and correlate tickets with cluster findings.
* Use `source` or `external_id` fields to track which agent or scan produced the finding.

Links and references

* [Kubernetes Basics](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
* [Docker Hub](https://hub.docker.com/)
* [FastAPI (used by FastMCP implementations)](https://fastapi.tiangolo.com/)

Next steps

The main task now is to integrate your agent with this MCP endpoint. The agent should:

1. Scan cluster findings and generate structured observations.
2. Call `list_issues` or `get_issue` to check for existing tickets.
3. Call `create_issue` to create new tickets when appropriate.
4. Optionally call `update_issue` to add context or progress status as remediation occurs.

With this pattern, your agent becomes a reliable pipeline that turns FinOps discovery into actionable work for engineers.

> **[Watch Video](https://learn.kodekloud.com/user/courses/building-kubernetes-finops-ai-agent/module/bbcc27a3-b731-4d76-9ba0-b3df1a8b3afb/lesson/6631434c-9cea-4a4c-b4c9-5df363f4912e)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.