GitHub官方开源MCP服务!GitHub MCP Server:无缝集成GitHub API,实现Git流程完全自动化

本文涉及的产品
交互式建模 PAI-DSW,每月250计算时 3个月
模型在线服务 PAI-EAS,A10/V100等 500元 1个月
模型训练 PAI-DLC,100CU*H 3个月
简介: GitHub MCP Server是基于Model Context Protocol的服务器工具,提供与GitHub API的无缝集成,支持自动化处理问题、Pull Request和仓库管理等功能。

❤️ 如果你也关注 AI 的发展现状,且对 AI 应用开发感兴趣,我会每日分享大模型与 AI 领域的开源项目和应用,提供运行实例和实用教程,帮助你快速上手AI技术!

🥦 AI 在线答疑 -> 智能检索历史文章和开源项目 -> 丰富的 AI 工具库 -> 每日更新 -> 尽在微信公众号 -> 搜一搜:蚝油菜花 🥦


🎯 「GitHub重度用户看过来!这个开源神器让你告别重复操作,AI自动接管代码审查+问题管理」

大家好,我是蚝油菜花。你是否也经历过这些开发噩梦——

  • 👉 手动处理几十个GitHub问题,标签和指派人点到手软
  • 👉 代码审查时在PR间反复横跳,错过关键修改点
  • 👉 想批量更新仓库文件,却要逐个提交修改...

今天要介绍的 GitHub MCP Server ,正在重新定义GitHub自动化!这个基于Model Context Protocol的黑科技:

  • 全栈自动化:从问题管理到代码审查,覆盖GitHub全流程
  • 智能代码扫描:自动检测潜在问题,生成专业审查意见
  • 企业级扩展:支持私有化部署,金融/医疗场景也能安心用

已有团队用它1天处理完季度积压问题,开源项目靠它实现7×24小时无人值守审查——你的GitHub工作流,是时候注入「AI加速剂」了!

🚀 快速阅读

GitHub MCP Server是一个基于Model Context Protocol的服务器工具。

  1. 功能:支持自动化处理GitHub问题、Pull Request和仓库管理等操作。
  2. 技术:采用Docker容器化部署,通过GitHub API实现深度集成。

GitHub MCP Server 是什么

GitHub MCP Server

GitHub MCP Server是一个基于Model Context Protocol (MCP)的服务器工具,专为开发者设计,用于实现GitHub工作流的自动化。它通过标准化的协议与开发工具集成,提供统一的接口来操作GitHub资源。

该工具采用容器化设计,支持Docker快速部署,能够无缝对接VS Code等主流开发环境。其核心价值在于将复杂的GitHub API封装为简单的工具调用,显著降低自动化脚本的开发门槛。

GitHub MCP Server 的主要功能

  • 问题管理:支持批量创建、更新和关闭GitHub问题,自动添加标签和指派人。
  • Pull Request管理:提供自动合并、分支更新和智能代码审查功能。
  • 仓库内容操作:支持文件推送、分支创建和内容获取等仓库管理操作。
  • 代码扫描:自动检测代码质量问题,生成详细警报报告。
  • 搜索功能:支持跨仓库搜索代码片段、用户和项目信息。

如何运行 GitHub MCP Server

GitHub MCP Server 是一个Model Context Protocol (MCP)服务器,提供了与 GitHub API 的无缝集成,使开发者和工具能够实现高级自动化和交互功能。

用例

  • 自动化 GitHub 工作流和流程。
  • 从 GitHub 仓库中提取和分析数据。
  • 构建与 GitHub 生态系统交互的 AI 驱动工具和应用程序。

前提条件

1. 安装 Docker

要在一个容器中运行服务器,你需要安装Docker

2. 创建 GitHub 个人访问令牌

创建一个GitHub 个人访问令牌。MCP 服务器可以使用许多 GitHub API,因此请启用你认为合适的权限(要了解更多关于访问令牌的信息,请查看文档)。

安装

使用 VS Code

