Skip to main content
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.
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.
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. Calling the tracker The tracker runs as a local web service in the demo. To run it in a container:
Open the UI at: 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:
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 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