Jira MCP Server Implementation

[ [

A server implementation adhering to the Model Context Protocol specification, specifically engineered for Atlassian Jira.

This module exposes Jira functionalities to AI agents by translating MCP commands into appropriate calls against the Jira REST API.

Deployment Instructions

Initial Setup

Prerequisite: Node.js runtime version 22.12.0 or higher is mandatory.

1. Token Generation: Secure a Jira Personal Access Token (PAT). Refer to this guide for assistance.

2. Configuration Injection into Claude Desktop settings:

   • macOS Path: ~/Library/Application Support/Claude/claude_desktop_config.json
   • Windows Path: Consult this reference

   Integrate the server definition into the mcpServers block:

   Standard Configuration (Linux/macOS):

   { "mcpServers": { "jira": { "command": "npx", "args": ["-y", "@parassolanki/jira-mcp-server@latest"], "env": { "JIRA_PERSONAL_ACCESS_TOKEN": "your_email@domain.com:your_generated_token", "JIRA_BASE_URL": "https://your-instance.atlassian.net" } } } }

   Windows Execution Variant:

   { "mcpServers": { "jira": { "command": "cmd /c npx", "args": ["-y", "@parassolanki/jira-mcp-server@latest"], "env": { "JIRA_PERSONAL_ACCESS_TOKEN": "your_email@domain.com:your_generated_token", "JIRA_BASE_URL": "https://your-instance.atlassian.net" } } } }

Available Functionalities (Tools)

1. list_projects: Retrieves an enumeration of available Jira projects.

   • Parameters:
     • query (String, optional): Criterion for filtering projects.
     • maxResults (Number, optional, limit 100): Caps the output size.
     • expand (String, optional): Requests inclusion of supplementary details (e.g., lead, issueTypes, url).

2. list_boards: Fetches project boards.

   • Parameters:
     • projectKeyOrId (String, required): The identifier for the target project.
     • name (String, optional): Board name filter.
     • maxResults (Number, optional, limit 100): Result count ceiling.
     • startAt (Number, optional): Pagination offset.
     • type (String, optional): Filter by board methodology (scrum or kanban).

3. list_sprints_from_board: Queries sprints associated with a specific board.

   • Parameters:
     • boardId (String, required): Unique identifier for the board.
     • maxResults (Number, optional, limit 100): Maximum number of sprints to retrieve.
     • startAt (Number, optional): Starting position for pagination.

4. list_issues_from_sprint: Extracts issues belonging to a designated sprint.

   • Parameters:
     • boardId (String, required): The board hosting the sprint.
     • sprintId (String, required): The sprint identifier.
     • maxResults (Number, optional, limit 100): Limit on returned issues.
     • startAt (Number, optional): Pagination index.
     • expand (String, optional): Requests verbose data via comma-separated values like schema or names.

5. create_issue: Registers a new item in Jira (currently limited to the 'Task' type).

   • Parameters:
     • projectKeyOrId (String, required): Destination project.
     • summary (String, required): Concise title for the new ticket.
     • description (String, required): Detailed context for the ticket.

Operational Examples

1. Query: "List every project managed in Jira" → Action: Invoke list_projects.
2. Query: "Identify all Kanban boards within the 'DEV' project" → Action: Execute list_boards with projectKeyOrId='DEV' and type='kanban'.
3. Query: "Retrieve sprints for board ID 123" → Action: Call list_sprints_from_board using board ID 123.
4. Query: "What tasks are pending in sprint 456 on board 123?" → Action: Use list_issues_from_sprint targeting sprint 456 on board 123.
5. Query: "Display the initial fifty items from the active sprint on the Marketing board" → Workflow: Chain calls: 1) list_boards (find Marketing ID), 2) list_sprints_from_board (find current sprint ID), 3) list_issues_from_sprint with maxResults=50.

Local Development Setup

1. Install required dependencies: shell pnpm install

2. Establish environment variables in a .env file: shell JIRA_PERSONAL_ACCESS_TOKEN=your_email@domain.com:your_generated_token JIRA_BASE_URL=jira_instance_url

3. Execute the server with live reloading: shell pnpm dev

4. Compile for production deployment: shell pnpm build

5. Start an interactive debugging session: shell pnpm inspector

Development Roadmap (TODOs)

• [x] Implemented: list_projects
• [x] Implemented: list_boards
• [x] Implemented: list_sprints_from_board
• [x] Implemented: list_issues_from_sprint
• [ ] Pending: get_issue_by_id_or_key
• [x] Implemented: create_issue (Task type only)
• [ ] Pending: create_issue (Support for Story, Epic, Sub-task types)
• [ ] Pending: update_issue
• [ ] Pending: delete_an_issue
• [ ] Pending: archieve_an_issue
• [ ] Pending: list_comments_from_issue
• [ ] Pending: get_comment_from_issue_by_id
• [ ] Pending: create_comment_in_issue
• [ ] Pending: update_comment_of_issue
• [ ] Pending: delete_comment_of_issue
• [ ] Pending: list_subtasks_from_issue
• [ ] Pending: get_user_by_username_or_key

---

Auxiliary Context on HTTP Requests (Wikipedia Reference):

XMLHttpRequest (XHR) is an Application Programming Interface (API) implemented as a JavaScript object. Its core utility is enabling web browser applications to dispatch HTTP requests to a remote server asynchronously, subsequent to the initial page load, and retrieve responses. XHR forms the foundational technology behind Asynchronous JavaScript and XML (Ajax). Before XHR's widespread adoption, server communication relied predominantly on standard hyperlink navigation or form submissions, which typically necessitated a full page refresh upon completion.

== Genesis == The underlying concept for enabling background communication originated in 2000 with Microsoft Outlook developers. This mechanism first appeared in Internet Explorer 5 (1999), though it initially utilized ActiveXObject("Msxml2.XMLHTTP") or ActiveXObject("Microsoft.XMLHTTP") instead of the standardized XMLHttpRequest identifier. By the release of Internet Explorer 7 (2006), universal support for the canonical XMLHttpRequest identifier was established across all major browser engines, including Mozilla's Gecko (2002), Safari 1.2 (2004), and Opera 8.0 (2005).

=== Standardization Milestones === The World Wide Web Consortium (W3C) released the first Working Draft specification for the XMLHttpRequest object on April 5, 2006. A subsequent Level 2 specification, introduced on February 25, 2008, augmented the object with capabilities for monitoring request progress, enabling cross-origin resource sharing (CORS), and processing raw byte streams. In late 2011, the Level 2 features were integrated back into the primary specification. Since the close of 2012, development responsibility transitioned to the WHATWG, which now maintains the living document using Web IDL definitions.

== Typical Operation Flow == Executing a request via XMLHttpRequest generally involves a sequence of programming actions:

1. Instantiate the object using its constructor.
2. Invoke the open() method to define the HTTP method, target Uniform Resource Identifier (URI), and whether the operation should be synchronous or asynchronous.
3. For asynchronous operations, define an event listener to handle state transitions.
4. Initiate the transmission by calling send().
5. Monitor state changes via the listener. Upon finalization (state transitions to 4, the 'done' state), the server's response data is typically accessible via the responseText property.

Beyond these fundamentals, XHR offers extensive configurability. Custom HTTP headers can be injected to guide server processing. Payload data can be uploaded during the send() invocation. Responses can be parsed directly into navigable JavaScript objects (e.g., from JSON) or streamed incrementally. Furthermore, operations can be preemptively halted (abort()) or configured with timeouts.