Jira Extended MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JIRA_URL | Yes | Jira Cloud instance URL | |
| JIRA_EMAIL | Yes | Atlassian account email | |
| JIRA_API_TOKEN | Yes | API token | |
| JIRA_START_DATE_FIELD | No | Custom field ID for start date | customfield_10015 |
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_issueB | Create a Jira issue with full field support including parent, fixVersions, dates. Args: project: Project key (e.g., "KAN") issue_type: Issue type name (e.g., "Task", "Story", "Bug", "Epic") summary: Issue title description: Plain text description (supports Jira wiki markup for rich text) assignee_id: Atlassian account ID of assignee priority: Priority name (e.g., "High", "Medium", "Low") labels: List of label strings parent: Parent issue key for sub-tasks or stories under epics (e.g., "KAN-1") fix_versions: List of version names (e.g., ["v1.0.0"]) components: List of component names start_date: Start date in YYYY-MM-DD format due_date: Due date in YYYY-MM-DD format story_points: Story point estimate custom_fields: Dict of custom field IDs to values |
| create_issues_bulkA | Create multiple issues in bulk (max 50 per request). Args: issues: List of issue objects. Each must have: project, issue_type, summary. Optional: description, assignee_id, priority, labels, parent, fix_versions, components, start_date, due_date, custom_fields. |
| get_issueB | Get detailed information about a Jira issue. Args: issue_key: Issue key (e.g., "KAN-123") fields: Comma-separated field names to include (default: all) expand: Comma-separated expansions (e.g., "changelog,transitions") |
| update_issueA | Update an existing Jira issue. Only provided fields are changed. Args: issue_key: Issue key (e.g., "KAN-123") summary: New summary description: New description (plain text, supports Jira wiki markup for rich text) assignee_id: New assignee account ID priority: New priority name labels: Replace all labels fix_versions: Replace all fix versions (list of version names) components: Replace all components start_date: New start date (YYYY-MM-DD) due_date: New due date (YYYY-MM-DD) parent: New parent issue key story_points: New story point estimate custom_fields: Dict of custom field IDs to values |
| delete_issueB | Delete a Jira issue. Args: issue_key: Issue key (e.g., "KAN-123") delete_subtasks: Also delete subtasks (default: True) |
| search_issuesB | Search Jira issues using JQL. Args: jql: JQL query string (e.g., 'project = KAN AND status = "To Do"') fields: Comma-separated fields to return max_results: Maximum results (1-100, default 50) next_page_token: Token for next page (from previous response) |
| get_transitionsB | Get available status transitions for an issue. Args: issue_key: Issue key (e.g., "KAN-123") |
| transition_issueB | Transition an issue to a new status. Args: issue_key: Issue key (e.g., "KAN-123") transition_name: Transition name (e.g., "In Progress", "Done"). Used to auto-find ID. transition_id: Transition ID (takes priority over name) comment: Optional comment to add during transition resolution: Optional resolution name (e.g., "Done") for closing transitions |
| bulk_transitionC | Transition multiple issues to a new status. Args: issue_keys: List of issue keys (e.g., ["KAN-1", "KAN-2"]) transition_name: Target transition name (e.g., "Done") comment: Optional comment for all transitions |
| link_issuesB | Create a link between two issues. Args: inward_issue: Inward issue key (e.g., "KAN-1") outward_issue: Outward issue key (e.g., "KAN-2") link_type: Link type name (e.g., "Blocks", "Relates", "Duplicate", "Cloners") comment: Optional comment |
| get_issue_linksA | Get all links for an issue. Args: issue_key: Issue key (e.g., "KAN-123") |
| delete_issue_linkB | Delete an issue link by its ID. Args: link_id: The link ID (get from get_issue_links) |
| get_versionsB | Get all versions/releases for a project. Args: project_key: Project key (e.g., "KAN") |
| create_versionB | Create a new version/release in a project. Args: project_key: Project key (e.g., "KAN") name: Version name (e.g., "v1.0.0") description: Version description start_date: Start date (YYYY-MM-DD) release_date: Release date (YYYY-MM-DD) |
| update_versionB | Update an existing version/release. Args: version_id: Version ID (get from get_versions) name: New version name description: New description start_date: New start date (YYYY-MM-DD) release_date: New release date (YYYY-MM-DD) released: Mark as released archived: Mark as archived |
| delete_versionB | Delete a version/release. Args: version_id: Version ID to delete move_fix_issues_to: Version ID to reassign fix version issues move_affected_issues_to: Version ID to reassign affected version issues |
| get_sprintsB | Get sprints for a board. Args: board_id: Board ID state: Filter by state: "future", "active", "closed" (default: all) |
| move_to_sprintC | Move issues to a sprint. Args: sprint_id: Target sprint ID issue_keys: List of issue keys to move (e.g., ["KAN-1", "KAN-2"]) |
| add_commentB | Add a comment to an issue. Args: issue_key: Issue key (e.g., "KAN-123") body: Comment text (plain text, supports Jira wiki markup for rich text) |
| get_commentsB | Get comments on an issue. Args: issue_key: Issue key (e.g., "KAN-123") max_results: Maximum number of comments (default 50) |
| add_worklogB | Add a worklog entry to an issue. Args: issue_key: Issue key (e.g., "KAN-123") time_spent: Time spent string (e.g., "2h 30m", "1d", "4h") comment: Work description started: Start time in ISO format (e.g., "2026-03-24T09:00:00.000+0000") |
| get_projectsB | List all accessible Jira projects. |
| get_projectB | Get detailed information about a project. Args: project_key: Project key (e.g., "KAN") |
| get_boardsB | List Jira boards. Args: project_key: Filter by project key board_type: Filter by type: "scrum", "kanban", "simple" |
| get_current_userA | Get the currently authenticated Jira user. |
| search_usersC | Search for Jira users by name or email. Args: query: Search string (name, email, or display name) max_results: Maximum results (default 25) |
| get_createmetaA | Get issue creation metadata for a project (available issue types and fields). Args: project_key: Project key (e.g., "KAN") |
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 27 tools
Each tool targets a distinct Jira resource or action; single vs. bulk variants (create_issue vs. create_issues_bulk, transition_issue vs. bulk_transition) are clearly distinguished by descriptions. No meaningful overlap would cause misselection.
Names are consistently snake_case and mostly follow a verb_noun pattern. Minor deviations exist: bulk_transition uses a prefix while create_issues_bulk uses a suffix, and get_createmeta compresses a Jira term, but the set remains predictable.
27 tools is heavy for an MCP server and exceeds the typical 3-15 range. However, the breadth is aligned with an 'extended' Jira surface covering issues, versions, sprints, comments, worklogs, projects, and boards, so it is over-scoped rather than redundant.
Core issue lifecycle is well covered (CRUD, search, transitions, bulk operations, links), and versions have full CRUD. Gaps remain in secondary areas: comments only support add/get, worklogs only support add, and sprints/boards lack full lifecycle management.