GitHub MCP：让 LLM 直接操作仓库、PR、Issue 的官方服务器

简介

GitHub MCP 是 ModelContextProtocol 官方仓库维护的开发者集成服务器。它把 GitHub REST API 包装为 MCP 工具，让任何兼容 MCP 的客户端都能通过统一协议操作 GitHub，无需各自实现 OAuth 流程、无需封装分页、无需处理 API 限流。

对开发者而言，这意味着：让 AI 助理直接帮你"查一下这个仓库的 README"、"列出我这个项目的未关闭 Issue"、"基于这段 diff 创建一个 PR"、"给这个 Issue 加 label 并指派负责人"。

核心能力

工具名	用途	关键参数
`create_issue`	创建 Issue	`owner`、`repo`、`title`、`body`、`labels`、`assignees`
`get_issue`	获取 Issue 详情	`owner`、`repo`、`issue_number`
`list_issues`	列出仓库 Issue	`owner`、`repo`、`state`（open/closed）、`labels`
`update_issue`	更新 Issue	`owner`、`repo`、`issue_number`、`state`、`labels`
`add_issue_comment`	添加 Issue 评论	`owner`、`repo`、`issue_number`、`body`
`create_pull_request`	创建 PR	`owner`、`repo`、`title`、`body`、`head`、`base`
`get_pull_request`	获取 PR 详情	`owner`、`repo`、`pull_number`
`list_pull_requests`	列出仓库 PR	`owner`、`repo`、`state`、`sort`
`create_pull_request_review`	提交 PR Review	`owner`、`repo`、`pull_number`、`event`、`body`
`merge_pull_request`	合并 PR	`owner`、`repo`、`pull_number`、`commit_title`
`get_file_contents`	读取文件内容	`owner`、`repo`、`path`、`branch`
`create_or_update_file`	创建/更新文件	`owner`、`repo`、`path`、`content`、`message`、`branch`
`push_files`	批量推送多文件	`owner`、`repo`、`branch`、`files[]`
`create_branch`	创建分支	`owner`、`repo`、`branch`、`from_branch`
`fork_repository`	Fork 仓库	`owner`、`repo`
`search_repositories`	搜索仓库	`query`、`page`、`count`
`search_code`	搜索代码	`q`、`page`、`count`
`search_issues`	搜索 Issue/PR	`q`、`page`、`count`
`get_commits`	获取提交历史	`owner`、`repo`、`page`、`count`
`list_branches`	列出分支	`owner`、`repo`

申请 GitHub Personal Access Token

步骤 1：生成 Token

访问 https://github.com/settings/tokens?type=beta（推荐 Fine-grained Token）
点击 Generate new token
填写名称（如 mcp-github）、过期时间（建议 90 天）

步骤 2：配置权限

Fine-grained Token（推荐）：按仓库授权

Repository access：选 Only select repositories → 选你的项目
Permissions：
- Contents: Read and write（读写文件）
- Issues: Read and write（Issue 管理）
- Pull requests: Read and write（PR 管理）
- Metadata: Read-only（必选）

Classic Token（简单）：按 scope 授权

repo（完整仓库访问，含私有）
read:org（读取组织信息，可选）

步骤 3：复制 Token

生成后立即复制（形如 ghp_xxxxxxxxxxxx 或 github_pat_xxxxxxxxxxxx），离开页面后不可再查。

各客户端配置示例

Claude Code（CLI）

编辑 ~/.claude/claude_desktop_config.json：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here"
      }
    }
  }
}

Cursor

编辑 ~/.cursor/mcp.json：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here"
      }
    }
  }
}

VS Code（Continue 插件）

编辑 ~/.continue/config.json：

{
  "experimental": {
    "modelContextProtocolServers": [
      {
        "transport": {
          "type": "stdio",
          "command": "npx",
          "args": ["-y", "@modelcontextprotocol/server-github"]
        },
        "env": {
          "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_your_token_here"
        }
      }
    ]
  }
}

Cline 插件

通过 Cline: MCP Settings 命令打开 cline_mcp_settings.json，结构与 Claude Desktop 一致。

实战场景

场景 1：让 Claude Code 做"Issue 分流助理"

