jira-github-mcp

jira-github-mcp 是一个模块化、可扩展的模型上下文协议（MCP）服务端，用于集成 Jira 和 GitHub，通过 IDE 内的 AI 智能体实现开发者工作流的端到端自动化——从问题跟踪到代码变更和拉取请求管理。

一、用途 开发者在 Jira、GitHub 与 IDE 之间频繁切换上下文，会打断专注并拖慢交付。该项目将这一流程转变为无缝的、IDE 原生的对话式体验，让开发者使用自然语言和 AI 辅助自动化，从 Jira 问题一路推进到合并的拉取请求。

二、主要能力

• Jira 集成：按过滤器获取问题、通过 JQL 搜索、在工作流中流转问题状态。
• GitHub 集成：创建分支、打开和合并 PR。
• 本地 Git 操作：在本地暂存、提交和推送变更。
• IDE 原生：通过 stdio 与任何兼容 MCP 的智能体（例如 GitHub Copilot）配合使用。
• 端到端工作流：Jira 问题 → 分支 → 代码 → 提交 → PR → 合并 → Jira 状态更新。
• 提供 MCP 资源，用于工作流指引和当前问题上下文。

三、可用工具（示例工作流中的调用）

• jira_get_my_issues：列出分配给当前用户的问题。
• jira_search_issues：按状态或紧急程度排序。
• jira_get_issue(issue_key="KAN-42")：获取指定问题。
• create_branch_for_issue(issue_key="KAN-42")：为问题创建分支。
• jira_transition_issue(issue_key="KAN-42", to_status="In Progress")：流转问题状态。
• git_commit_and_push(message="Implement KAN-42", branch="feature/KAN-42")：提交并推送变更。
• create_pull_request(issue_key="KAN-42", branch_name="feature/KAN-42")：创建拉取请求。
• merge_pull_request(pr_number=123)：合并拉取请求。

四、项目结构

• src/：应用源代码
• server/：MCP 服务端入口点和工具注册
• config/：Jira 与 GitHub 的配置加载
• providers/：Jira/GitHub API 客户端与本地 Git 操作
• tools/：MCP 工具定义与实现
• resources/：MCP 资源（工作流指引、问题上下文）
• prompts/：服务端内部用于引导智能体行为的 AI 提示词
• tests/：集成与单元测试
• pyproject.toml：项目元数据与依赖
• uv.lock：依赖锁文件 架构的完整文档见 docs/architecture.md。

五、安装与设置 前置条件：

• Git（在 PATH 中可用）
• Jira 实例（Cloud 或自托管）且可访问 REST API v3
• 具备基于令牌 API 访问权限的 GitHub 仓库

步骤：

1. 克隆仓库。
2. 创建并激活虚拟环境。使用 uv（推荐）。
3. 安装依赖。使用 uv（推荐）。项目依赖 fastmcp：MCP 协议与服务端工具。
4. 配置环境变量。在仓库根目录创建 .env 文件。注意：JIRA_BASE_URL 不应以 / 结尾；GitHub PAT 仅授予所需的最小权限（分支、拉取请求等）。
5. 运行 MCP 服务端。以 Python 模块方式运行服务端；如果定义了入口点，也可以按入口点运行。
6. 从 MCP 客户端连接。若要与 MCP 客户端（例如 VS Code / GitHub Copilot）配合使用，请配置客户端从项目根目录运行服务端。示例 MCP 配置中，需将 /absolute/path/to/mcp-server 替换为仓库的实际路径。

连接到 GitHub Copilot：

• 打开 VS Code 并确保已安装 GitHub Copilot。
• 使用 GitHub 账号登录（若尚未登录）。
• 将 MCP 服务端配置添加到 VS Code 设置中（见上文 JSON）。
• 开始向 Copilot 提出自然语言问题——它会自动调用相关工具。

六、示例工作流（问题到合并的完整流程）

1. 发现下一个任务：询问 Copilot “分配给我最紧急的任务是什么？”。调用工具 jira_get_my_issues、jira_search_issues。选定问题 KAN-42。
2. 开始处理问题：询问 “开始处理 KAN-42”。调用 jira_get_issue(issue_key="KAN-42")、create_branch_for_issue(issue_key="KAN-42")、jira_transition_issue(issue_key="KAN-42", to_status="In Progress")。随后在编辑器中做出更改。
3. 提交更改：询问 “用消息 'Implement KAN-42' 提交我的更改”。调用 git_commit_and_push(message="Implement KAN-42", branch="feature/KAN-42")。
4. 创建拉取请求：询问 “为 KAN-42 创建 PR”。调用 create_pull_request(issue_key="KAN-42", branch_name="feature/KAN-42")、jira_transition_issue(issue_key="KAN-42", to_status="In Review")。代码审查与 CI 检查在 GitHub 上运行。
5. 合并并关闭问题：询问 “合并 PR 并将 KAN-42 移至 Done”。调用 merge_pull_request(pr_number=123)、jira_transition_issue(issue_key="KAN-42", to_status="Done")。问题关闭、代码合并、工作流完成。

七、适用场景

• Jira 问题、分支和拉取请求的日常开发工作流。
• 具有清晰拉取请求状态跟踪的代码审查流程。
• Sprint 执行与任务进度可见性。
• 快速缺陷修复与热修复工作流。
• 从问题到合并的端到端功能开发。
• 具有一致状态与归属跟踪的团队协作。

八、限制与未来增强 未来计划包括：多平台支持，将集成扩展到 GitHub 之外的平台（例如 GitLab）；更智能的工作流，如多仓库支持、可复用 JQL 模板和可配置的自动化规则；更深入的自动化，如 AI 辅助的 PR/提交起草、Webhook 驱动的同步和 CI/CD 反馈。 该 MCP 服务端通过单一的对话式界面连接 Jira 与 GitHub，减少人工协调，保持问题、分支与拉取请求同步，帮助团队专注开发而非流程。其设计注重清晰性、可扩展性和开发者体验。