Book an audit call

AI in Jira: MCP, Rovo and LLMs in automation, compared

Three routes bring AI into Jira today: an MCP connection that lets an outside assistant read and write your site, Rovo, which is Atlassian’s own assistant and agents, and model calls placed inside automation rules. Each suits a different job, and each fails differently when the configuration underneath is untidy.

Written by Ben Friedman, fractional forward-deployed AI engineerPublished · 2 min read

Key takeaways

  • Rovo is for people working in issues and pages. Start there for search, summaries and drafting.
  • MCP is for assistants you already use elsewhere that need to reach Jira.
  • A model call in a rule is for one repeatable judgment, such as classifying a request.
  • All three inherit the site’s permissions and its mess.

The three routes, side by side

Rovo
Runs inside Atlassian, respects the platform’s permissions and needs no hosting. Its reach into configuration is limited, which the Rovo article covers object by object.
MCP connection
A standard way for an outside assistant to call Jira as a tool. The assistant can do whatever its token allows, so scoping is the whole job. See Atlassian MCP setup.
Model call in automation
A rule sends text to a model and uses the answer in its next step. Cheap, narrow and easy to test, as long as the rule has an owner.

Choosing by the job, not by the technology

  • Someone wants an answer or a draft while working a ticket: Rovo.
  • A request should be sorted, tagged or routed the moment it arrives: a model step in a rule.
  • An assistant your team uses for other work should also see and update issues: MCP.
  • Projects, workflows, schemes and fields should be changed on request, with approval: an administration agent such as JAMES.

How each route fails on an untidy site

Rovo answers from stale pages when nobody archives. An MCP-connected assistant with a broad token edits issues in projects it was never meant to enter. A model step in a rule keeps classifying into categories the team retired last quarter. None of these is a model fault. Each is the site’s state showing through.

Cleaning comes first, which is why the audit’s Jira edition reads configuration before recommending any of the three.

Where custom work begins

The three routes cover most needs. Custom work starts when the task spans Jira and another system, needs a rule Jira cannot express, or must be provable afterwards. At that point the options are an agent built for the task or a Forge app, and the audit says which.

Frequently asked questions

Do we need all three?
Rarely at once. Most teams start with Rovo, add one or two model steps in rules, and consider MCP only when an outside assistant is already part of daily work.
Is it safe to connect an outside assistant to Jira?
It is as safe as the token you give it. Use a dedicated account, scope it to the projects it needs, and review what it did in the first weeks.

Not sure which route your site is ready for? The Jira audit answers that in two weeks.

Take the 5-minute scorecardTry JAMES free

About the author

Ben Friedman runs Viter, a forward-deployed AI engineering service. He has spent over ten years running Atlassian and operations tooling, including as internal Jira lead at Aroundtown, and holds the ACP-610, ACP-620 and ACP-120 certifications. He builds JAMES, the AI Jira administrator.

Next in this topic · 2 of 5Build or buy AI for operations: deciding one workflow at a time Buy when the vendor’s AI sits where the work is. Build when the process is yours, spans systems or must be provable.Read next →