---
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="/zh-Hant/docs/github-copilot/understanding/09-custom-instructions-rules-skills-hooks" />
  <Card title="下一篇" description="繼續看團隊上線前的安全、治理和計費。" href="/zh-Hant/docs/github-copilot/understanding/11-security-admin-billing" />
  <Card title="MCP 官方頁" description="回到官方重組頁深讀 GitHub MCP、企業 MCP 和 IDE MCP 配置。" href="/zh-Hant/docs/github-copilot/official/07-mcp" />
</Cards>
