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

简介: 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 工具库 -> 每日更新 -> 尽在微信公众号 -> 搜一搜:蚝油菜花 🥦

相关文章
|
10月前
|
人工智能 自然语言处理 JavaScript
利用MCP Server革新软件测试:更智能、更高效的自动化
MCP Server革新软件测试:通过标准化协议让AI实时感知页面结构,实现自然语言驱动、自适应维护的自动化测试,大幅提升效率,降低脚本开发与维护成本,推动测试左移与持续测试落地。
|
JSON 安全 Java
API 一键转换 MCP 服务!Higress 助今日投资快速上线 MCP 市场
今日投资的技术负责人介绍了如何通过Higress MCP 市场完善的解决方案,快捷地将丰富的金融数据 API 转化为 MCP 工具,帮助用户通过 MCP 的方式非常轻松地调用专业金融数据,自由快速地构建自己的金融大模型应用。
1429 23
|
人工智能 安全 API
Higress MCP Server 安全再升级:API 认证为 AI 连接保驾护航
Higress MCP Server 新增了 API 认证功能,为 AI 连接提供安全保障。主要更新包括:1) 客户端到 MCP Server 的认证,支持 Key Auth、JWT Auth 和 OAuth2;2) MCP Server 到后端 API 的认证,增强第二阶段的安全性。新增功能如可重用认证方案、工具特定后端认证、透明凭证透传及灵活凭证管理,确保安全集成更多后端服务。通过 openapi-to-mcp 工具简化配置,减少手动工作量。企业版提供更高可用性保障,详情参见文档链接。
1928 42
|
11月前
|
开发工具 git 开发者
Git版本管理常见文件提交流程讲解
以上就是Git常见文件提交流程概述。掌握此流程对于任何使用Git进行版本控制和协同工作项目团队成员都至关重要。
402 13
|
人工智能 JSON API
0代码将存量 API 适配 MCP 协议
本文主要讲述通过 Nacos+Higress 的方案实现0代码改造将 Agent 连接到存量应用,能够显著降低存量应用的改造成本。
1800 44
0代码将存量 API 适配 MCP 协议
|
12月前
|
人工智能 API 定位技术
MCP 开发实战:手把手教你封装高德地图与 arXiv API
本教程为 MCP(Model Context Protocol)开发实战第二阶段,带你从零封装第三方 API 为 AI 模型可用工具。通过高德地图地理编码与 arXiv 论文检索两个实例,涵盖项目搭建、工具声明、资源定义、错误处理等核心内容,助你快速上手 MCP 开发并集成至 Claude 使用。
|
SQL JavaScript 关系型数据库
炸裂,Directus要干掉后台团队!GitHub 31K+星神器:SQL秒变API,你只管设计界面!
Directus 是一款开源的“开放数据平台”,可将 SQL 数据库秒变 REST+GraphQL API,并提供无代码数据管理界面。支持多数据库,适用于新旧项目,简化后端开发与维护。其核心功能包括自动化 API 生成、细粒度权限控制、可视化管理界面、无代码流程编排及灵活扩展机制,适用于企业 CMS、内部工具、数据分析等多种场景。
1871 1
|
数据可视化 Java 测试技术
Git Flow 现代实操指南含从代码提交到 CI/CD 全流程的实用技巧与长尾关键词解析 Git Flow
本指南结合现代技术趋势,详解Git Flow工作流,涵盖GitHub Actions自动化、Conventional Commits规范、Gitmoji可视化等内容,助你实现代码到CI/CD的全流程管理,提升团队开发效率与代码质量。
892 2
|
人工智能 安全 API
MCP vs 传统集成方案:REST API、GraphQL、gRPC的终极对比
作为一名长期关注AI技术发展的博主摘星,我深刻感受到了当前AI应用集成领域正在经历的巨大变革。随着Anthropic推出的Model Context Protocol(MCP,模型上下文协议)逐渐成熟,我们不得不重新审视传统的系统集成方案。在过去的几年中,REST API凭借其简单易用的特性成为了Web服务的标准选择,GraphQL以其灵活的数据查询能力赢得了前端开发者的青睐,而gRPC则以其高性能的特点在微服务架构中占据了重要地位。然而,当我们将视角转向AI应用场景时,这些传统方案都暴露出了一些局限性:REST API的静态接口设计难以适应AI模型的动态需求,GraphQL的复杂查询机制在处
649 0
MCP vs 传统集成方案:REST API、GraphQL、gRPC的终极对比

热门文章

最新文章