Skip to main content

Overview

This page documents the manual tool surface that an agent (or a flow) can call to act on Jira on demand. It is not the same as automatic ticket pickup — for that, configure Jira Automation (Auto-Pickup), which uses these same credentials but adds webhook/polling intake and trigger rules so Genesis starts work on a ticket without being asked.Before using this tool group, make sure a Jira connection has been saved as described in Setup Jira API Parameters.

Tool Name

Purpose

The jira_connector_tools group integrates Genesis workflows with Jira. Authenticate to a Jira instance, create or update issues, search with JQL, transition statuses, pull project metadata to keep work in sync, and, when Jira automation is enabled, configure shared worker and polling automation.

Functions Available

  1. jira_connector: Standard Jira issue, comment, attachment, and search operations.
  2. jira_automation_setup_action: Read or update shared Jira automation and service-worker settings, validate or provision the Jira worker, and sync the scheduled Jira poller Flow.
  3. jira_automation_action: Run Jira automation actions such as a manual POLL_ONCE pass against the saved configuration.

Key Features & Functions

Authenticate & Connect

Establish a secure session with your Jira Cloud or Server instance.

Create & Update Issues

Open new tasks, bugs, or stories and modify fields, assignees, and priorities.

Search with JQL

Run targeted queries to find and report on issues across projects.

Workflow Transitions

Move issues through statuses with TRANSITION_ISSUE using a transition id or a target status name.

Project Context

Fetch projects, issue types, and workflow options to drive automation.

Input Parameters for Each Function

jira_connector

Parameters
LIST_PROJECTS: Lists the projects visible to the selected connection. The response’s result.projects contains each project’s key, name, and id; result.truncated is true when the listing stops at the 10,000-project cap. This reads the full listing: Jira Cloud makes one request per 50 projects (up to 200 requests), while Server/Data Center makes one request.
UPDATE_ISSUE description vs ADD_COMMENT: With action="UPDATE_ISSUE", the description parameter updates the Jira issue’s description field (via the fields API). It is not posted as a comment. To add a comment on an existing issue, use action="ADD_COMMENT" with issue_key and comment or description. For UPDATE_ISSUE, comment is ignored so a stray comment argument cannot overwrite the issue description.
ADD_COMMENT visibility (JSM): For Jira Service Management requests, set comment_visibility to public when replying to the customer or internal for an agent-only note. When omitted, Genesis preserves Jira’s existing/default comment behavior. Successful ADD_COMMENT responses can include comment_id, visibility, visibility_verified, and related fields. If Jira applies a different visibility than requested, the tool returns Success: false with visibility_mismatch and retry_safe: false — do not retry because the comment already exists.
CREATE_LINK, ADD_ATTACHMENT, and TRANSITION_ISSUE: CREATE_LINK links two issues as issue_key → link_type → target_issue_key (for example, link an X-ray Test to its Story with link_type="tests"). ADD_ATTACHMENT uploads a file from Genesis storage to an issue via a scoped URI. TRANSITION_ISSUE moves an issue through its workflow — pass transition_id directly, or pass a target status name and Genesis resolves the transition automatically.
Action Review for writes: CREATE_ISSUE, CREATE_CHILD_ISSUE, UPDATE_ISSUE, ADD_COMMENT, TRANSITION_ISSUE, CREATE_LINK, and ADD_ATTACHMENT run under Action Review. The deployment policy may apply a write immediately or wait for a person to approve it. A pending result means nothing has changed yet; an uncertain result has action_review.status="reconciliation_required" — do not retry it blindly. For an uncertain attachment upload, check the issue’s attachments manually before deciding what to do: Jira does not provide a client-chosen upload identity for automatic reconciliation. Mutating requests sent through connection_api_action are also outside this family.
ADD_ATTACHMENT staging: Genesis reads the scoped source before the Action Review decision and holds a private snapshot of its bytes for that proposal. The upload is limited to 20 MB. A query-result:// source must belong to the same user, bot, and thread; its query may run once while staging, but approval and submission use the captured bytes rather than running it again. The snapshot is checked against its recorded filename, content type, size, and digest before submission, then released when the proposal is terminal (the Action Review sweep retries cleanup failures). See Databricks durability for Databricks volume storage, access, and restart behavior. For example, use action="ADD_ATTACHMENT", issue_key="OPS-42", and attachment_uri="sandbox:/mnt/data/triage.log"; set filename only to override the stored file’s name.
Prefer API tokens over passwords for Jira Cloud. Create tokens from your Atlassian account and store them securely.
SEARCH_ISSUES on Jira Cloud: Genesis calls Atlassian’s enhanced /rest/api/3/search/jql endpoint with a JSON POST body (jql, fields, maxResults). The enhanced search contract does not include the legacy startAt offset parameter — non-zero offsets return an error. Narrow your JQL to stay within the returned page. Jira Server/Data Center continues to use the classic search API with offset pagination via startAt.

Write identity and connection selection