为了快速安装,可以使用此 README 顶部的一键安装按钮。

手动安装时,将以下 JSON 块添加到 VS Code 的用户设置(JSON)文件中。你可以通过按 Ctrl + Shift + P 并键入 Preferences: Open User Settings (JSON) 来完成此操作。

可选地,你可以在工作区中添加一个名为 .vscode/mcp.json 的文件。这将允许你与其他人共享配置。

注意:在 .vscode/mcp.json 文件中不需要 mcp 键。

{
   
  "mcp": {
   
    "inputs": [
      {
   
        "type": "promptString",
        "id": "github_token",
        "description": "GitHub 个人访问令牌",
        "password": true
      }
    ],
    "servers": {
   
      "github": {
   
        "command": "docker",
        "args": [
          "run",
          "-i",
          "--rm",
          "-e",
          "GITHUB_PERSONAL_ACCESS_TOKEN",
          "ghcr.io/github/github-mcp-server"
        ],
        "env": {
   
          "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}"
        }
      }
    }
  }
}

有关在 VS Code 的代理模式中使用 MCP 服务器工具的更多信息,请参阅agent mode documentation

使用 Claude Desktop

{
   
  "mcpServers": {
   
    "github": {
   
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
   
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

从源代码构建

如果你没有 Docker,可以使用 gocmd/github-mcp-server 目录中构建二进制文件,并使用 github-mcp-server stdio 命令,同时设置 GITHUB_PERSONAL_ACCESS_TOKEN 环境变量为你自己的令牌。

GitHub 企业服务器

可以使用 --gh-host 标志和 GH_HOST 环境变量来设置 GitHub 企业服务器主机名。

国际化 / 覆盖描述

可以通过在二进制文件所在的同一目录中创建一个 github-mcp-server-config.json 文件来覆盖工具的描述。

该文件应包含一个 JSON 对象,键为工具名称,值为新的描述。例如:

{
   
  "TOOL_ADD_ISSUE_COMMENT_DESCRIPTION": "替代描述",
  "TOOL_CREATE_BRANCH_DESCRIPTION": "在 GitHub 仓库中创建一个新分支"
}

可以通过运行带有 --export-translations 标志的二进制文件来导出当前的翻译。

此标志将保留你所做的任何翻译/覆盖,并添加自上次导出以来二进制文件中添加的任何新翻译。

./github-mcp-server --export-translations
cat github-mcp-server-config.json

也可以使用环境变量来覆盖描述。环境变量的名称与 JSON 文件中的键相同,但前缀为 GITHUB_MCP_ 并且全部大写。

例如,要覆盖 TOOL_ADD_ISSUE_COMMENT_DESCRIPTION 工具,可以设置以下环境变量:

export GITHUB_MCP_TOOL_ADD_ISSUE_COMMENT_DESCRIPTION="替代描述"

工具

用户

  • get_me - 获取经过身份验证的用户详细信息
    • 不需要参数

问题

  • get_issue - 获取仓库中问题的内容

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • issue_number: 问题编号(数字,必填)
  • get_issue_comments - 获取 GitHub 问题的评论

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • issue_number: 问题编号(数字,必填)
  • create_issue - 在 GitHub 仓库中创建新问题

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • title: 问题标题(字符串,必填)
    • body: 问题正文内容(字符串,可选)
    • assignees: 分配给此问题的用户名(字符串数组,可选)
    • labels: 应用于此问题的标签(字符串数组,可选)
  • add_issue_comment - 向问题添加评论

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • issue_number: 问题编号(数字,必填)
    • body: 评论文本(字符串,必填)
  • list_issues - 列出并筛选仓库问题

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • state: 按状态筛选('open', 'closed', 'all')(字符串,可选)
    • labels: 按标签筛选(字符串数组,可选)
    • sort: 按字段排序('created', 'updated', 'comments')(字符串,可选)
    • direction: 排序方向('asc', 'desc')(字符串,可选)
    • since: 按日期筛选(ISO 8601 时间戳)(字符串,可选)
    • page: 页码(数字,可选)
    • perPage: 每页结果数(数字,可选)
  • update_issue - 更新 GitHub 仓库中的现有问题

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • issue_number: 要更新的问题编号(数字,必填)
    • title: 新标题(字符串,可选)
    • body: 新描述(字符串,可选)
    • state: 新状态('open' 或 'closed')(字符串,可选)
    • labels: 新标签(字符串数组,可选)
    • assignees: 新分配者(字符串数组,可选)
    • milestone: 新里程碑编号(数字,可选)
  • search_issues - 搜索问题和拉取请求

    • query: 搜索查询(字符串,必填)
    • sort: 排序字段(字符串,可选)
    • order: 排序顺序(字符串,可选)
    • page: 页码(数字,可选)
    • perPage: 每页结果数(数字,可选)

拉取请求

  • get_pull_request - 获取特定拉取请求的详细信息

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • pullNumber: 拉取请求编号(数字,必填)
  • list_pull_requests - 列出并筛选仓库拉取请求

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • state: PR 状态(字符串,可选)
    • sort: 排序字段(字符串,可选)
    • direction: 排序方向(字符串,可选)
    • perPage: 每页结果数(数字,可选)
    • page: 页码(数字,可选)
  • merge_pull_request - 合并拉取请求

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • pullNumber: 拉取请求编号(数字,必填)
    • commit_title: 合并提交的标题(字符串,可选)
    • commit_message: 合并提交的消息(字符串,可选)
    • merge_method: 合并方法(字符串,可选)
  • get_pull_request_files - 获取拉取请求中更改的文件列表

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • pullNumber: 拉取请求编号(数字,必填)
  • get_pull_request_status - 获取拉取请求的所有状态检查的组合状态

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • pullNumber: 拉取请求编号(数字,必填)
  • update_pull_request_branch - 使用基础分支的最新更改更新拉取请求分支

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • pullNumber: 拉取请求编号(数字,必填)
    • expectedHeadSha: 拉取请求的 HEAD 引用的预期 SHA(字符串,可选)
  • get_pull_request_comments - 获取拉取请求的审查评论

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • pullNumber: 拉取请求编号(数字,必填)
  • get_pull_request_reviews - 获取拉取请求的审查

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • pullNumber: 拉取请求编号(数字,必填)
  • create_pull_request_review - 在拉取请求审查中创建审查

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • pullNumber: 拉取请求编号(数字,必填)
    • body: 审查评论文本(字符串,可选)
    • event: 审查操作('APPROVE', 'REQUEST_CHANGES', 'COMMENT')(字符串,必填)
    • commitId: 要审查的提交 SHA(字符串,可选)
    • comments: 放置在拉取请求更改上的行特定评论对象数组(数组,可选)
      • 对于内联评论:提供 path, position(或 line)和 body
      • 对于多行评论:提供 path, start_line, line,可选的 side/start_sidebody
  • create_pull_request - 创建新拉取请求

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • title: PR 标题(字符串,必填)
    • body: PR 描述(字符串,可选)
    • head: 包含更改的分支(字符串,必填)
    • base: 要合并到的分支(字符串,必填)
    • draft: 创建为草稿 PR(布尔值,可选)
    • maintainer_can_modify: 允许维护者编辑(布尔值,可选)
  • update_pull_request - 更新 GitHub 仓库中的现有拉取请求

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • pullNumber: 要更新的拉取请求编号(数字,必填)
    • title: 新标题(字符串,可选)
    • body: 新描述(字符串,可选)
    • state: 新状态('open' 或 'closed')(字符串,可选)
    • base: 新基础分支名称(字符串,可选)
    • maintainer_can_modify: 允许维护者编辑(布尔值,可选)

仓库

  • create_or_update_file - 在仓库中创建或更新单个文件

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • path: 文件路径(字符串,必填)
    • message: 提交消息(字符串,必填)
    • content: 文件内容(字符串,必填)
    • branch: 分支名称(字符串,可选)
    • sha: 如果更新文件,则为文件的 SHA(字符串,可选)
  • push_files - 在单个提交中推送多个文件

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • branch: 要推送的分支(字符串,必填)
    • files: 要推送的文件,每个文件具有路径和内容(数组,必填)
    • message: 提交消息(字符串,必填)
  • search_repositories - 搜索 GitHub 仓库

    • query: 搜索查询(字符串,必填)
    • sort: 排序字段(字符串,可选)
    • order: 排序顺序(字符串,可选)
    • page: 页码(数字,可选)
    • perPage: 每页结果数(数字,可选)
  • create_repository - 创建新的 GitHub 仓库

    • name: 仓库名称(字符串,必填)
    • description: 仓库描述(字符串,可选)
    • private: 仓库是否为私有(布尔值,可选)
    • autoInit: 自动初始化带有 README(布尔值,可选)
  • get_file_contents - 获取文件或目录的内容

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • path: 文件路径(字符串,必填)
    • ref: Git 引用(字符串,可选)
  • fork_repository - 分叉仓库

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • organization: 目标组织名称(字符串,可选)
  • create_branch - 创建新分支

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • branch: 新分支名称(字符串,必填)
    • sha: 创建分支的 SHA(字符串,必填)
  • list_commits - 获取仓库分支的提交

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • sha: 分支名称、标签或提交 SHA(字符串,可选)
    • path: 仅包含此文件路径的提交(字符串,可选)
    • page: 页码(数字,可选)
    • perPage: 每页结果数(数字,可选)

搜索

  • search_code - 在 GitHub 仓库中搜索代码

    • query: 搜索查询(字符串,必填)
    • sort: 排序字段(字符串,可选)
    • order: 排序顺序(字符串,可选)
    • page: 页码(数字,可选)
    • perPage: 每页结果数(数字,可选)
  • search_users - 搜索 GitHub 用户

    • query: 搜索查询(字符串,必填)
    • sort: 排序字段(字符串,可选)
    • order: 排序顺序(字符串,可选)
    • page: 页码(数字,可选)
    • perPage: 每页结果数(数字,可选)

代码扫描

  • get_code_scanning_alert - 获取代码扫描警报

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • alertNumber: 警报编号(数字,必填)
  • list_code_scanning_alerts - 列出仓库的代码扫描警报

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • ref: Git 引用(字符串,可选)
    • state: 警报状态(字符串,可选)
    • severity: 警报严重性(字符串,可选)

资源

仓库内容

  • 获取仓库内容
    检索特定路径下的仓库内容。
  • 模板: repo://{owner}/{repo}/contents{/path*}
  • 参数:

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • path: 文件或目录路径(字符串,可选)
  • 获取特定分支的仓库内容
    检索特定路径下的特定分支的仓库内容。

  • 模板: repo://{owner}/{repo}/refs/heads/{branch}/contents{/path*}
  • 参数:

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • branch: 分支名称(字符串,必填)
    • path: 文件或目录路径(字符串,可选)
  • 获取特定提交的仓库内容
    检索特定路径下的特定提交的仓库内容。

  • 模板: repo://{owner}/{repo}/sha/{sha}/contents{/path*}
  • 参数:

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • sha: 提交 SHA(字符串,必填)
    • path: 文件或目录路径(字符串,可选)
  • 获取特定标签的仓库内容
    检索特定路径下的特定标签的仓库内容。

  • 模板: repo://{owner}/{repo}/refs/tags/{tag}/contents{/path*}
  • 参数:

    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • tag: 标签名称(字符串,必填)
    • path: 文件或目录路径(字符串,可选)
  • 获取特定拉取请求的仓库内容
    检索特定路径下的特定拉取请求的仓库内容。

  • 模板: repo://{owner}/{repo}/refs/pull/{prNumber}/head/contents{/path*}
  • 参数:
    • owner: 仓库所有者(字符串,必填)
    • repo: 仓库名称(字符串,必填)
    • prNumber: 拉取请求编号(字符串,必填)
    • path: 文件或目录路径(字符串,可选)

资源


❤️ 如果你也关注 AI 的发展现状,且对 AI 应用开发感兴趣,我会每日分享大模型与 AI 领域的开源项目和应用,提供运行实例和实用教程,帮助你快速上手AI技术!

🥦 AI 在线答疑 -> 智能检索历史文章和开源项目 -> 丰富的 AI 工具库 -> 每日更新 -> 尽在微信公众号 -> 搜一搜:蚝油菜花 🥦

相关文章
|
3月前
|
监控 算法 API
拼多多API团购活动自动化:拼单成功率暴涨的幕后技术解析
本方案通过API自动化引擎破解传统团购效率低、响应慢、数据分散等问题,实现库存、价格、成团的实时联动。实战数据显示,成团时效提升74%,拼单成功率高达92%,人力成本下降80%。某生鲜商家接入后,月GMV突破500万元,成团率高达98.3%。API赋能团购,开启电商效率新纪元。
160 0
|
4月前
|
安全 API 数据安全/隐私保护
低代码革命:API无代码集成如何让企业“3天上线一个生态”?
在数字化转型浪潮中,API成为释放数据价值、提升企业效率的核心。本文详解API架构设计、安全实践与跨平台集成,为CTO提供效率提升指南,涵盖微服务、安全认证、协议选择、低代码集成及未来趋势,助力企业构建敏捷、安全、高效的数字生态。
|
4月前
|
存储 安全 API
订单处理效率提升80%?揭秘电商API自动化操作的隐藏技巧
本文全面解析电商API的使用方法,涵盖基础概念、实战操作与高级技巧,助力从业者从入门到精通掌握这一关键技术。内容包括API核心功能、接入流程、安全优化及多个业务创新案例,帮助提升电商运营效率与创新能力。
|
4月前
|
JSON JavaScript 测试技术
用Postman玩转电商API:一键测试+自动化请求教程
Postman 是电商 API 测试的高效工具,涵盖基础配置、自动化测试、环境管理与请求自动化,助你快速提升开发效率。
|
4月前
|
消息中间件 安全 数据可视化
降本增效新引擎:API集成如何让电商订单履约快人一步?
本文详解电商系统如何通过API与支付、物流、CRM三大第三方服务高效集成,涵盖技术实现、应用场景与商业价值,助力企业构建数字化竞争力。
|
2月前
|
缓存 运维 监控
API 别乱跑:自动化运维里的流量管理秘籍
API 别乱跑:自动化运维里的流量管理秘籍
145 9
|
2月前
|
开发工具 git 开发者
Git版本管理常见文件提交流程讲解
以上就是Git常见文件提交流程概述。掌握此流程对于任何使用Git进行版本控制和协同工作项目团队成员都至关重要。
106 13
|
2月前
|
人工智能 数据可视化 测试技术
AI 时代 API 自动化测试实战:Postman 断言的核心技巧与实战应用
AI 时代 API 自动化测试实战:Postman 断言的核心技巧与实战应用
404 11
|
2月前
|
JSON 监控 测试技术
亚马逊:调用订单退款API自动化处理售后请求,缩短用户等待时间
在电商运营中,售后效率直接影响用户体验与平台声誉。亚马逊订单退款API为卖家提供自动化工具,通过编程方式高效处理退款请求,显著缩短用户等待时间。本文详解如何集成该API,实现退款流程自动化,提升响应速度与用户满意度。
95 0
|
3月前
|
JSON 缓存 供应链
API 接口驱动 1688 采购自动化:从商品获取到下单支付的全流程贯通
在B2B电商采购中,1688开放平台通过API实现商品筛选、比价、下单、支付及物流跟踪的全流程自动化,大幅提升采购效率,降低人工成本与错误率。企业可无缝对接ERP系统,实现数据驱动决策,显著优化采购周期、成本与风险管控,助力数字化转型。

热门文章

最新文章