Jira AI API options: REST, Rovo, and eesel CLI

“Jira AI API” can mean several different things: reading an issue for your own model, letting a coding agent use Jira tools, calling Rovo, or operating a support teammate. I would identify which of those jobs you need before choosing an endpoint.

Atlassian now documents several developer routes. This guide separates them and explains where eesel CLI fits when the job is support work inside Jira Service Management. Documentation was checked on September 8, 2026.

Choose the interface that matches your job

These routes do not share one universal token, billing unit, or permission model. An API key that works for one service is not proof of authorization for another.

Jira REST: explicit resource operations

The Jira REST reference documents issues, comments, users, projects, and related resources. Your application chooses the operation and handles the response. If you send retrieved content to an external model, your application also owns that data-handling decision.

The API is not a blanket promise that every AI button in Jira has an equivalent REST operation. Check the documented resource, authentication method, required permissions, and pagination for the specific job.

This older interface shows writing-assistance options in Jira. It is not evidence that those menu items have corresponding public REST endpoints.

For a summary tool, begin with one approved test issue. Preserve the distinction between the issue's recorded facts and a model's proposed next step. Do not let a successful summary automatically authorize a write.

Rovo MCP: tools for an AI client

The Rovo MCP overview describes a hosted server connecting compatible clients to Atlassian apps. Its current endpoint is https://mcp.atlassian.com/v2/mcp. It supports OAuth authorization and a documented API-token route for headless clients.

The client can discover and invoke supported tools within the authenticated user's permissions. This is a tool connection, not the same interface as sending an A2A conversation to Rovo. Check the supported tools and administrator settings rather than guessing from a tool name.

Rovo A2A: communicate with Rovo

Atlassian's A2A getting-started guide documents communication from an external agent to Rovo. It requires Rovo and A2A to be enabled and an appropriate A2A-compatible client.

The guide uses a public Agent Card, a description of capabilities and authentication requirements, for discovery. Authenticated requests then use OAuth with PKCE and Dynamic Client Registration. It recommends message/stream for the first end-to-end request.

Discovering the public card is not authorization to read an organization's Jira data. Follow the actual consent flow and verify the request completes; an open stream alone is not a completed task.

Forge: build an agent extension

The Forge Rovo module defines an agent in a Forge app. Actions can supply specific code or API work for that agent.

This is relevant when you want to build and maintain an Atlassian extension. It is a different responsibility from configuring a ready-made support teammate. Decide who will own deployment, permissions, failed actions, and ongoing maintenance.

Where eesel CLI fits

The eesel CLI operates the same eesel agent and workspace as the dashboard. A person can inspect it from a terminal, a script can consume its JSON output, and Claude Code, Cursor, or Codex can help configure and evaluate it.

For a Jira support workflow, you can inspect connections and instructions, rehearse a policy-sensitive reply, and investigate activity and approvals. You are operating eesel, not calling Rovo through another name.

Inspect the existing teammate

With Node.js 18.17 or newer:

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
npx @eesel/cli integrations --agent PILOT_AGENT_ID
npx @eesel/cli status --agent PILOT_AGENT_ID
npx @eesel/cli instructions --agent PILOT_AGENT_ID
npx @eesel/cli automations --agent PILOT_AGENT_ID

Replace PILOT_AGENT_ID with the intended teammate. This selects an agent; it does not create a sandbox or reduce its integration account's permissions.

Use the Jira integration guide if Jira is missing. That connection uses a subdomain, Atlassian account email, and API token. Keep credentials in the approved connection flow, not in reports or shared coding-agent prompts.

Enabling an eesel Jira trigger creates a Send web request rule in Jira Automation. The token's account needs permission to administer that automation. A working connection does not prove that event delivery is configured.

Keep issue data and policy knowledge separate

eesel reads Jira issues live through Get Issue and Search Issues, including JQL searches. The integration does not sync old Jira issues into its knowledge.

Connect approved policy sources separately. For example, a live issue can describe a failed production deployment, while an approved incident policy explains who may declare an incident and what evidence is required. Neither source replaces the other.

A useful coding-agent request is:

Inspect this eesel teammate through read-only CLI commands. Identify its Jira connection, available policy sources, and enabled automations. Report missing prerequisites for an incident-summary pilot. Do not start chats, connect sources, change instructions, enable actions, or create automation.

The JSON output supports a repeatable review. It does not make every field a stable contract for your script: inspect the command's --help and returned fields before building a parser.

Rehearse an incident summary

Confirm that the relevant incident policy is available and disable write actions before testing. The commands below do not change permissions.

npx @eesel/cli new --name "jira-incident-summary-check" --agent PILOT_AGENT_ID
npx @eesel/cli chat "Fictional request: a deployment failed and one employee reports that the checkout page is unavailable. Draft an internal summary using the approved incident policy. Separate reported symptoms from verified facts and list the evidence needed before declaring an incident. Do not read real issues, declare an incident, create or update an issue, post a comment, assign anyone, or add labels." --agent PILOT_AGENT_ID
npx @eesel/cli chat "A second employee says checkout works for them. Revise the summary without inventing an outage scope, root cause, or resolution." --agent PILOT_AGENT_ID

The follow-up continues the same conversation. Evaluate whether contradictory reports remain visible and whether the summary avoids claiming that investigation has already happened.

CLI chats are billed work. Read-only inspection commands are free. The --dry-run flag previews a server call rather than simulating answer quality.

Verify the actual Jira result

For an integration test, use a synthetic issue in an approved test project. Inspect existing automations first and review the scope before requesting a new automation, because chat-created automations start enabled.

Choose issue created with a narrow filter. Keep Reply to Issue off and require approval for Leave Note on Issue. Leave unrelated writes disabled. Create a fresh issue after setup, then inspect:

npx @eesel/cli activity --agent PILOT_AGENT_ID
npx @eesel/cli approvals --agent PILOT_AGENT_ID
npx @eesel/cli billing

Review the proposed note, approve only that action, and verify its private visibility and issue key in Jira. A pending approval is not a delivered comment. Workspace billing can include other teammates' work.

This eesel example uses a Zendesk teammate, not the proposed Jira test. Inspect your own teammate's activity, then verify the actual comment in Jira.

The second documented Jira trigger is a new customer comment. Mentions, status changes, and field updates are not separate eesel triggers. Test the event you configured, rather than repeatedly changing a field and expecting a run.

Validate each boundary

For a custom REST client, these checks belong in your implementation. For Rovo MCP or A2A, follow that interface's current testing guidance. For eesel, inspect the teammate's activity and verify the result in Jira.

Compare costs without mixing products

Keep Jira subscriptions, Atlassian AI usage, external model charges, and eesel work on separate budget lines. The selected route determines which costs apply; they are not all mandatory for every implementation.

eesel's current pricing is task-based. An issue handled by the teammate is one task regardless of comment count, and tasks are billed regardless of outcome. An activity record is not automatically an itemized invoice.

Try eesel if the job is an operated Jira support teammate. Use the CLI to inspect it, rehearse its reasoning, and approve a private result before expanding the workflow.