This server integrates Jira Server/Data Center (v7+) with AI clients (Claude Desktop, Cursor, Windsurf, LangChain) via the Model Context Protocol, enabling direct Jira operations through 8 tools:
get_current_user: Verify your PAT and retrieve account info (username, display name, email, timezone).
list_issues: Fetch issues filtered by assignee, reporter, watcher, status, project key, or custom JQL.
get_issue_detail: View full issue details (description, comments, sub-tasks, priority, status) with drift detection to warn when descriptions are outdated relative to comments.
create_issue: Create Tasks, Bugs, Stories, or Sub-tasks with fields like summary, description, priority, labels, due date, assignee, epic link, and custom fields. Supports dryRun to preview before creating.
update_issue: Change assignee, transition status, add comments, set/clear due dates, add/remove labels, and edit summary or description.
log_work: Record time spent on an issue (e.g., "2h 30m") with a start date and comment.
list_worklogs: Query worklogs by user and date range, returning either a summary aggregated by issue or detailed per-entry view (with IDs for deletion).
delete_worklog: Remove one or more worklogs, with mandatory dryRun preview before deletion.
Safety & Deployment: All write operations require explicit user confirmation. Supports both Stdio and HTTP transports, with multi-tenant deployment allowing multiple users to share one server instance using their own Jira credentials.
Provides tools for interacting with Jira Server/Data Center, enabling issue management, work logging, and project tracking.
Click on "Deploy 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 my open issues"
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.
MCP (Model Context Protocol) server tích hợp Jira cho Claude AI. Hỗ trợ Claude Desktop, Cursor, Windsurf, và LangChain tương tác trực tiếp với Jira Server/Data Center (không Cloud).
Thông tin | Giá trị |
Phiên bản | v1.4.0 |
Trạng thái | Production-ready |
Xác thực | Personal Access Token (PAT) |
Transports | Stdio (Claude Desktop), HTTP (LangChain, remote) |
8 Tools: get_current_user, list_issues, get_issue_detail, log_work, list_worklogs, delete_worklog, update_issue, create_issue
Drift Detection: Cảnh báo khi description lỗi thời so với comments
Tool Chaining: Gợi ý hành động tiếp theo sau mỗi tool
Safety-First: Write operations yêu cầu xác nhận từ user
Markdown Output: Format AI-friendly với priority emojis, quality analysis
Related MCP server: jira-mcp-server
Node.js 18+
Jira Server/Data Center v7+ (không Cloud)
Personal Access Token (PAT)
Clone & install:
git clone <repo-url> && cd jira-mcp-server && npm installCấu hình .env.local:
JIRA_BASE_URL=https://jira.company.com
JIRA_PAT=<your-pat-token>
JIRA_DEFAULT_PROJECT=XYZ # Tùy chọnBuild & Run:
npm run build # Stdio transport
HTTP_PORT=3000 MCP_AUTH_TOKEN=secret npm start # HTTP transportMỗi thành viên tự config trực tiếp trong MCP client của mình:
Claude Desktop (~/.claude/claude_desktop_config.json):
{
"mcpServers": {
"jira-mcp-server": {
"command": "node",
"args": ["/path/to/jira-mcp-server/dist/index.js"],
"env": {
"JIRA_BASE_URL": "https://jira.company.com",
"JIRA_PAT": "your-personal-pat-token"
}
}
}
}Cursor/Windsurf (.cursor/mcp.json hoặc .windsurf/mcp.json):
{
"mcpServers": {
"jira-mcp-server": {
"command": "node",
"args": ["/path/to/jira-mcp-server/dist/index.js"],
"env": {
"JIRA_BASE_URL": "https://jira.company.com",
"JIRA_PAT": "your-personal-pat-token"
}
}
}
}Lưu ý: File
.env.localchỉ cần khi dev local (npm run dev). Production dùngenvblock trong MCP config.
Claude Desktop: Xem claude-desktop-setup.md
Cursor/Windsurf: Xem Connection Guide
LangChain/Remote: Xem http-api-reference.md
npm run inspect # MCP Inspector at http://localhost:8000Hoặc trong Claude Desktop, thử: "Show me open issues"
Tất cả write operations (log_work, update_issue, create_issue, delete_worklog) yêu cầu xác nhận từ user.
Tool | Mô tả | Chủ yếu dùng cho |
get_current_user | Lấy thông tin user hiện tại (từ PAT) | Verify PAT, biết username cho JQL |
list_issues | Filter issues (assignee, status, custom JQL) | Xem danh sách work items |
get_issue_detail | Chi tiết issue + drift detection | Hiểu issue trước khi làm việc |
log_work | Ghi nhận giờ làm (yêu cầu startedAt) | Timesheet, tracking |
list_worklogs | Tổng giờ đã log (summary hoặc detail per-entry) | Báo cáo timesheet, lấy worklogId |
delete_worklog | Xoá worklog (batch + dryRun + best-effort) | Sửa log nhầm |
update_issue | Assign, labels, transition, comment, set/clear due date, sửa summary (tiêu đề) + description (mô tả) | Cập nhật trạng thái, nhãn, deadline, tiêu đề, mô tả |
create_issue | Tạo issue (Task, Bug, Story) | Tạo work item mới |
Ví dụ nhanh:
# Xem issues của tôi
list_issues({ statusFilter: "open" })
# Chi tiết issue
get_issue_detail({ issueKey: "PROJ-123" })
# Log 2 tiếng hôm qua
log_work({
issueKey: "PROJ-123",
timeSpent: "2h",
comment: "Fixed UI bug",
startedAt: "2026-04-12"
})
# Tổng giờ đã log tháng này (summary)
list_worklogs({})
# Xem detail từng worklog entry (kèm worklogId)
list_worklogs({ detail: true })
# Preview trước khi xoá
delete_worklog({
issueKey: "PROJ-123",
worklogIds: ["12345", "12346"],
dryRun: true
})
# Xoá thật sau khi user xác nhận
delete_worklog({
issueKey: "PROJ-123",
worklogIds: ["12345", "12346"]
})
# Chuyển sang Done
update_issue({
issueKey: "PROJ-123",
transitionName: "Done",
resolution: "Fixed"
})
# Update due date
update_issue({
issueKey: "PROJ-123",
dueDate: "2026-06-30"
})
# Gỡ due date
update_issue({
issueKey: "PROJ-123",
dueDate: "clear"
})
# Thêm labels
update_issue({
issueKey: "PROJ-123",
addLabels: ["backend", "urgent"]
})
# Xoá labels
update_issue({
issueKey: "PROJ-123",
removeLabels: ["blocked", "needs-info"]
})
# Xoá toàn bộ labels rồi set lại
update_issue({
issueKey: "PROJ-123",
clearLabels: true,
addLabels: ["triaged", "ready"]
})
# Đổi tiêu đề (summary)
update_issue({
issueKey: "PROJ-123",
summary: "Tiêu đề mới rõ ràng hơn"
})
# Replace toàn bộ mô tả (description, wiki markup)
update_issue({
issueKey: "PROJ-123",
description: "Mô tả mới\n\n* Bước 1\n* Bước 2"
})
# Combine: labels + assignee + transition
update_issue({
issueKey: "PROJ-123",
addLabels: ["urgent"],
assignee: "hieutv",
transitionName: "In Progress"
})
# Tạo task mới
create_issue({
projectKey: "PROJ",
issueType: "Task",
summary: "Implement feature",
description: "Add OAuth support",
priority: "High"
})Xem chi tiết: Tool Examples (nếu cần)
npm run build # TypeScript → dist/
npm run dev # Watch mode
npm start # Run server (stdio or HTTP)
npm run inspect # MCP Inspector (http://localhost:8000)src/
├── index.ts # Entry + transport selection
├── jira/
│ ├── client.ts # REST API wrapper
│ ├── tools/ # Tool registration split theo concern
│ │ ├── index.ts # Barrel — registerJiraTools()
│ │ ├── user-tools.ts # get_current_user
│ │ ├── issue-tools.ts # list_issues, get_issue_detail, update_issue
│ │ ├── issue-drift-warning.ts # Helper drift heuristic
│ │ ├── create-issue-tool.ts # create_issue (schema lớn)
│ │ └── worklog-tools.ts # log_work, list_worklogs, delete_worklog
│ └── formatter.ts # AI-friendly output
├── transports/
│ ├── stdio-transport.ts
│ └── http-transport.ts # Express + Bearer auth
└── shared/utils.ts # Error handling, chainingCho phép nhiều users dùng chung một MCP server, mỗi user có credentials Jira riêng.
Client (headers) → Nginx (:443 SSL) → Node.js (:3000) → Jira APIThêm X-Jira-* headers vào MCP client config:
{
"mcpServers": {
"jira": {
"type": "http",
"url": "https://mcp.company.com/mcp",
"headers": {
"Authorization": "Bearer <MCP_AUTH_TOKEN>",
"X-Jira-Base-Url": "https://jira.company.com",
"X-Jira-Pat": "<your-personal-token>"
}
}
}
}Header | Required | Description |
| Yes | Bearer token ( |
| No* | Jira server URL |
| No* | Personal Access Token |
*Fallback to server env vars nếu không truyền headers.
Chạy MCP server:
HTTP_PORT=3000 MCP_AUTH_TOKEN=<secret> npm startCấu hình Nginx: Copy deploy/nginx.conf.example và sửa domain.
SSL: certbot --nginx -d mcp.company.com
Tạo một Jira issue mới (Task, Sub-task, Bug, Story). Dùng dryRun=true để xem metadata (custom fields, users, epics) — không tạo issue. Dùng khi phân rã một task lớn thành các sub-task nhỏ hơn, hoặc khi tạo task từ file mô tả nghiệp vụ .md. Nếu người dùng yêu cầu tạo task mới như 'tạo task mới cho tôi nhé', hãy yêu cầu họ cung cấp các thông tin dựa trên ví dụ sau:
Dự án (Project Key): PROJECT_KEY
Loại Issue: Task
Tiêu đề: Phối hợp thực AM UBNB Hoài Hôi
Mô tả: Phối hợp thực AM UBNB Hoài Hôi
Mức độ ưu tiên: Low
Nhãn (Labels): ProjectLabels
Mã SPDA: PROJ ProjectSPDA
Công đoạn: Nghiên cứu và phát triển
Due Date: 2026-04-03
Assign cho: nghiath (optional)
Epic: PROJECT-100 (optional) ⚠️ PHẢI hỏi user xác nhận TRƯỚC KHI gọi tool này — hiển thị nội dung issue sẽ tạo cho user duyệt.
| Name | Required | Description | Default |
|---|---|---|---|
| projectKey | Yes | Project key, VD: 'PROJAI' | |
| dryRun | No | true = chỉ xem metadata (custom fields, users, epics) — không tạo issue | |
| issueType | No | Loại issue | Task |
| summary | No | Tiêu đề ngắn gọn của issue (bắt buộc khi tạo issue) | |
| description | No | Mô tả chi tiết issue (bắt buộc khi tạo issue) | |
| parentKey | No | Key của issue cha — bắt buộc nếu issueType là Sub-task | |
| priority | No | Mức độ ưu tiên (bắt buộc khi tạo issue) | |
| labels | No | Danh sách labels, VD: ['backend', 'urgent'] (bắt buộc khi tạo issue) | |
| spda | No | Mã SPDA (customfield_10100). VD: 'PROJ XXXXX' (bắt buộc khi tạo issue) | |
| congDoan | No | Công đoạn (customfield_10101). VD: 'Nghiên cứu và phát triển' (bắt buộc khi tạo issue) | |
| dueDate | No | Ngày hết hạn, format YYYY-MM-DD. VD: '2026-04-15' (bắt buộc khi tạo issue) | |
| assignee | No | Username của người được assign. Dùng dryRun=true để xem danh sách user khả dụng. VD: 'nghiath', 'admin'. Bỏ trống = không assign. | |
| epicKey | No | Key của Epic muốn liên kết. VD: 'PROJ-100'. Dùng dryRun=true để xem danh sách Epic đang mở. Bỏ trống = không link Epic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses dryRun behavior (only returns metadata, no creation) and implies mutation. Missing details on rate limits or auth requirements, but adequate for a creation 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?
Description is verbose with a long example and instructions. While front-loaded with purpose, the example could be shortened. Still structured and readable, but not maximally concise.
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 high schema coverage, no output schema, description covers creation, dryRun, and required confirmation. Could mention return type but acceptable without output schema.
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 basic descriptions. Description adds value by explaining when to use dryRun to see available users/epics, and providing context for assignee and epicKey fields 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?
Description clearly states it creates new Jira issues (Task, Sub-task, Bug, Story). It specifies the action (tạo = create) and resource (Jira issue). Distinguished from siblings like update_issue, which modifies existing 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?
Explicitly states when to use: breaking down large tasks into sub-tasks or creating tasks from .md files. Also includes a mandatory instruction to ask user confirmation before calling the tool, and provides a detailed example to guide user input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Xoá 1 hoặc nhiều worklog trên 1 Jira issue. ⚠️ DESTRUCTIVE. BẮT BUỘC chạy dryRun=true trước, show preview cho user, đợi xác nhận rồi mới chạy dryRun=false. adjustEstimate=auto (Jira tự cộng giờ đã xoá vào remaining estimate). Chỉ xoá được worklog của chính mình (hoặc admin). Dùng list_worklogs với detail=true để lấy worklogId.
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | Jira issue key, VD: 'VNPTAI-123' | |
| worklogIds | Yes | Array worklog ID cần xoá. Lấy từ `list_worklogs` với detail=true. | |
| dryRun | No | true = preview, không xoá thật. KHUYẾN CÁO mạnh chạy dryRun trước. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses destructive nature, mandatory dryRun step, adjustEstimate=auto behavior, and permission constraints. No annotations provided, so description fully carries transparency burden.
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?
Dense but clear paragraph; front-loaded with warnings and procedure. Could be slightly more structured (e.g., bullet points), but no wasted 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?
Covers procedure, permissions, parameter sources, and effect on estimate. Lacks explanation of return value/response format, but this is a destructive action where typical output is minimal.
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 covers all 3 parameters. Description adds context: dryRun for preview vs. actual delete, worklogIds sourced from list_worklogs, and adjustEstimate behavior. Exceeds baseline 3.
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?
Clearly states 'Xoá 1 hoặc nhiều worklog trên 1 Jira issue' (delete one or more worklogs on a Jira issue). Distinguishes from sibling tools like log_work and list_worklogs.
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?
Explicitly mandates dryRun=true first, user confirmation, then dryRun=false. Also notes permission restriction (only own worklogs or admin) and suggests using list_worklogs to obtain IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lấy thông tin user Jira hiện tại (ứng với PAT đang dùng). Trả về username, display name, email, timezone. Dùng để: (1) verify PAT hợp lệ, (2) biết username để dùng trong JQL hoặc assigneeFilter, (3) xác nhận đúng account khi dùng multi-tenant.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently explains that the tool returns user information and serves authentication/verification purposes. No side effects or advanced behaviors need disclosure; the description is honest and sufficient.
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: two sentences packed with purpose, return fields, and use cases. No wasted words, and key information is front-loaded.
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 no output schema, the description lists the return fields. It covers authorization context (PAT), common use cases, and multi-tenant awareness. No gaps are apparent for this simple tool.
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 zero parameters, so no parameter documentation is needed. The description implicitly acknowledges this by not mentioning any inputs. Baseline score of 4 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: retrieving current Jira user info. It specifies the returned fields (username, display name, email, timezone) and provides three concrete use cases. This fully distinguishes it from sibling tools like create_issue or list_worklogs.
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 explicitly lists when to use the tool: to verify PAT validity, get username for JQL/assigneeFilter, and confirm account in multi-tenant setups. It does not explicitly mention when not to use it, but for a simple read-only tool, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Đọc toàn bộ thông tin chi tiết của 1 Jira issue: mô tả đầy đủ, comments, sub-tasks, priority, status hiện tại. Dùng trước khi phân tích hoặc implement một task cụ thể.
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | Jira issue key, VD: 'PROJAI-123' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It explains the tool returns full details of an issue, implying a read-only operation, but does not mention authentication, rate limits, or error handling. The description is adequate but not exhaustive.
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, clear sentence that front-loads the purpose, lists key content, and provides a usage note. Every part is useful and concise.
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 low complexity and no output schema, the description sufficiently explains what the tool returns (description, comments, sub-tasks, priority, status) and when to use it. It is complete for its purpose.
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 a description for the single parameter (issueKey). The tool description does not add additional information beyond the schema, so the baseline score of 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 specifies the verb 'đọc' (read) and the resource 'Jira issue detail', listing included fields (description, comments, sub-tasks, priority, status). It clearly distinguishes from siblings like list_issues or get_current_user.
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 advises using the tool before analyzing or implementing a task, providing clear context. However, it does not explicitly state when not to use it or mention alternatives beyond the implied contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lấy danh sách Jira issues theo filter linh hoạt. Mặc định: issues được assign cho tôi, đang mở. Có thể lọc theo user khác (assigneeFilter), role (assignee/reporter/watcher), trạng thái (statusFilter), hoặc JQL tùy chỉnh (customJql = full override). Trước đây có tên list_my_open_issues.
| Name | Required | Description | Default |
|---|---|---|---|
| projectKey | No | Filter theo project key cụ thể, VD: 'PROJAI'. Bỏ trống = tất cả project. | |
| assigneeFilter | No | User để filter. 'currentUser()' = tôi (default). 'unassigned' = chưa assign (chỉ với assignee role). 'any' = bỏ qua filter user. Username cụ thể: 'nghiath', 'admin', v.v. | currentUser() |
| roleFilter | No | Role của user với issue. 'assignee' = được assign (default). 'reporter' = người tạo issue. 'watcher' = người đang theo dõi. | assignee |
| statusFilter | No | Filter theo nhóm trạng thái: 'open' = Open/To Do/Reopened, 'active' = In Progress, 'done' = Done/Resolved/Closed, 'all' = tất cả. | open |
| customJql | No | JQL tùy chỉnh — full override, không inject thêm gì. VD: 'project = PROJAI AND sprint in openSprints()' | |
| maxResults | No | Số lượng tối đa issues trả về |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It explains default roles and status groups and notes customJql overrides entirely. However, missing details on side effects, read-only nature, pagination, and error handling. Adequate but not comprehensive.
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?
Three sentences, front-loaded with main purpose. No wasted words, efficient. Slightly verbose due to Vietnamese, but still concise.
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 6 parameters, no output schema, and no annotations, the description covers defaults and filter logic. Lacks information on return structure, ordering, pagination limit (though maxResults is in schema), error cases. Moderately complete for a list tool.
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%, so baseline is 3. The description repeats some schema info (defaults, enums) and adds value by explaining customJql as full override. Does not significantly enhance beyond 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 tool retrieves a list of Jira issues with flexible filtering, specifying default behavior (assigned to current user, open). It distinguishes from siblings like get_issue_detail (single issue) but does not explicitly differentiate from other list tools.
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 explains default filters and options like customJql as full override, but does not provide explicit when-to-use or when-not-to-use guidance relative to sibling tools. Context is implied but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Truy vấn worklog của 1 user trong khoảng thời gian. Mặc định: current user, tháng hiện tại, summary aggregate theo issue. detail=true: show từng worklog entry với worklogId (dùng để lấy ID cho delete_worklog). Use case: 'tháng này tôi log bao nhiêu giờ', 'liệt kê chi tiết worklog tuần qua'.
| Name | Required | Description | Default |
|---|---|---|---|
| username | No | Username Jira (không phải display name). Bỏ trống = current user. | |
| dateFrom | No | Ngày bắt đầu YYYY-MM-DD. Bỏ trống = ngày 1 tháng hiện tại. | |
| dateTo | No | Ngày kết thúc YYYY-MM-DD. Bỏ trống = hôm nay. | |
| projectKey | No | Filter theo project key, VD: 'VNPTAI'. Bỏ trống = tất cả. | |
| detail | No | true = show từng worklog entry với worklogId (dùng cho delete_worklog). false/bỏ trống = summary aggregate theo issue. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains default behavior (current user, current month, summary aggregate), the effect of the detail parameter, and the purpose of worklogId. With no annotations, it carries the full burden and does so well, though it could mention authentication or project access constraints.
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 three concise sentences, front-loading the main purpose, then details, then use cases. No redundant information.
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 read-only list tool with no output schema, the description covers the essential: purpose, defaults, mode behavior, and a hint for deletion. It could mention output format or empty results, but overall it is sufficiently 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?
Schema descriptions already cover each parameter in detail (format, defaults). The description adds value by explaining the overall default behavior and the intended use of detail mode, though the schema coverage is already high.
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 it queries worklogs for a user in a time period, with defaults and two modes (summary vs detail). It provides specific use cases that illustrate the tool's purpose.
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 gives concrete use cases (e.g., 'how many hours did I log this month') and hints that detail mode provides worklogId for delete_worklog, but does not explicitly exclude its use for other tasks like viewing issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ghi nhận thời gian làm việc (logwork) lên một Jira issue. Dùng sau khi hoàn thành công việc để track effort. Ví dụ: đã làm 2 tiếng fix bug VNPTAI-456. ⚠️ PHẢI hỏi user xác nhận TRƯỚC KHI gọi tool này — không được tự động submit. Hiển thị nội dung sẽ log cho user review trước.
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | Jira issue key, VD: 'VNPTAI-123' | |
| timeSpent | Yes | Thời gian theo format Jira: '2h', '30m', '1h 30m', '1d'. 1d = 8h. | |
| comment | Yes | Mô tả ngắn gọn đã làm gì trong khoảng thời gian này | |
| startedAt | Yes | Ngày bắt đầu làm việc, format YYYY-MM-DD (VD: '2026-03-02'). BẮT BUỘC phải truyền. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is a write operation (logwork), requires user confirmation (display content for review before submission), and implies mutability. It does not detail auth needs or rate limits, but for a simple logging tool, this is sufficient.
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 three sentences long, front-loaded with the main purpose, followed by usage guidance and a strong warning. Every sentence adds value, and there is no redundant information.
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 4 required parameters, the description covers the action, required fields, and usage caution. It lacks details about return value (e.g., confirmation or worklog ID) and does not differentiate from sibling tools beyond purpose, but it is complete enough for a simple log tool.
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% (all 4 parameters described in schema). The description adds value by providing examples for timeSpent format ('2h', '30m', '1h 30m', '1d') and emphasizing that startedAt is required and its format (YYYY-MM-DD). This goes beyond the schema's basic type info.
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 'Ghi nhận thời gian làm việc' (log work time) and specifies the resource 'Jira issue' with an example (fix bug VNPTAI-456). It distinguishes itself from siblings like delete_worklog and list_worklogs by focusing on the creation of a work log entry.
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 explicitly states when to use: after completing work to track effort. It also provides a strong usage constraint: 'PHẢI hỏi user xác nhận TRƯỚC KHI gọi tool này — không được tự động submit' (must ask user confirmation before calling, not auto-submit). It does not explicitly mention alternatives or when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cập nhật Jira issue: assign/unassign user, chuyển trạng thái, thêm comment, hoặc xem transitions khả dụng. Dùng dryRun=true để xem danh sách transitions mà không thay đổi gì. Truyền assignee để gán/gỡ người làm. Truyền dueDate để đổi/gỡ deadline ('clear' = gỡ). Truyền chỉ comment (không transitionName) để thêm ghi chú mà không đổi status. Truyền transitionName để chuyển trạng thái (kèm comment, resolution nếu cần). Có thể combine assignee + dueDate + transitionName + comment trong cùng 1 call. ⚠️ PHẢI hỏi user xác nhận TRƯỚC KHI thay đổi assignee, due date, status hoặc thêm comment.
| Name | Required | Description | Default |
|---|---|---|---|
| issueKey | Yes | Jira issue key, VD: 'PROJAI-123' | |
| dryRun | No | true = chỉ xem transitions khả dụng, không thay đổi gì | |
| transitionName | No | Tên trạng thái muốn chuyển. VD: 'In Progress', 'Done'. Bỏ trống nếu chỉ muốn comment. | |
| resolution | No | Resolution khi đóng task. VD: 'Done', 'Fixed'. Chỉ cần khi chuyển sang Done/Resolved. | |
| comment | No | Ghi chú kèm theo. Có thể dùng độc lập (không cần transitionName) hoặc kèm transition. | |
| assignee | No | Username muốn assign. 'unassigned' = gỡ assignee (set null). Bỏ trống = không đổi assignee. VD: 'nghiath', 'hieutv'. Hỗ trợ fuzzy match. | |
| dueDate | No | Ngày hết hạn mới, format YYYY-MM-DD. 'clear' = gỡ due date. Bỏ trống = không đổi. VD: '2026-06-15'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses dryRun behavior for safe preview, ability to combine multiple changes, fuzzy match for assignee, and the need for user confirmation. No annotations exist, so description carries the burden well.
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?
Front-loaded with purpose, then uses bullet-like explanation for each field, ending with a warning. Slightly verbose in Vietnamese but well-structured and essential.
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?
Thoroughly covers all operations, combination rules, and safety requirements. No output schema but return values are obvious for a mutation tool. Complete enough for an agent to use correctly.
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?
Adds significant meaning beyond input schema: 'unassigned' for removing assignee, 'clear' for due date, comment independence, fuzzy match support. Schema coverage is 100% but description enriches understanding.
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 it updates Jira issues with specific actions: assign/unassign, change status, add comment, view transitions. Distinguishes from sibling tools like create_issue and list_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?
Provides clear guidance on when to use dryRun, how to assign/unassign, change due date, add comment, and combine actions. Includes a required user confirmation warning but lacks explicit when-not-to-use compared to siblings.
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.3.0create_issuedelete_worklogget_current_userget_issue_detaillist_issueslist_worklogslog_workupdate_issueScored across 8 tools
Each tool targets a distinct action or resource: creating issues, managing worklogs, retrieving user info, fetching issue details, listing issues, listing worklogs, logging work, and updating issues. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_issue, list_worklogs, update_issue). The verbs are descriptive and the nouns clearly indicate the resource being acted upon.
With 8 tools, the set is well-scoped for core Jira issue management tasks. It covers creation, updates, reads, and worklog operations. Slightly on the lower side, but sufficient for typical workflows.
The tool set covers most common operations: create, read, update issues, and manage worklogs. Missing a delete issue tool, but the inclusion of get_current_user and list_worklogs fills ancillary needs. Minor gaps exist.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Give Claude only the Google Drive files you choose. Every action logged.
