先给判断
接入 GitHub MCP Server 时，“模型可以调用 GitHub”不是一个足够精确的权限描述。官方服务器提供 toolset、单工具选择和 read-only 模式；安全配置应该从任务需要完成的动作反推，而不是因为某个工具集合方便就全部打开。
三层选择
Toolset 是一组相关能力，例如 repos、issues 或 pull requests。它适合先定义任务边界，但集合内部可能仍包含读写工具。单工具 allowlist 可以进一步收窄上下文和可调用面。官方配置文档还说明，read-only 模式优先级更高，即使某个写工具被显式请求，也不会提供。
这三层解决的是“服务器暴露哪些工具”，不是“每个请求代表谁、能访问哪些仓库”。Token 的仓库范围、组织策略、分支保护和审批仍然是独立门。不能把 read-only flag 写成账号权限已经最小化。
一个只读研究任务
如果任务只是读取仓库文件、issue 和 pull request，可以先选择必要 toolset，再启用 read-only：
toolsets: repos,issues,pull_requests
mode: read-only之后检查三件事：工具清单里是否没有 mutation tool；token 是否只能访问目标仓库；模型提示词是否禁止把“发现问题”升级为“创建 issue”或“提交 PR”。工具可见性、身份授权和行为约束必须同时成立。
读写任务要分阶段
自动修复任务可能需要读取代码、提出补丁、创建分支和打开 PR。不要让一个长会话一开始就拥有完整写入面。更稳妥的流程是：只读收集 → 人工审阅候选 diff → 单独授权写入动作 → 再次验证目标仓库和分支。
即使服务器的 read-only 模式可靠，也无法替你验证第三方服务的 webhook、分支保护或机器人账号设置。外部凭据不应出现在提示词、日志、截图或文章示例中；示例只能使用明显的占位符。
失败方式
常见错误包括把 repos 当成纯读取集合、同时打开所有 toolsets、只依赖模型“不要写”的提示词、用个人高权限 PAT 做全局自动化，以及把远程 MCP URL 当成无需身份审查的公共服务。每一项都会让工具层与账号层的真实权限发生偏差。
验收清单
列出实际启用的 toolsets 和 tools
read-only 模式下确认写工具不可见
核对 token 的仓库/组织范围
验证分支保护和 PR 审批边界
用无害读取请求做 smoke test
记录模型请求与实际工具调用的差异适用边界
只读研究、代码搜索和 PR 综述适合先用只读模式。自动 merge、发布和生产配置不应因为 MCP 已连接就自动开放；这些动作需要独立的审批与回滚流程。
来源与边界
GitHub 官方仓库和配置指南支持 toolset、individual tools 与 read-only 的配置语义。本文没有测试某个真实账号，也没有展示或读取任何 token；账号权限、组织策略和实际网络部署仍需在目标环境中单独核验。