列出我仓库 myorg/webapp 中所有未关闭、无 assignee 的 Issue，
按 label 分类，
对 bug 类 Issue 自动指派给 @zhangsan，
对 feature 类 Issue 添加 "needs-triage" label 并评论"已收到，待评估"。

Claude Code 会调用 list_issues（filter assignee + state）→ 按标签分流 → update_issue（assignee）→ add_issue_comment。

场景 2：让 Cursor 做"PR 自动审查"

获取我仓库 myorg/webapp 的最新 5 个 open PR，
对每个 PR 读取 diff（get_pull_request），
检查是否有：
1. console.log 遗留
2. 硬编码密钥
3. 缺少错误处理
发现问题则在 PR 下评论，并标记 "needs-review"。

Cursor 会循环调用 list_pull_requests → get_pull_request → 分析 → add_issue_comment。

场景 3：让 Claude Code 做"文档批量更新"

读取我仓库 myorg/webapp 的 docs/ 目录下所有 .md 文件，
在每个文件末尾追加一行「最后更新：2026-08-06」，
创建一个新分支 docs/update-timestamp，
提交这些改动，
并创建 PR 标题"docs: 批量更新文档时间戳"。

Claude Code 会调用 get_file_contents（遍历）→ create_branch → create_or_update_file（循环）→ create_pull_request。

场景 4：让 VS Code 做"代码搜索跨仓库"

搜索 GitHub 上所有 TypeScript 仓库中使用了 "createTRPCNext" 的代码，
整理成表格：仓库名 / 文件路径 / 代码片段 / 星标数，
帮我了解 tRPC Next.js 的最佳实践。

Cline + Continue 会调用 search_code（q="createTRPCNext language:TypeScript"）→ search_repositories（补充星标）→ 格式化输出。

与 Filesystem MCP 的对比

维度	GitHub MCP	Filesystem MCP
操作对象	远程 Git 仓库	本地文件系统
版本管理	✅ 原生 Git	❌
协作能力	✅ PR/Issue	❌
适合场景	开源协作、团队项目	本地开发、脚本
读取速度	慢（API 调用）	快
写入门槛	高（需 Token + 分支）	低
推荐搭配	团队项目	本地实验

建议两个都装：Filesystem MCP 管本地代码与脚本，GitHub MCP 管远程仓库与协作。

注意事项

Token 保密：Personal Access Token 切勿提交到 Git，用 .env 或系统密钥链管理。
权限最小化：优先用 Fine-grained Token 只授权必要仓库，避免 Classic Token 的全量 repo 权限。
API 限流：GitHub API 认证用户 5000 次/小时，未认证 60 次/小时。MCP 服务器已内置退避，但批量操作仍需注意。
写入操作需谨慎：create_or_update_file 和 merge_pull_request 是不可逆操作，建议在 Prompt 中加"先确认再执行"。
分支保护：若仓库启用了分支保护，直接 push 到 main 会被拒，需走 PR 流程。
大文件读取：get_file_contents 对超过 1MB 的文件会截断，建议用 get_commits + diff 替代。
搜索语法：search_code 和 search_issues 使用 GitHub 搜索语法（如 language:TypeScript stars:>100），非自然语言。
私有仓库：Fine-grained Token 需显式选择私有仓库，Classic Token 用 repo scope 自动包含。
Webhook 替代：若需实时响应（如 Issue 创建即处理），建议用 GitHub Webhook + 服务器，MCP 是主动调用模式。

安全建议

只读 Token 优先：日常检索用 Read-only 权限，写入操作用临时 Token
Token 分仓：不同项目用不同 Token，避免一个泄露影响所有仓库
操作审计：让 AI 在每次写入前先描述将要做什么，人工确认后执行
分支隔离：AI 创建的 PR 一律走 feature 分支，禁止直接 push main
Token 轮换：每 90 天在 GitHub Settings 重新生成 Token

小结

GitHub MCP 是开发者最直接的 AI 编码协作入口：一个 Token、若干权限，就能让任意 MCP 客户端操作仓库、PR、Issue。对于需要"搜索代码、管理 Issue、自动审查 PR、批量更新文档"的开发场景，几乎是必装组件。建议搭配 Filesystem MCP（管理本地代码）和 Notion MCP（管理文档）组成开发者办公三件套。

下一篇我们会讲 Filesystem MCP，看如何让 LLM 读写本地文件系统。