Inspiration

We run a small business where AI agents do much of the day-to-day work. The mistake that cost us most was never bad writing. It was a confident "done" that was not done. Status updates written by agents read well and are wrong in small, specific ways: an issue that is still In Progress, a count that is off by one, an assignee who changed yesterday. We had built checks like this for our own agents, and we wanted the same check inside Jira, where status updates are read and trusted.

What it does

  • Three Rovo MCP tools, usable by Rovo agents and by any external MCP client through the Atlassian MCP server:
    • Verify claims about Jira issues: one claim per line, such as MOBL-10 status = In Progress. Each claim comes back as MATCH, MISMATCH (with the value Jira has now) or UNVERIFIABLE (with the reason).
    • Verify a claimed issue count: runs the JQL that defines the set and counts the issues exactly.
    • Get verifiable facts for Jira issues: status, assignee, priority, resolution, type, labels, fix versions and due date for up to 20 issues, so an update can be written from evidence in the first place.
  • An issue panel (UI Kit) that finds claim lines in the issue's recent comments and re-checks them against live Jira every time someone opens the issue. A status update that was true when it was posted, and is not true now, is flagged with today's value.
  • An open SKILL.md that gives any agent the loop: draft, turn every fact into a claim line, verify, fix every mismatch, then post with a "Verified by Claim Check" list that the panel can re-check later.

In the demo, a Rovo agent is told "MOBL-10 is done and 3 stories are in testing." It checks both, finds that MOBL-10 is still In Progress and that 4 stories are in Testing, and corrects them before it answers. Later, when an issue moves, the panel flags the stale line in the posted update. Claude Code, connected through the Atlassian MCP server, uses the same tools to fix a release note before it is sent.

How we built it

  • Forge with the rovo:mcp module for the three tools and jira:issuePanel with UI Kit for the panel.
  • Every check is a deterministic comparison in a Forge function. There is no Forge LLM, no external service and no stored data.
  • Every Jira read uses asUser(), so the tools never reveal anything about an issue the person could not open. The only scope is read:jira-work.
  • 14 unit tests cover claim parsing and comparison.
  • We tested the tools from a Rovo agent built in Rovo Studio and from Claude Code connected to the Atlassian MCP server.

Challenges we ran into

  • Jira returns field values in the reader's language: a Japanese user sees the priority "Critical" as クリティカル. Guessing translations would make the check itself unreliable, so the tool returns UNVERIFIABLE with the reason and tells the agent to restate the claim with the name Jira uses.
  • Jira turns issue keys typed into a comment into smart links. The panel reads claim lines whether the key is plain text or a smart link.
  • An "about N issues" total is not good enough for a check, so the count tool pages through the results (up to 5,000 issues) and counts them exactly.

Accomplishments that we're proud of

  • The agent caught both wrong facts it was given, and the panel caught a claim that went stale after it was posted.
  • The same three tools work unchanged from Rovo and from an external MCP client.

What we learned

In our test runs, with a Rovo agent and with Claude Code, the agent corrected every mismatch when the tool returned the actual value next to the claim. That is why every result carries the value Jira has now, not only a verdict.

What's next for Claim Check for Jira

  • More fields: sprint, story points, parent and components.
  • Claims in Confluence pages, not only in Jira comments.
  • A scheduled re-check that comments on the issue when a posted claim goes stale.

Built With

Share this project:

Updates

Submission history