“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
| What you need | Route to inspect |
|---|---|
| Read or update a known Jira resource | Jira REST API |
| Give an AI client Atlassian tools | Rovo MCP |
| Send a task to Rovo from an external agent | Rovo A2A |
| Build an Atlassian-hosted agent extension | Forge Rovo agent and action modules |
| Inspect and operate an eesel support teammate | eesel CLI |
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.
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.
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
| Result | What it proves | What remains to check |
|---|---|---|
| Authentication succeeds | Credentials were accepted | Scope and intended account |
| Lookup returns an issue | Data access worked | Correct issue and requester rights |
| Draft looks useful | Answer may be suitable | Policy evidence and review |
| Action is held | Approval gate was reached | Human decision and actual execution |
| Comment appears | Jira accepted a comment | Correct issue and private visibility |
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.
| Budget line | Where to verify it |
|---|---|
| Jira access and automation | Atlassian subscription and usage settings |
| Rovo usage | The selected Rovo feature's current billing terms |
| External model requests | Your model provider's usage records, if used |
| eesel tasks | The eesel workspace's Billing & Usage page |
| Review and maintenance | Your team's measured time |
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.