Your AI IDE already reads the repo. If tickets are plain-text YAML next to the code, the agent can search the backlog the same way it reads a module — no MCP, no JQL translator, no cloud hop for every ask.
MCP into Jira is the bolt-on path. At a few thousand tickets — or around 10,000 — the gap shows up in latency, hit rate, and junk in the context window.
Native path: tickets as YAML
.gitoza/tasks/tickets/{project}/{ticket-id}.yaml
The ticket id is the filename (without .yaml). With stable keys (status, assignee, priority, type), an agent can answer:
- Open bugs in auth assigned to me
- What is still open on this release?
- Which tickets mention the checkout API?
Retrieval is local — IDE index, grep, or a SQLite-backed app index. You only pay network time for the model, not for fetching every ticket over REST.
Minimal example (AUTH-102.yaml):
---
title: Lockout after failed logins
priority: medium
status: open
type: bug
---
# Lockout after failed logins
## Description
Brief context for the agent and the team.
Point the agent at .gitoza/tasks/tickets/ and ask. Same loop as code review.
Same ask over Jira MCP
Useful when Atlassian must stay the system of record. For day-to-day agent work it adds a chain on every answer: natural language → tool call → JQL → REST → JSON → maybe another call if the first page was wrong.
Fine for one known issue key. Heavy for wide or multi-step backlog questions.
Speed, precision, cost
| YAML in the repo | Jira over MCP | |
|---|---|---|
| AI access | Native (files the IDE already sees) | Tools + network |
| Latency | Disk / local index | Network + JQL + paging |
| Narrow asks | High when keys are consistent | Depends on JQL |
| Tokens | Ticket text you chose | Schemas + JSON bloat |
| Quotas | None for local reads | Cloud / MCP caps |
| Offline | Works | Needs the cloud |
Precision caveat: “summarize all 10k tickets” still will not fit one context window. Filter first, then summarize — locally that is search/grep, not “hope the JQL was right.”
Cost direction: local plain text is cheaper per useful answer than tool-shaped round trips. Many checks never need an LLM — a terminal search is enough.
Skip the bridge
If the team already works in an AI IDE, put the backlog where the agent already looks: the repo. Files need no tool schema, no JQL translation, and no second system for “what is open this sprint.”
MCP is a workaround for a backlog trapped in a vendor API. YAML tickets remove that trap — Git is the data plane.
Try it
Gitoza keeps tickets under .gitoza/tasks/tickets/{project}/ (releases beside them; tests under .gitoza/test/ if you want coverage next to the work). Browse in the desktop UI, or open the YAML in Cursor / VS Code and ask.
Top comments (0)