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_ticketC | Get full details of a Jira ticket by its key |
| 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. |
| search_ticketsC | Search Jira tickets using JQL query language |
| create_ticketB | 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 |
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 17 tools
Each tool targets a distinct resource and action (e.g., add_comment vs update_comment vs delete_comment; log_work vs update_worklog vs delete_worklog). The only potential overlap is update_ticket vs transition_ticket, but descriptions clearly separate field updates from status changes.
All tools follow a consistent snake_case verb_noun pattern (get_ticket, create_ticket, add_comment, delete_worklog, etc.). Minor variations like move_to_sprint and generate_release_notes remain readable and do not break the overall convention.
17 tools is slightly above the typical 3-15 range, but each tool covers a necessary Jira operation with no obvious redundancy. The count is justified by the breadth of ticket management tasks.
The set covers core ticket lifecycle operations (create, read, update, search, transition, comments, worklogs, watchers, links) but lacks delete_ticket and some project/sprint management functions. Agents can work around most gaps using JQL and existing tools.