Connect Claude to Jira

Search issues with a JQL query and return a compact summary of each match - key, summary, status, assignee, priority, type, project and dates. This is the entry point for almost every Jira question: get an issue key here, then call get_issue for the full description and get_transitions before moving it. JQL examples: "project = ENG AND status != Done ORDER BY updated DESC", "assignee = currentUser() AND resolution IS EMPTY", "labels = billing AND created >= -14d". The query must be bounded (name a project, an assignee, or a date range) or Jira rejects it. Pagination is by next_page_token, not an offset.

Fetch one issue in full, including its description, status, assignee, labels, links and comments. Use it after search_issues when you need the actual body rather than a one-line summary. The description and comment bodies come back as Atlassian Document Format - a JSON tree of paragraphs, not markdown. Call get_transitions if you then want to move the issue.

List the workflow transitions available on one issue right now, with the transition id and the status each one leads to. Always call this before transition_issue: transition ids are per-workflow and per-issue-state, so the id that closed one issue will not close another. Costs nothing and changes nothing.

List the projects this token can see, with their keys, names, types and leads. Call this first when you need a project_key for create_issue or a JQL query and do not already have one. Filter with query to match a name or key substring.

List the issue types you may actually create in one project - Task, Bug, Story, Sub-task, and whatever else that project's scheme defines. Call this before create_issue: issue type names are per-project, and a name that works in one project is rejected in another. Takes the project key from list_projects.

Find users by name or email and return their Atlassian accountId. A search string is required - Jira has no unfiltered listing here. This is the only way to get the accountId that create_issue and update_issue need for an assignee; Jira rejects usernames and email addresses in those fields. Email addresses may be hidden depending on each user's privacy settings.

Return the account this connection authenticates as: display name, email, accountId, time zone and locale. Use it to confirm which Jira account an agent is acting as, and to get the accountId for JQL such as assignee = currentUser(). Takes no arguments and changes nothing, which is why it is the install-time health check.

File a new issue. Needs a project key, a summary and an issue type name - call list_projects for the key and list_issue_types for the type names that project actually offers, because a type valid in one project is often invalid in another. The description is plain text; it is wrapped into Atlassian Document Format for you, so do not pass ADF JSON. Returns the new issue's id, key and self URL.

Change fields on an existing issue: retitle it, rewrite the description, reassign it, reprioritise it, relabel it or set a due date. Pass only the fields you want changed; anything you omit is left alone. This cannot move an issue between workflow statuses - that is transition_issue. Jira answers with an empty body on success.

Post a comment on an issue. Prefer this over update_issue when you are reporting progress or asking a question - rewriting the description destroys what was there, a comment does not. The body is plain text and is wrapped into Atlassian Document Format for you. Comments are visible to everyone who can see the issue.

Log time against an issue. time_spent uses Jira's own duration syntax - "3h", "1d 2h", "45m". Omit started and Jira stamps it now; supply it to backdate an entry. Adding a worklog adjusts the issue's remaining estimate automatically. Returns the created worklog entry.