Jira MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JIRA_URL | Yes | The URL of your Jira instance (e.g., https://your-domain.atlassian.net) | |
| JIRA_EMAIL | Yes | Your email address associated with your Atlassian account | |
| JIRA_API_TOKEN | Yes | Your Atlassian API token | |
| JIRA_DEFAULT_USER | No | Default user for filtering Jira tickets (optional) |
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": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_my_jira_ticketsA | Retrieve all Jira tickets associated with the authenticated user (assigned, reported, or mentioned). Supports filtering by status, project, and custom username. |
| get_jira_ticketA | Get detailed information about a specific Jira issue by key (e.g. PROJ-123), including summary, description, priority, status, assignee, and comments. |
| search_jira_ticketsC | Search Jira issues using a custom JQL (Jira Query Language) string. |
| update_jira_ticketC | Edit fields on an existing Jira issue (summary, description, priority, labels, assignee) and optionally post a comment. |
| complete_jira_ticketA | Mark a Jira ticket as completed / done. Automatically identifies and executes the 'Done' or 'Resolved' workflow transition, with an optional resolution comment. |
| list_ticket_transitionsA | List all available workflow transitions for a Jira ticket to check allowable state changes. |
| transition_jira_ticketC | Move a Jira ticket to any workflow state by transition name or ID (e.g. 'In Progress', 'In Review', 'Done'). |
| add_jira_commentC | Add a new comment to a Jira ticket. |
| get_jira_user_infoA | Fetch the currently authenticated Jira user profile details (name, email, account ID, timezone). |
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 9 tools
There is clear overlap between complete_jira_ticket and transition_jira_ticket, since the former is a specialized version of the latter that targets Done/Resolved states. Additionally, update_jira_ticket optionally posts a comment while add_jira_comment is a dedicated comment tool, creating a minor ambiguity. The other tools (get_my_jira_tickets, search_jira_tickets, get_jira_ticket) are reasonably distinct, but these overlaps could lead to misselection.
All tool names use snake_case and follow a verb_noun pattern (get_, search_, update_, complete_, list_, transition_, add_). The only minor deviation is that list_ticket_transitions lacks the 'jira_' prefix present in most other names, but overall the convention is highly consistent.
With 9 tools, the set is well-scoped for a Jira integration. It covers read, search, update, workflow transitions, and comments without excessive bloat, and each tool earns its place.
The surface covers reading, searching, updating, transitioning, and commenting on tickets, but it is missing a create_jira_ticket operation, which is a core CRUD gap for a Jira server. Other potentially important operations like worklogs or attachments are also absent, but the missing create is the most notable deficiency.