---
title: "10 · Copilot 和 MCP 怎么接"
description: "解释 MCP 什么时候值得接入 Copilot，如何把 GitHub、数据库、文档、监控和内部工具变成上下文来源。"
verifiedAt: "2026-05-06"
---

MCP（Model Context Protocol，模型上下文协议）是一个开放标准，让 Copilot 这样的 AI 工具通过统一接口接入外部系统。但 MCP 不应该为了新鲜感而接：只有当 Copilot 缺少外部系统事实时，MCP 才有价值——查 issue、PR、Actions、数据库 schema、内部文档、监控告警、工单状态，这些都比让模型凭记忆猜可靠。

> [!NOTE]
> **本章目标**：你会判断什么时候需要 MCP，知道 MCP client、server、tools、resources、prompts 的分工，并能给团队设计最小安全接入路径。

## 1. MCP 在 Copilot 里的位置

```mermaid
flowchart LR
  Copilot["Copilot Chat / Agent"] --> Client["MCP client"]
  Client --> Server["MCP server"]
  Server --> Tools["Tools: 执行动作"]
  Server --> Resources["Resources: 提供数据"]
  Server --> Prompts["Prompts: 预设任务"]
  Tools --> Systems["GitHub / DB / Docs / Monitoring"]
  Resources --> Systems
  Prompts --> Copilot
```

GitHub 官方定义里，MCP 是开放标准，用来让应用把上下文共享给大语言模型。放在 Copilot 里，它就是一层受控工具协议：Copilot 通过 MCP server 获取外部数据或执行外部动作。

## 2. 什么时候值得接 MCP

值得接：

- Copilot 必须读取最新 issue、PR、Actions、security alerts。
- 任务需要内部文档、API、数据库 schema 或工单事实。
- 团队希望统一工具入口，而不是每个人复制上下文。
- 外部系统变化快，不能靠静态的 custom instructions 维护。
- 你希望 agent 通过工具拿证据，再做代码变更。

不值得接：

- 一次性概念解释。
- 只需要项目长期规范，应该用 instructions。
- 只需要重复 prompt，应该用 prompt file。
- server 来源不可信。
- 工具会写入或删除，但没有审批和回滚。
- 你只是想“看看能不能更智能”。

MCP 的判断标准不是 server 有多少工具，而是这个任务缺哪类真实上下文。

## 3. Copilot 入口支持差异

官方文档列出的支持边界要分清：

- **IDEs**：支持本地 MCP server，远程 server 支持取决于编辑器和配置。
- **Copilot CLI**：支持本地和远程 MCP server；GitHub MCP server 是内置能力。
- **Copilot cloud agent**：支持仓库级 MCP server；GitHub MCP server 和 Playwright MCP server 有默认配置。
- **组织策略**：MCP servers in Copilot policy 可启用或禁用，官方文档说明该策略默认关闭。

所以“我本地能用 MCP”不等于组织、云端 agent 或同事也能用。上线前要把入口、策略和配置位置写清。

## 4. 最小安全模型

接入 MCP 前先回答 6 个问题：

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

答不清就不要上线。MCP server 可能读取文件、访问网络、调用 API、创建 issue、操作 PR；它是工程能力，不是普通文档。

## 5. 推荐接入顺序

1. 从只读 server 开始，例如 GitHub repo 查询、文档搜索、Fetch。
2. 在 Agent mode 中手动选择工具，确认 Copilot 会正确引用来源。
3. 把有效配置固化到个人 profile 或工作区 `.vscode/mcp.json`。
4. 团队共享时，用 PR 审查 server 配置。
5. 再按 toolset 分层开放写能力。
6. 最后才考虑 cloud agent 或企业级统一配置。

不要一开始就把数据库写操作、云平台变更、生产监控处理全部打开。

## 6. Prompt 写法

```text
任务：
修复登录错误提示。

使用 MCP：
先用 GitHub MCP 查 issue #123 和相关 PR。
如果需要文档，只用 internal-docs MCP 的 auth 文档。

权限：
不要调用写入工具。
不要访问数据库。
不要使用 Playwright 之外的网络工具。

验收：
说明引用了哪些 MCP 结果。
展示 diff 和测试输出。
```

关键是让 reviewer 看懂 Copilot 调用了哪些外部事实，以及这些事实如何影响代码改动。

## 本章自检

你应该能回答：

- 当前任务缺什么外部上下文？
- MCP server 是本地还是远程，谁维护？
- 工具是只读还是写入？
- 组织策略是否允许当前入口使用 MCP？
- 日志里能否看到 server 启动、工具调用和错误？

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

## 官方来源

- [About Model Context Protocol (MCP)](https://docs.github.com/en/copilot/concepts/context/mcp)：GitHub 官方 MCP 概念、可用入口和策略说明。
- [Extending GitHub Copilot Chat with MCP servers](https://docs.github.com/en/copilot/how-tos/provide-context/use-mcp-in-your-ide/extend-copilot-chat-with-mcp)：GitHub 官方 IDE MCP 使用流程。
- [Add and manage MCP servers in VS Code](https://code.visualstudio.com/docs/copilot/customization/mcp-servers)：VS Code 官方 MCP server 配置、信任和管理。

## 接下来去哪

<Cards>
  <Card title="上一篇" description="先确认 instructions、skills、hooks 和 plugins 的职责边界。" href="/docs/github-copilot/understanding/09-custom-instructions-rules-skills-hooks" />
  <Card title="下一篇" description="继续看团队上线前的安全、治理和计费。" href="/docs/github-copilot/understanding/11-security-admin-billing" />
  <Card title="MCP 官方页" description="回到官方重组页深读 GitHub MCP、企业 MCP 和 IDE MCP 配置。" href="/docs/github-copilot/official/07-mcp" />
</Cards>
