The Jira MCP Server connects Jira and Claude, enabling Jira issue management through Claude commands.
Capabilities:
Search Jira issues using JQL
View detailed information about specific issues
Update existing issues (title, description, status, assignee)
Add comments to issues
Retrieve project information
Create new Jira issues (note: a bug fix is in progress for this feature)
Provides tools for interacting with Jira, including searching issues using JQL, viewing issue details, updating existing issues, adding comments, and retrieving project information.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Jira MCP Server show me all open issues in the PROJ project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Jira와 Claude를 연결하는 Model Context Protocol (MCP) 서버입니다.
이슈 검색: JQL을 사용하여 Jira 이슈 검색
이슈 조회: 특정 이슈의 상세 정보 확인
이슈 생성: 새로운 Jira 이슈 생성
이슈 업데이트: 기존 이슈 수정 (제목, 설명, 상태, 담당자)
댓글 추가: 이슈에 댓글 추가
프로젝트 정보: 프로젝트 정보 조회
Related MCP server: Atlassian Jira MCP Server
.env 파일을 생성하고 다음 정보를 입력하세요:
JIRA_URL=https://your-domain.atlassian.net
JIRA_USERNAME=your-email@domain.com
JIRA_API_TOKEN=your-api-token
DEFAULT_PROJECT_KEY=PROJ참고: 설정 파일들은 config/ 폴더에 자동으로 생성됩니다.
Jira에 로그인
계정 설정 > 보안 > API 토큰 생성
생성된 토큰을 .env 파일의 JIRA_API_TOKEN에 입력
npm install대화형 설정 도구를 사용하여 쉽게 설정할 수 있습니다:
npm run setup이 명령어는:
Jira 연결 정보를 입력받습니다
config/.env 파일을 자동으로 생성합니다
config/claude_desktop_config.json 파일을 자동으로 생성합니다
Claude Desktop 설정 방법을 안내합니다
자동 설정 대신 수동으로 설정하려면 config/.env.example 파일을 복사하여 config/.env로 이름을 바꾸고 값을 수정하세요.
npm startClaude Desktop에서 이 MCP 서버를 사용하려면 설정 파일을 수정해야 합니다.
%APPDATA%\\Claude\\claude_desktop_config.json 파일을 편집:
{
"mcpServers": {
"jira": {
"command": "node",
"args": ["C:\\path\\to\\jira-mcp-server\\index.js"],
"env": {
"JIRA_URL": "https://your-domain.atlassian.net",
"JIRA_USERNAME": "your-email@domain.com",
"JIRA_API_TOKEN": "your-api-token",
"DEFAULT_PROJECT_KEY": "PROJ"
}
}
}
}~/Library/Application Support/Claude/claude_desktop_config.json 파일을 편집:
{
"mcpServers": {
"jira": {
"command": "node",
"args": ["/path/to/jira-mcp-server/index.js"],
"env": {
"JIRA_URL": "https://your-domain.atlassian.net",
"JIRA_USERNAME": "your-email@domain.com",
"JIRA_API_TOKEN": "your-api-token",
"DEFAULT_PROJECT_KEY": "PROJ"
}
}
}
}Claude에서 다음과 같은 명령을 사용할 수 있습니다:
"프로젝트 PROJ에서 상태가 Open인 이슈들을 찾아줘""PROJ 프로젝트에 '새로운 기능 개발' 제목으로 Task 이슈를 생성해줘""PROJ-123 이슈의 상태를 'In Progress'로 변경해줘""PROJ-123 이슈에 '작업을 시작했습니다' 댓글을 추가해줘"search_issues: JQL로 이슈 검색
get_issue: 특정 이슈 조회
create_issue: 새 이슈 생성
update_issue: 이슈 업데이트
add_comment: 댓글 추가
get_project_info: 프로젝트 정보 조회
Jira URL이 올바른지 확인
API 토큰이 유효한지 확인
사용자 이메일이 정확한지 확인
사용자가 해당 프로젝트에 접근 권한이 있는지 확인
이슈 생성/수정 권한이 있는지 확인
MIT License
An example tool that processes messages
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | Message to process |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Processes messages' implies some operation but doesn't specify whether it's read-only, destructive, requires authentication, has rate limits, or what the output looks like. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero waste, making it appropriately concise. However, it's front-loaded with minimal content and could benefit from more detail to improve utility without sacrificing brevity. It earns a 4 for efficiency but loses a point for under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that 'processes messages'. It doesn't explain what 'process' means, the behavior, or the result, leaving the agent with insufficient context to use it effectively. This is inadequate for a tool with even one parameter and no structured support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond the input schema, which has 100% coverage for the single parameter 'message'. The schema already describes it as 'Message to process'. Since schema coverage is high, the baseline score is 3, as the description doesn't compensate but doesn't need to given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'processes messages', which provides a basic verb+resource combination. However, it's vague about what 'processes' entails (e.g., filtering, transforming, analyzing) and doesn't differentiate from siblings (though none exist). This is a minimal viable description that states purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, such as context, prerequisites, or alternatives. With no siblings, differentiation isn't needed, but it still lacks any usage context (e.g., 'Use this to clean up message text before storage'). This leaves the agent with no operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'example_tool' stands alone with a distinct purpose, so agents cannot misselect between multiple options.
Since there is only one tool, naming consistency is inherently perfect. The tool name 'example_tool' follows a clear noun-based pattern, and with no other tools to compare, there are no inconsistencies in naming conventions.
A single tool is too few for a server named 'Jira MCP Server', which implies a domain related to Jira project management. This minimal set fails to cover the expected scope, such as CRUD operations for issues, projects, or workflows, making it inadequate for typical agent tasks.
The tool set is severely incomplete for the Jira domain. With only an 'example_tool' that processes messages, it lacks any operations for managing issues, projects, users, or other Jira entities, leaving obvious gaps that will cause agent failures in real-world scenarios.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect to Atlassian Jira, Confluence, and Compass to search, create, and manage your work.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Connect your team's living knowledge base — docs, data, issues, CRM — to Claude and ChatGPT.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SunWooBang/jira-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
