Jira
Jira tools are offered once an Atlassian profile exists and Jira is enabled with a selected profile. Add profiles (site, email, API token) in Settings → Providers → Atlassian profiles. Enable Jira and choose its profile in your tool settings, per project in .nerve/config/capabilities.json, or per conversation from Capabilities → Tools beside the composer (the configure button beside Jira). The agent sees Jira only when the resolved settings name a profile that exists, and tool calls use that same profile.
Each Atlassian profile shows its connection status for Jira and Confluence: verified, credentials rejected, access restricted, not on this site, or couldn’t check. Use Test connection to check now; Nerve also re-checks stale results when the page opens and updates the status when a Jira call succeeds or is refused with 401.
Nerve exposes Jira operations for users, issues, projects, boards, sprints, backlogs, attachments, comments, worklogs, and issue links. Read operations are network reads and can run in parallel. Mutations are sequential write-capable calls and pass the active permission/approval policy.
The tool surface is single-target: each mutation changes one issue, comment, worklog, link, attachment, sprint, or backlog placement. Related resource mutations use an explicit action such as create, update, or delete. Jira Software board, sprint, and backlog tools require the configured site and project to provide Jira Software APIs. Attachment transfers are capped at 25 MiB and downloads are written to local artifacts; attachment bytes are never injected into the model context.
Use jira_get_issue to discover comment, worklog, issue-link, and attachment IDs before changing them. jira_manage_attachment uses action: "upload" with issue_key and file_path, or action: "delete" with attachment_id; deletion is destructive. Calls that previously used jira_upload_attachment should use jira_manage_attachment with action: "upload". Use jira_get_project with issue-link types before creating links. All new mutations support dry_run.
Read-only agent permission blocks Jira network calls, even operations classified as read-only network access. Use supervised permission when you want the agent to research Jira and ask before changes.
Results are bounded; narrow queries and limits improve context use. Larger/raw data can be stored as artifacts rather than injected in full.