Genesis scopes Jira write actions — CREATE_ISSUE, CREATE_CHILD_ISSUE, UPDATE_ISSUE, ADD_COMMENT, CREATE_LINK, ADD_ATTACHMENT, and TRANSITION_ISSUE — by the resolved connection identity:
  • User OAuth connections act as the requesting user. Writes require a requesting user in the active thread context.
  • Personal PAT or API-token connections allow writes only when the requesting user owns that connection.
  • Shared PAT or API-token connections fail closed for bot writes unless the connection’s Write identity (locator field identity_type) is service_account or team_owned, or Genesis uses the dedicated Jira service-worker token for automation-managed threads. connection_api_action only reads Jira: it refuses POST/PUT/PATCH/DELETE, so every Jira change goes through jira_connector and Action Review. Admins set the field in the Connections page edit form or with connections_action UPDATE - which replaces the stored locator, so the full locator must be resent: auth_type, host, email, token_scope_mode and identity_type for Cloud API-token connections, or auth_type, host and identity_type for Server/DC PAT connections; api_token or pat may be omitted to keep the stored secret reference. Older markers on existing rows (credential_owner_type / owner_type, or a truthy is_service_account / service_account / team_owned flag) are still honoured but not recommended. See Setup Jira API Parameters.
When a write is blocked, the tool returns Success: false with a message that names the connection and the identity_type field to set, plus a Suggestion to configure a Genesis Jira service account, use the requester’s own connection, or pass an allowed connection_id. Successful and blocked write responses include a provenance object with connection id, auth mode, identity type, Jira identity email, requester ids, and whether service-worker auth was used. For shared or service-worker writes, ADD_COMMENT appends Posted by Genesis on behalf of {requester email}. when the requester email is available and the comment does not already include that attribution.
jira_automation_setup_action and jira_automation_action are available by default. Operators can disable them by setting GENESIS_ENABLE_JIRA_AUTOMATION=false or an equivalent falsey value on one of the Jira automation flag aliases; while disabled, both helpers return the Jira automation disabled message.

jira_automation_setup_action

Use this helper to manage the same shared Jira automation and service-worker settings exposed in the Config UI. Shared setup actions require access_config_panel or manage_all_connections. Common parameters Automation convenience parameters Service-worker convenience parameters Example

jira_automation_action

Use this helper to run programmatic Jira automation actions from chat or a scheduled Genesis Flow. Parameters
When lookback_minutes is omitted, POLL_ONCE respects the saved poll_interval_seconds throttle and can return a skipped message if the previous poll ran too recently.
Example

Use Cases

  1. Auto-create incidents from platform events When a data quality check fails, open a Bug in the correct project with context attached.
  2. Sync task progress Move issues to In Progress or Done when Genesis tasks are started or completed with TRANSITION_ISSUE. Use UPDATE_ISSUE with description to change the issue body; use ADD_COMMENT to post activity in the comment thread.
  3. Link related issues and attach evidence Use CREATE_LINK to connect tests to stories or mark blockers, and ADD_ATTACHMENT to upload logs, screenshots, SQL output, or reports from Genesis storage.
  4. JSM customer replies and internal notes Use ADD_COMMENT with comment_visibility="public" to reply to the customer or comment_visibility="internal" for agent-only notes on Jira Service Management requests.
  5. Programmatic reporting Run scheduled JQL searches for open blockers and post summaries to Slack.
  6. Sprint coordination Batch update assignees and priorities ahead of sprint planning.
  7. Governance and audits Pull full issue details with history and attachments for compliance reviews.
**Deleting or bulk editing issues in Jira is hard to undo. **Test your automation in a non-production project first.

Workflow/How It Works

  1. Authenticate Provide jira_url, username, and api_token to establish a session.
  2. Operate on issues Use create_issue, update_issue, get_issue, and transition_issue as tasks progress.
  3. Search and report Execute search_issues with jql_query to produce lists for dashboards or alerts.
  4. Pull context Call get_projects and get_workflows to discover valid types, fields, and transitions.
Custom fields vary by project. Use get_issue on a known ticket or the Jira REST API browser to confirm field ids before automating writes.

Integration Relevance

  • project_manager_tools to mirror milestones and task states.
  • data_dev_tools to tie engineering work to Jira user stories.
  • slack_tools to notify channels on issue creation or failure transitions.
  • file_manager_tools to attach logs, screenshots, or reports to issues.
  • handoff to hand off Jira updates as part of multi-agent workflows.

Configuration Details

  • Use the full HTTPS base URL for your instance.
  • Ensure the API token has permissions for the target projects.
  • Match project_key, issue_type, and custom field ids to the project configuration.
  • Workflow transitions require a valid transition_id or a status name that matches an available transition for the issue’s current workflow state.

Limitations or Notes

  1. Jira Cloud and Server/Data Center use different search APIs — Cloud enhanced search is a JSON POST to /rest/api/3/search/jql without startAt offsets; Server/DC uses the classic search API with offset pagination.
  2. API rate limits may require pagination or backoff for large queries.
  3. Permissions and screens can block writes to required fields if not supplied.
  4. On Jira Server/Data Center, large searches can paginate with offset-based startAt. On Jira Cloud, enhanced search does not support offset pagination — narrow JQL instead.
  5. Tokens expire or can be revoked. Handle authentication failures gracefully.

Output

  • Authentication Confirmation of the authenticated user and scopes.
  • Issue Operations Keys, URLs, updated field snapshots, and current status after actions.
  • Search Results Arrays of issues with key metadata from JQL queries.
  • Project and Workflow Data Project listings, issue types, transitions, and related configuration.
  • Errors Clear messages for permission problems, invalid fields, missing transitions, connectivity issues, or blocked shared PAT/API-token write identity.
  • Write provenance For write actions, a provenance object describing the resolved connection, auth mode, identity type, Jira account email, requester, and whether service-worker auth was used.
  • Comment visibility For ADD_COMMENT with comment_visibility, responses can include comment_id, requested_visibility, public, visibility, visibility_verified, and warnings such as visibility_mismatch when Jira applied a different visibility than requested. GET_ISSUE comments include public and visibility when fetched with include=['comments'].