관계 추적, 최적화된 데이터 페이로드, AI 컨텍스트 창에 대한 데이터 정리를 통해 JIRA 데이터에 대한 액세스를 제공하는 MCP(모델 컨텍스트 프로토콜) 서버 구현입니다.
ℹ️ Confluence에는 별도의 MCP 서버가 있습니다.
이 MCP 서버는 Jira Cloud 와 Jira Server(데이터 센터) 인스턴스를 모두 지원합니다. JIRA_TYPE 환경 변수를 설정하여 사용할 인스턴스를 선택할 수 있습니다.
cloud (기본값): Jira Cloud(Atlassian 호스팅)용
server : Jira 서버/데이터 센터(자체 호스팅)용
서버는 선택한 유형에 맞는 올바른 API 버전과 인증 방법을 자동으로 사용합니다.
Related MCP server: Jira MCP Server
JQL을 사용하여 JIRA 문제 검색(요청당 최대 50개 결과)
댓글 기록 및 최적화된 페이로드를 사용하여 Epic Children을 검색합니다(요청당 최대 100개 이슈)
의견 및 관련 문제를 포함한 자세한 문제 정보를 얻으세요
JIRA 이슈 생성, 업데이트 및 관리
이슈에 댓글 추가
Atlassian 문서 형식에서 문제 언급 추출
문제 관계 추적(언급, 링크, 부모/자식, 에픽)
AI 컨텍스트 효율성을 위해 풍부한 JIRA 콘텐츠를 정리하고 변환합니다.
보안된 다중 파트 업로드 처리를 통한 파일 첨부 지원
Jira Cloud와 Jira Server(데이터 센터) API를 모두 지원합니다.
Bun (v1.0.0 이상)
API 액세스가 가능한 JIRA 계정
지엑스피1
git clone [repository-url]
cd jira-mcpbun install
bun run build적절한 구성 파일을 편집합니다.
맥OS:
클라인: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Claude 데스크톱: ~/Library/Application Support/Claude/claude_desktop_config.json
윈도우:
클라인: %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json
클로드 데스크톱: %APPDATA%\Claude Desktop\claude_desktop_config.json
리눅스:
클라인: ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Claude Desktop: 안타깝게도 아직 존재하지 않습니다.
mcpServers 개체 아래에 다음 구성을 추가합니다.
{
"mcpServers": {
"jira": {
"command": "node",
"args": ["/absolute/path/to/jira-mcp/build/index.js"],
"env": {
"JIRA_API_TOKEN": "your_api_token",
"JIRA_BASE_URL": "your_jira_instance_url",
"JIRA_USER_EMAIL": "your_email",
"JIRA_TYPE": "cloud"
}
}
}
}Cline의 MCP 설정에서 MCP 서버를 다시 시작하세요. Claude Desktop을 다시 시작하여 새 MCP 서버를 로드하세요.
테스트 실행:
bun test개발을 위한 시청 모드:
bun run dev변경 후 다시 빌드하려면:
bun run buildJQL을 사용하여 JIRA 이슈를 검색하세요. 요청당 최대 50개의 결과를 반환합니다.
입력 스키마:
{
searchString: string; // JQL search string
}댓글과 관계 데이터를 포함하여 서사시에 있는 모든 아동 관련 이슈를 받아보세요. 요청당 100개 이슈로 제한됩니다.
입력 스키마:
{
epicKey: string; // The key of the epic issue
}댓글과 모든 관계를 포함하여 특정 JIRA 이슈에 대한 자세한 정보를 얻으세요.
입력 스키마:
{
issueId: string; // The ID or key of the JIRA issue
}지정된 필드로 새로운 JIRA 이슈를 생성합니다.
입력 스키마:
{
projectKey: string, // The project key where the issue will be created
issueType: string, // The type of issue (e.g., "Bug", "Story", "Task")
summary: string, // The issue summary/title
description?: string, // Optional issue description
fields?: { // Optional additional fields
[key: string]: any
}
}기존 JIRA 문제의 필드를 업데이트합니다.
입력 스키마:
{
issueKey: string, // The key of the issue to update
fields: { // Fields to update
[key: string]: any
}
}JIRA 이슈에 파일을 첨부합니다.
입력 스키마:
{
issueKey: string, // The key of the issue
fileContent: string, // Base64 encoded file content
filename: string // Name of the file to be attached
}JIRA 이슈에 댓글을 추가합니다. 일반 텍스트를 입력받아 내부적으로 필요한 Atlassian 문서 형식으로 변환합니다.
입력 스키마:
{
issueIdOrKey: string, // The ID or key of the issue to add the comment to
body: string // The content of the comment (plain text)
}Atlassian 문서 형식에서 텍스트를 추출합니다.
설명 및 댓글에서 트랙 문제 언급
관계 유형과 공식적인 문제 링크를 유지합니다.
부모와 자식의 관계를 유지합니다
서사시적 연관성을 추적합니다
작성자 정보가 포함된 댓글 기록이 포함되어 있습니다.
응답에서 불필요한 메타데이터를 제거합니다.
언급된 내용에 대한 콘텐츠 노드를 재귀적으로 처리합니다.
중복 제거 문제 언급
Strict 모드에서 TypeScript로 빌드됨
향상된 성능을 위해 Bun 런타임을 사용합니다.
최적화된 빌드를 위한 Vite
JIRA REST API v3를 사용합니다
API 토큰을 사용한 기본 인증
관련 데이터에 대한 일괄 API 요청
AI 컨텍스트 창에 대한 최적화된 응답 페이로드
복잡한 Atlassian 구조의 효율적인 변환
강력한 오류 처리
속도 제한 고려 사항
최대 한도:
검색 결과: 요청당 50개 이슈
Epic Children: 요청당 100개 호
보안 파일 첨부를 위한 다중 파트 양식 데이터 지원
자동 콘텐츠 유형 감지 및 검증
서버는 포괄적인 오류 처리 전략을 구현합니다.
네트워크 오류 감지 및 적절한 메시징
HTTP 상태 코드 처리(특히 문제의 경우 404)
상태 코드가 포함된 자세한 오류 메시지
콘솔에 오류 세부 정보 로깅
모든 매개변수에 대한 입력 검증
MCP 프로토콜을 통한 안전한 오류 전파
일반적인 JIRA API 오류에 대한 특수 처리
첨부 파일에 대한 Base64 검증
다중 파트 요청 실패 처리
속도 제한 감지
첨부 매개변수 검증
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 LICENCE 파일을 참조하세요.
Add a file attachment to a JIRA issue
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | The key of the issue to add attachment to | |
| fileContent | Yes | Base64 encoded content of the file | |
| filename | Yes | Name of the file to be attached |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits beyond the basic action. It fails to mention important details like required permissions, file size limits, or whether the attachment replaces existing ones. The description carries the full burden but only states the action.
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, concise sentence that communicates the essential purpose without any unnecessary words. It is well-structured and immediately understandable.
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?
For a simple tool with three parameters and no output schema, the description is adequate but incomplete. It does not mention constraints like base64 encoding (though schema does), file size limits, or whether the tool returns anything. Given the simplicity, a 3 is fair.
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 input schema has 100% coverage with clear parameter descriptions (filename, issueKey, fileContent). The tool description does not add extra meaning beyond the schema, so a baseline of 3 is appropriate.
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 clearly states the tool's purpose: adding a file attachment to a JIRA issue. It uses a specific verb ('Add') and resource ('file attachment to a JIRA issue'), and distinguishes it from sibling tools like add_comment or create_issue.
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?
No guidance on when to use this tool versus alternatives. For example, it doesn't mention that attachments are only possible from a certain issue type or that there are size limits. The description is purely declarative without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a comment to a JIRA issue
| Name | Required | Description | Default |
|---|---|---|---|
| issueIdOrKey | Yes | The ID or key of the issue to add the comment to | |
| body | Yes | The content of the comment (plain text) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits like whether the comment is appended, supports rich text, or requires specific permissions.
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?
Single sentence, no unnecessary words. Direct and efficient.
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?
For a simple tool with two parameters, the description is adequate. No output schema, but the function is straightforward. Could mention if comment is appended or replaces.
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?
Schema coverage is 100% and descriptions are clear. Description does not add additional meaning beyond the schema.
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 clearly states the action ('Add a comment') and the resource ('JIRA issue'), with a specific verb and resource. It distinguishes from siblings like add_attachment and create_issue.
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?
No guidance on when to use this tool versus alternatives, such as when to add attachment or update issue. No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new JIRA issue
| Name | Required | Description | Default |
|---|---|---|---|
| projectKey | Yes | The project key where the issue will be created | |
| issueType | Yes | The type of issue to create (e.g., "Bug", "Story", "Task") | |
| summary | Yes | The issue summary/title | |
| description | No | The issue description | |
| fields | No | Additional fields to set on the issue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details beyond the fact that it creates. It does not mention permissions, side effects, return value, or any constraints, leaving the agent underinformed.
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 extremely concise, which is generally positive. However, given the tool's complexity (5 parameters, nested objects), it may benefit from slightly more detail without losing brevity.
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?
The description is too sparse for a creation tool with no output schema. It fails to mention what the tool returns, any required permissions, or potential side effects, leaving significant gaps for the agent.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter information beyond what the schema already provides, so no increase is warranted.
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 clearly states 'Create a new JIRA issue', specifying a concrete action and resource. It distinguishes itself from sibling tools like update_issue, add_attachment, and search_issues.
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 implies usage for creating issues but provides no guidance on when not to use it or alternatives. The context of sibling tools is present but not explicitly addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all child issues in an epic including their comments
| Name | Required | Description | Default |
|---|---|---|---|
| epicKey | Yes | The key of the epic issue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions returning child issues and comments, but omits details such as pagination, sorting, limits, error handling, or whether the result is a flat list or nested. This is insufficient for a retrieval tool.
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 concise sentence with no wasted words. However, it lacks structure such as bullets or examples that could improve readability. Still appropriate for a simple tool.
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 no output schema and no annotations, the description should explain the return value more fully. It mentions comments but not that it returns a list of issue objects. Moderate completeness.
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?
Schema coverage is 100% (epicKey described). The description adds no additional meaning to the parameter beyond what the schema already provides. Baseline is 3 for full coverage.
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 clearly states the tool retrieves child issues of an epic including their comments. It uses a specific verb (get) and resource (epic children). This distinguishes it from siblings like get_issue (single issue) and search_issues (search).
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?
No guidance on when to use this tool versus alternatives like search_issues. No prerequisites or context provided. The description only states what it does, without usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific JIRA issue including comments
| Name | Required | Description | Default |
|---|---|---|---|
| issueId | Yes | The ID or key of the JIRA issue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, permissions, or response format, leaving the agent uninformed about side effects.
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?
Single sentence that is front-loaded with key action and resource, no unnecessary words.
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?
For a simple tool with one parameter and no output schema, the description adequately explains the purpose, though it could mention return format or data scope for full completeness.
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?
Schema coverage is 100% for the single parameter, and the description adds no new meaning beyond the schema's description of issueId. Baseline 3 applies as per rules.
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 clearly states 'Get detailed information about a specific JIRA issue including comments', specifying the verb, resource, and distinguishing it from sibling tools like get_epic_children or get_transitions.
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?
Implied usage for retrieving detailed info for one issue, but no explicit guidance on when to use versus search_issues or alternatives, nor any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available status transitions for a JIRA issue
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | The key of the issue to get transitions for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates a read operation ('get') but does not disclose any potential restrictions or side effects. Without annotations, more detail on authorization or result filtering would be helpful.
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?
Single sentence, no wasted words. Front-loaded with clear purpose.
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?
No output schema present, and the description does not explain the return format (e.g., list of transition objects). While adequate for a simple tool, could be more complete.
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 input schema already fully describes the only parameter (issueKey). The description adds no additional semantic value beyond what is in the schema.
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?
Description clearly states 'Get available status transitions for a JIRA issue' with specific verb and resource. Clearly distinguishes from sibling tools like transition_issue which applies a transition.
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?
No guidance on when to use this tool versus alternatives like transition_issue. Does not provide context for prerequisites or typical usage flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search JIRA issues using JQL
| Name | Required | Description | Default |
|---|---|---|---|
| searchString | Yes | JQL search string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It does not disclose important behavioral traits such as whether the operation is read-only, pagination behavior, error handling for invalid JQL, or any authentication requirements.
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, front-loaded sentence with no unnecessary words. Every word serves a purpose.
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?
Despite having only one parameter, the description lacks critical details such as result format, pagination, sorting, or limits. For a search tool, an agent needs to know these aspects to use it properly. The absence of an output schema amplifies this gap.
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 input schema is fully covered with a description for the single parameter searchString ('JQL search string'), so the description adds no additional meaning beyond the schema. Baseline 3 applies.
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 clearly states the verb 'Search' and the resource 'JIRA issues using JQL', which is specific and immediately distinguishes this tool from siblings like get_issue (retrieve by ID) or create_issue (creation).
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 only implies usage via JQL but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_issue for specific issues, or other search tools). No when-not-to or exclusionary criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the status of a JIRA issue by performing a transition
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | The key of the issue to transition | |
| transitionId | Yes | The ID of the transition to perform | |
| comment | No | Optional comment to add with the transition |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only says 'change the status' with no details on side effects, permissions, or required knowledge of transition IDs. This is insufficient for safe invocation.
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?
Single sentence, no redundancy, but too brief to be informative. Sacrifices clarity for brevity.
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?
No output schema, no annotations, and no explanation of how to obtain transition IDs or what happens after transition. Incomplete for effective agent use.
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?
Schema coverage is 100% with descriptions; the tool description adds no extra meaning beyond what the schema already provides. Baseline score applies.
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 verb 'change' and resource 'status of a JIRA issue', but uses the jargon 'transition' which may not be clear to all users. It distinguishes from general 'update_issue' but could be more specific.
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?
No guidance on when to use this tool versus siblings like 'get_transitions' or 'update_issue'. The agent must infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing JIRA issue
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | The key of the issue to update | |
| fields | Yes | Fields to update on the issue |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'Update an existing JIRA issue', lacking details on permissions, error handling, partial update semantics, or consequences of invalid issue keys.
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 no waste, but it is too minimal. Conciseness is achieved at the cost of completeness.
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 absence of output schema and the presence of many sibling tools, the description is incomplete. It does not explain how to structure the fields object or handle partial updates.
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?
Parameters have schema descriptions (100% coverage), so baseline is 3. The description does not add meaning beyond the schema; the 'fields' object description is generic and offers no guidance on expected properties or format.
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 clearly states the verb 'Update' and resource 'existing JIRA issue', distinguishing it from sibling tools like create_issue and transition_issue.
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 implies use for modifying an existing issue but does not explicitly state when to use it versus alternatives like transition_issue for status changes or add_comment for comments. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0add_attachmentadd_commentcreate_issueget_epic_childrenget_issueget_transitionssearch_issuestransition_issueupdate_issueScored across 9 tools
Each tool has a clearly distinct purpose targeting specific JIRA operations: create, get, update, search, transition, add attachments/comments, and get epic children. There is no overlap or ambiguity between tools like 'get_issue' and 'search_issues' or 'update_issue' and 'transition_issue', making misselection unlikely.
All tools follow a consistent verb_noun naming pattern with snake_case throughout (e.g., create_issue, get_issue, update_issue). The verbs are appropriate and predictable, with no mixing of conventions or styles, ensuring readability and coherence.
With 9 tools, the server is well-scoped for JIRA operations, covering core workflows like issue management, searching, and status transitions. Each tool earns its place without being overly sparse or bloated, fitting typical server sizes of 3-15 tools.
The tool set provides strong coverage for JIRA issue lifecycle, including CRUD operations (create, get, update), searching, transitions, and attachments/comments. A minor gap exists with no delete_issue tool, but agents can work around this, and other operations like epic handling are partially covered.
Intelligent context infrastructure for AI teams: knowledge graph, sessions, tasks, documents.
Individual-analyst context layer: recall, remember, and reconcile your data and engineering context.
Shared, versioned context that humans and AI agents can publish, review, annotate, and continue.
Shared, permission-aware company context for AI agents, with provenance, approvals and audit.
