Summary
Triage happens in the editor, and the ticket is already filled in when it lands.
The 12 tools cover one loop tightly — find work with JQL, read it, change it, hand it to someone, say why — and jira_create_issue takes enough fields that a ticket filed from here does not need editing afterwards. There is a sharp edge worth knowing before you wire it into an agent: jira_delete_issue deletes permanently, and it sits in the same tool set as the read calls. Boards, sprints and worklogs are outside this surface; it is issues, comments and projects.
What it is
A Jira server covering the issue lifecycle — JQL search, create, update, assign, comment, delete — against a self-supplied base URL
What you get
- JQL search with a result cap, so 'project = PROJ AND status = Open' or 'assignee = currentUser() AND status != Done' runs from the chat (jira_search_issues).
- Issue creation carrying project key, issue type, summary, description, priority, labels, components, assignee and custom fields (jira_create_issue).
- Updates that include status transitions, plus assignment and permanent deletion (jira_update_issue, jira_assign_issue, jira_delete_issue).
- The comment thread in both directions: read every comment on an issue, add one (jira_get_comments, jira_add_comment).
- Project context needed before filing: the project list, one project's details, and the issue types that project accepts (jira_get_projects, jira_get_project, jira_get_issue_types).
- Identity of the authenticated account, which is what makes currentUser() queries meaningful (jira_get_current_user).
Requirements
A Jira instance you can reach and an account on it: JIRA_BASE_URL and JIRA_PAT.
Setup effort
One command plus a key — npx mcp-jira-server, then supply credentials