Cursor AI 接入 GitHub MCP 服务器完整指南

Cursor 的 Agent 模式已经能读写代码、执行终端命令，但它默认看不到你的 GitHub 仓库动态。通过 MCP（Model Context Protocol）把 GitHub 服务器接进来，Agent 就能直接查询 issue、拉取 PR、读取仓库信息。本文基于 YouTube 频道 JustBoz 的实操演示，拆解完整配置流程。

为什么值得接入 GitHub MCP

MCP 是 Anthropic 提出的开放协议，让 AI 工具以标准化方式调用外部服务。Cursor 作为较早支持 MCP 的编辑器，在侧边栏提供了专门的 MCPs 管理面板。接入 GitHub 服务器后，你可以在对话里直接让 Agent 执行"列出我所有待处理的 pull request"这类操作，而不需要手动复制粘贴仓库链接。

JustBoz 在视频中强调的核心价值在于：把 GitHub 的上下文直接喂给 Agent，减少来回切换浏览器和编辑器的次数。对于日常需要处理多个仓库的开发者，这个流程能明显压缩重复操作的时间。

MCP 采用客户端-服务器架构：Cursor 作为 MCP 客户端，在启动时读取 mcp.json 中的服务器定义，并以子进程方式拉起每个服务器（如 npx @modelcontextprotocol/server-github）。服务器通过标准输入输出（stdio）与客户端交换 JSON-RPC 消息，并向客户端声明自己提供哪些工具（tools）、资源（resources）和提示模板（prompts）。Agent 在对话中决定调用某个工具时，客户端把调用请求转发给对应服务器，服务器再去请求 GitHub REST API，最后把结果回传给模型。因此，接入一个 MCP 服务器本质上是给 Agent 增加了一组可调用的外部函数，而令牌就是这些函数访问 GitHub 时的身份凭证。

第一步：创建 GitHub 个人访问令牌

整个流程的起点在 GitHub 的账户设置里。路径是：Settings → Developer settings → Personal access tokens。

创建令牌时有两点需要注意：

• 最小权限原则。只勾选你实际需要的 scope，不要图省事全选。GitHub MCP 服务器能做的事情取决于令牌权限，权限越少，泄露后的风险面越小。
• 立即复制。令牌只在生成时显示一次，页面刷新后就再也看不到了。如果没保存，只能删掉重新生成。

这是整个配置里最容易出错的环节——很多人习惯先点完所有选项再去复制，结果中途切换页面导致令牌丢失。

GitHub 目前同时提供两类个人访问令牌：经典令牌（Classic PAT）和细粒度令牌（Fine-grained PAT）。经典令牌以 scope 为粒度授权，可跨所有仓库生效，配置简单，MCP 服务器的文档通常以它为例；细粒度令牌则必须指定可访问的仓库范围，并可按读/写分别授予 issue、pull request、contents 等权限，权限边界更精确。如果只需要让 Agent 读取仓库信息与 PR 状态，细粒度令牌的只读权限组合已经足够，且泄露后的影响范围被限制在指定仓库内。选型时可以先按最小可用原则从细粒度令牌开始，遇到权限不足再逐项放行。

第二步：在 Cursor 中添加 MCP 服务器

回到 Cursor，点击左侧边栏的 Customize，然后在顶部标签栏打开 MCPs 面板。选择添加服务器，Cursor 会自动打开位于用户主目录下 .cursor 文件夹中的 mcp.json 文件。

在这个 JSON 文件里添加一个名为 GitHub 的条目，command 字段填写运行 GitHub MCP 服务器的命令。关键在于令牌的放置位置：JustBoz 明确建议把 token 写进该条目的 ENV 块，而不是放在 arguments 参数里。

这个细节值得展开说明。arguments 中的内容可能被命令日志、进程列表或调试输出记录下来，而环境变量相对隔离。虽然两种方式在功能上等效，但从凭据管理的角度看，ENV 块是更稳妥的选择。这个建议也符合十二要素应用（12-Factor App）中"配置存于环境"的原则。

mcp.json 中的每个服务器条目通常包含三个关键字段：command 指定要执行的程序（如 npx 或 docker），args 是传给该程序的参数（如包名与启动参数），env 是以键值对形式注入子进程的环境变量。GitHub MCP 服务器启动时会从环境变量（常见为 GITHUB_PERSONAL_ACCESS_TOKEN）读取令牌，因此把令牌放进 env 正是服务器期望的读取方式，而不是一种可有可无的偏好。另外，npx 方式首次运行会临时下载服务器包，需要本机已安装 Node.js；若不想依赖网络拉取，也可以改用全局安装或 Docker 镜像，并在 command 与 args 中相应调整。

第三步：验证连接是否生效

保存 mcp.json 后，回到 MCPs 标签页检查状态指示是否变绿。绿灯代表服务器已成功启动并完成握手。

但绿灯只是进程层面的确认，不代表 GitHub 认证也通过了。JustBoz 给出的验证方法是：直接让 Cursor 的 Agent 列出你的 open pull requests。如果能返回真实的 PR 列表，说明令牌权限、网络连接、服务器进程三个环节全部打通；如果返回空列表或报错，则需要回头检查 scope 是否覆盖了 repo 相关权限。

这个验证思路值得借鉴——用一次真实的 API 调用代替抽象的"连接成功"提示，能更早暴露权限配置问题。

这套配置适合谁

从实操角度看，这个流程的门槛不高，但有两个前提：一是你已经在使用 Cursor 的 Agent 功能，二是你有跨仓库检索的需求。如果你的工作流集中在单一仓库、且很少在编辑器里处理 issue 和 PR，接入 MCP 带来的收益有限。

反过来，如果你经常需要让 AI 帮忙梳理某个仓库的变更历史、或者批量检查 PR 状态，把 GitHub 作为 MCP 服务器接入是性价比较高的选择。配置一次，后续所有对话都能复用。

需要提醒的是，mcp.json 属于本地配置文件，其中的令牌以明文形式存储。如果你会把 .cursor 目录纳入版本控制或同步到云端，务必先把该文件加入忽略列表。

如果希望进一步降低明文令牌的风险，可以把令牌从 mcp.json 中移出，改为在启动命令里引用系统环境变量，让配置文件只保留变量名；或者把令牌存放在操作系统的密钥链中，由脚本在启动时注入。此外，定期轮换令牌、为不同用途分别创建令牌（例如一个只读令牌用于 MCP，另一个用于写操作），也能在令牌意外泄露时把损失控制在较小范围。这些做法并不改变配置流程本身，只是把凭据管理的细节再收紧一层。

小结

三步走完：GitHub 建令牌（最小权限、立即复制）、Cursor 里加服务器（令牌放 ENV 不放 arguments）、用真实 PR 查询验证连通性。整个过程十分钟以内可以完成，难点不在操作复杂度，而在凭据管理的细节。