MCP 是什么

GitHub 官方定义里，MCP（Model Context Protocol）是一个开放标准，用来让应用把上下文共享给大语言模型。放到 Copilot 里看，它就是一层工具协议：Copilot 通过 MCP client（客户端）连接 MCP server（服务端），server 再提供 tools（可调用的动作）、resources（数据资源）和 prompts（预设任务入口）。

结论先说：MCP 的核心不是“多一个插件”，而是让 Copilot 以受控方式调用外部系统。

1. MCP 的四个角色

flowchart LR
    Copilot["Copilot Chat / Agent"] --> Client["MCP client"]
    Client --> Server["MCP server"]
    Server --> Tool["Tools: 执行动作"]
    Server --> Resource["Resources: 提供数据"]
    Server --> Prompt["Prompts: 预设交互入口"]
    Tool --> System["外部系统"]
    Resource --> System
    Prompt --> Copilot

    style Client fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Server fill:#dcfce7,stroke:#16a34a,stroke-width:2px
    style System fill:#fef3c7,stroke:#d97706,stroke-width:2px

• MCP client：VS Code、Copilot CLI、Cloud Agent 等负责连接 server 的宿主。
• MCP server：暴露工具和上下文的服务，可以本地运行，也可以远程访问。
• Tools：agent 可以调用的动作，例如搜索仓库、读取 issue、创建 PR。
• Resources：server 提供给 Chat 的数据，例如仓库内容、文档、对象详情。
• Prompts：server 预设的 slash command 式任务入口。

这层结构的好处是统一：不用每个工具都单独为 Copilot 写一套集成，也不用把外部系统状态手动复制进 Chat。

2. Copilot 哪些入口支持 MCP

GitHub 官方文档列出的支持边界：

• IDEs：广泛支持本地 MCP server，远程 MCP server 支持也在增长，具体看编辑器文档。
• Copilot CLI：支持本地和远程 MCP server；GitHub MCP server 是内置的，不需要额外配置。
• Copilot cloud agent：支持仓库级 MCP server；GitHub MCP server 和 Playwright MCP server 默认配置。

企业和组织可以通过 “MCP servers in Copilot” 策略启用或禁用 MCP。官方文档说明该策略默认关闭，所以团队里“我本地能用”不代表组织账号也能用。

3. 什么时候需要 MCP

适合：

• Copilot 需要查询 GitHub issue、PR、Actions、security alerts。
• Copilot 需要读内部文档、API、数据库或支持系统。
• 团队希望统一 server 配置，而不是让每个人手工复制上下文。
• 外部系统状态变化快，不能靠静态 instructions 维护。

不适合：

• 一次性解释概念。
• 只需要项目长期规范，此时用 instructions。
• 只需要重复 prompt，此时用 prompt file。
• 工具来源不可信，或无法说明它会读写什么。
• 没有审批和回滚，却想开放写操作。

4. 最小安全模型

接入 MCP 前先回答：

1. Server 来源：谁维护，是否官方或内部可信。
2. 运行位置：本地、远程、容器、企业私有环境。
3. 认证方式：OAuth、PAT、环境变量，还是输入变量。
4. 工具权限：只读、写入、审批、删除、执行命令。
5. 数据边界：能读哪些仓库、文件、API、日志和客户数据。
6. 失败证据：日志在哪里，如何重启，如何禁用。

这 6 个问题答不清，不要上线。

5. 典型接入路径

1. 从只读 server 开始，例如 Fetch、GitHub repo 查询、文档搜索。
2. 在 Agent mode 中手动选择工具，观察 Copilot 是否正确引用上下文。
3. 把有效配置固化到个人 profile 或工作区 .vscode/mcp.json。
4. 如果团队共享，提交 PR 审查 server 配置。
5. 需要更多动作时，再按 toolset 分层开放写能力。

深读：为什么不要默认启用所有工具

Agent 会根据任务目标自动选择工具。工具越多，模型越可能选择一个你没有预期的路径，也更难解释结果来自哪里。

商业级 MCP 接入应该从“这个任务缺什么上下文”出发，而不是从“这个 server 有多少工具”出发。

本章自检

1. 这个 MCP server 是否补了真实上下文缺口？
2. 它是本地 server 还是远程 server？
3. 它的工具是否按只读和写入分层？
4. 组织策略是否允许当前入口使用 MCP？
5. 是否能在日志里看到 server 启动、工具调用和错误？

通过标准：一个新人能看懂 server 用途、权限、配置位置和禁用方式。

官方来源

• About Model Context Protocol (MCP) —— GitHub 官方 MCP 概念、可用入口和策略说明。
• Extending GitHub Copilot Chat with MCP servers —— GitHub 官方 IDE MCP 使用流程。
• Add and manage MCP servers in VS Code —— VS Code 官方 MCP server 配置、信任和管理。

接下来去哪