Jira MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JIRA_HOST | Yes | Base URL, e.g. https://jira.company.com | |
| JIRA_PASSWORD | Yes | Jira password | |
| JIRA_USERNAME | Yes | Jira username | |
| JIRA_START_DATE_FIELD | No | Custom field ID for Start date | customfield_11300 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_ticketA | Get full details of a Jira ticket by its key. For a single comment (a ?focusedCommentId= link), use get_comment instead. |
| transition_ticketA | Change a Jira ticket's status. Matches the transition name or its target status; common aliases (Closed/Resolved -> Done, Reopen -> Re-Open) resolve to whatever the workflow offers. Valid options vary per issue and are listed in the error when no match is found. |
| update_ticketB | Update fields of a Jira ticket. Converting between a standard issue type and Sub-task is a Jira REST API limitation — use Jira's UI "Move" action instead. |
| add_commentB | Add a comment to a Jira ticket |
| update_commentA | Replace the text of an existing comment on a Jira ticket. Comment IDs are shown by get_ticket with include_comments. |
| delete_commentA | Delete a comment from a Jira ticket. This cannot be undone. Comment IDs are shown by get_ticket with include_comments. |
| get_commentA | Get one comment of a Jira ticket by its ID, e.g. from a ?focusedCommentId= link. Cheaper than get_ticket when only that comment matters. |
| search_ticketsC | Search Jira tickets using JQL query language |
| create_ticketC | Create a new Jira ticket |
| generate_release_notesB | Generate Markdown release notes for a fix version, grouped by issue type |
| link_issuesB | Create a link between two Jira tickets |
| unlink_issuesA | Remove a link between two Jira tickets. Direction does not matter. If several links connect them, pass link_type to pick one. |
| log_workB | Log work (time) on a Jira ticket, optionally setting WorklogPRO Type of Work and Type of Activity |
| update_worklogA | Edit a worklog's time, start or comment. Worklog IDs are shown by get_ticket with include_worklogs. To change Type of Work/Activity, delete the worklog and log_work again. |
| delete_worklogA | Delete a worklog from a Jira ticket. This cannot be undone. Worklog IDs are shown by get_ticket with include_worklogs. |
| add_watcherC | Add a user as a watcher of a Jira ticket |
| remove_watcherB | Remove a user from the watchers of a Jira ticket |
| move_to_sprintB | Move Jira tickets into an active or future sprint, by sprint name or ID |
| add_attachmentA | Upload a local file to a Jira ticket as an attachment. Embed an uploaded image in a comment or description with !filename.png! |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 19 tools
Each tool has a clearly distinct purpose by resource and action: tickets, comments, worklogs, links, watchers, attachments, and sprints are separated cleanly. The few potentially overlapping areas, such as get_ticket vs get_comment and update_ticket vs transition_ticket, are explicitly clarified in the descriptions.
All tool names follow a consistent snake_case verb_noun pattern, including add_comment, create_ticket, update_worklog, remove_watcher, and generate_release_notes. There are no mixed conventions or vague standalone verbs.
The 19 tools cover a broad Jira surface and each seems purposeful, but the count is slightly high relative to a typical well-scoped MCP server. The subresource operations for comments, worklogs, watchers, links, and attachments justify most of the size.
Core ticket workflows are well covered: create, get, search, update, transition, comments CRUD, links add/remove, worklogs create/update/delete, watchers add/remove, and sprint moves. Minor gaps remain, such as no ticket deletion, limited attachment operations beyond upload, and no sprint/project discovery tooling, but most can be worked around or are less common.