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 snapshotHere’s the repository view where the issue-tracker service lives. The image shows the folder structure and numbered sections used in the demo repository.
Core design and MCP serverThe 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.
MCP tools exposable to agentsThese 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 trackerThe tracker runs as a local web service in the demo. To run it in a container:
docker run -p 8001:8001 finops-issue-tracker:latest
Open the UI at:http://localhost:8001The 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 interactionThe MCP tools are exposed programmatically. A simplified example endpoint for creating an issue might look like:POST /create-issueExample JSON payload:
{ "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.