MCP 連接器是什麼？給 ChatGPT 和 Claude 使用者的白話指南
用非工程語言說明 MCP 連接器、ChatGPT 和 Claude 怎麼使用 MCP，以及連接 AI 工具到工作資料前要檢查哪些權限。
2026年5月6日
MCP 連接器可以先把它理解成：讓 ChatGPT、Claude 或其他支援的 AI 工具，用一種標準方式去讀取你允許的外部資料，或呼叫你允許的工具。它不是「讓 AI 看見你所有資料」的魔法開關，而是一條需要伺服器、登入、權限與工具範圍共同決定的連接路徑。
Highlight Reel
把值得留下的 AI 對話變成下次可用的脈絡
用 Highlight Reel 保存有用的 AI 對話、重點和逐字稿；在支援 MCP 的 AI 用戶端中，再依權限搜尋、取回、重用。
如果你不是工程師，最簡單的說法是：MCP 是共通語言；MCP 連接器是某個 AI 用戶端和某個服務之間設定好的連線。這個服務可能是公司文件、內部 wiki、GitHub issue、Jira ticket、專案資料庫，或像 Highlight Reel 這種保存 AI 對話與逐字稿的地方。
先講結論
MCP 是 Model Context Protocol。官方文件把它描述成一個開放標準，讓 AI 應用程式可以連接外部系統、資料來源、工具與工作流程。
一個 MCP 連接器通常可以拆成三個部分：
| 部分 | 白話意思 | 例子 |
|---|---|---|
| AI 用戶端 | 你正在聊天或工作的 AI 工具 | ChatGPT、Claude、Claude Code、Cursor、Codex |
| MCP server | 對外提供資料或工具的服務 | 公司文件系統、任務系統、Highlight Reel |
| 權限 | AI 被允許讀取或執行的範圍 | 搜尋保存的逐字稿、取回某篇筆記、建立分享頁 |
最重要的界線是：MCP 不等於所有 AI 工具都能自動存取所有東西。實際行為取決於你用的是哪個 AI 用戶端、連接哪個 server、怎麼登入、授權了哪些 scope，以及該用戶端目前支援哪些 MCP 功能。
為什麼會需要 MCP？
AI 工作常卡在同一件事：脈絡一直重貼。
你可能在 ChatGPT 討論過產品定位，在 Claude 整理過研究，在 Codex 處理過實作細節，最後又把結論貼到 Notion、Google Docs 或 internal wiki。下一次開新對話時，AI 通常不知道前面發生過什麼，除非你再貼一次。
MCP 想解決的就是這種「每次都要重新搬脈絡」的問題。它提供一個標準方式，讓 AI 用戶端向外部系統要求資料或工具。
原本的流程像這樣：
複製背景資料 -> 貼進 AI -> 回答一次 -> 下次再重來有 MCP 之後，理想流程會變成：
連接已授權來源 -> 請 AI 搜尋或取回需要的資料 -> 人再檢查結果這個差異很大。前者把脈絡當成一次性文字，後者把脈絡當成可以被查找、取回、重用的工作資產。
「MCP 連接器」跟「MCP server」一樣嗎？
不完全一樣。
一般使用者常說「MCP 連接器」，因為產品體驗就是「我把 ChatGPT 或 Claude 接到某個服務」。但在 MCP 的技術語言裡，提供資料或工具的服務通常叫做 MCP server；呼叫這些能力的 AI 工具叫做 MCP client。
可以用這張表理解：
| 你看到的詞 | 通常代表什麼 |
|---|---|
| MCP | 讓 AI 工具連接外部系統的協議或共通規則 |
| MCP server | 對 AI 暴露資料、工具或工作流程的服務 |
| MCP client | 可以呼叫 MCP server 的 AI 用戶端 |
| MCP connector | 使用者眼中的「這個 AI 工具已經接上那個服務」 |
| ChatGPT app | OpenAI 目前在許多文件中使用的產品稱呼，包含 MCP-powered custom apps |
| Claude custom connector | Anthropic 在 Claude 產品中對 remote MCP 連接的稱呼 |
OpenAI 文件目前在許多地方把過去稱為 connectors 的資料型功能改叫 apps。搜尋時你仍然會看到「ChatGPT MCP connector」，但在實際介面或官方文件中，可能會看到 apps、custom apps 或 MCP apps。
MCP 連接器可以做什麼？
MCP 連接器能做什麼，不是由「MCP」這三個字直接決定，而是由 MCP server 提供的工具、AI 用戶端允許的能力，以及你的授權範圍一起決定。
常見能力包含：
| 能力 | AI 可以做什麼 | 工作例子 |
|---|---|---|
| Search | 搜尋連接來源裡的相關項目 | 「找出我們討論定價方案的那段保存對話。」 |
| Fetch | 取回某個指定項目的完整內容 | 「打開這個 Highlight Reel 頁面背後的逐字稿。」 |
| Read tools | 讀資料但不改資料 | 「列出最近的專案決策筆記。」 |
| Write tools | 建立或修改資料 | 「把這段核准後的摘要建立成新的分享頁。」 |
| Workflow tools | 觸發定義好的動作 | 「開一張 Jira ticket，附上整理後的背景。」 |
安全起點通常是 read-only，也就是先讓 AI 搜尋和取回資料。等你確認結果穩定、權限清楚、工具行為可預期，再考慮 create、update 或其他會改動資料的工具。
連接 MCP 時實際會發生什麼？
一個常見的 remote MCP 流程大概是：
- 你在 AI 用戶端加入 connector 或 app 的 URL。
- AI 用戶端讀取 MCP server 宣告的工具或能力。
- 如果需要登入，你會走 OAuth 或其他驗證流程。
- 你選擇是否在某次對話中啟用這個連接器。
- 當你提出需求，模型可能會呼叫已允許的工具。
- 你檢查結果；如果是寫入或修改資料，還可能需要額外確認。
OAuth 很常出現在 remote MCP 連接裡，因為它可以讓服務代表你操作，而不是把密碼交給 AI 用戶端。你真正要看的不是「有沒有接上」，而是「我接上的是誰、它能讀什麼、能不能改資料、之後能不能撤銷」。
ChatGPT MCP：使用者要注意什麼？
ChatGPT 這邊的命名比較容易混淆。很多使用者仍然搜尋 ChatGPT connectors，但 OpenAI 目前在文件和介面中更常使用 apps 或 MCP apps。
對使用者來說，比命名更重要的是這幾點：
- ChatGPT 是否能使用某個 MCP-powered app，會受方案、工作區設定、管理員權限與目前產品支援影響。
- OpenAI 的 developer mode 文件描述的是更完整的 MCP client access，包含 read 和 write tools，但它也明確把這類能力視為需要負責任設定的高風險功能。
- OpenAI Help Center 說明，會寫入或修改資料的動作會有確認流程。
- company knowledge 或 deep research 類型的使用情境通常偏向 search/fetch，也就是讀取與取回資料。
- 工作區管理員可能需要審核、發布、限制誰能使用，以及控制哪些 actions 可以被啟用。
所以當有人說「ChatGPT MCP 連接器」，他可能指的是幾種不同東西：讀取型資料連接、developer mode 裡的 custom app，或工作區核准過的 app。不要只聽名字，要看實際權限。
Claude MCP：使用者要注意什麼？
Claude 也有多個 MCP 入口。
你可能會在這些地方遇到 MCP：
- Claude 或 Claude Desktop 的 custom connectors
- Claude Code 裡設定的 local 或 remote MCP servers
- Claude API 的 Messages API remote MCP connector
Anthropic 的 Claude custom connector 文件提醒使用者只連接可信任的 server，並仔細檢查 OAuth 和 requested permissions。Claude API 文件則把 remote MCP connector 描述成讓 Messages API 直接連接 remote MCP servers，不需要另外實作 MCP client，但也列出目前限制，例如 API 端支援重點在 tool calls。
白話版結論是：Claude 可以透過 MCP 連到外部工具與脈絡，但 Claude web、Claude Desktop、Claude Code 和 Claude API 的設定方式與限制不一樣。不要假設一個地方能做的事，另一個地方也完全相同。
連接前要檢查哪些權限？
把 MCP 連接器當成工作整合工具來看，不要當成一般聊天設定。連接前至少問這些問題：
| 問題 | 為什麼重要 |
|---|---|
| 這個 connector 是誰建立、誰託管的？ | remote MCP server 會收到和你授權相關的請求。 |
| 它可以讀哪些資料？ | 搜尋標題和讀完整逐字稿是不同敏感度。 |
| 它可以 create、update、delete 嗎？ | 寫入工具會真的改變資料，需要更高審查。 |
| AI 用戶端會不會要求確認？ | 確認流程能降低誤操作，但你仍要看清楚 payload。 |
| 是否可以撤銷授權？ | 不再使用的連接器應該能被移除或斷開。 |
| 工作區或方案允許嗎？ | 管理員設定與產品 rollout 會影響可用功能。 |
MCP 有用，是因為它讓 AI 可以有結構地使用外部脈絡。也正因如此，它的權限應該像 GitHub app、Slack app 或公司內部整合一樣被認真看待。
Highlight Reel 在這裡扮演什麼角色？
Highlight Reel 解決的是另一個前置問題：有用的 AI 對話不該只躺在某個聊天紀錄裡。
當你把重要對話、摘要、逐字稿或決策脈絡保存到 Highlight Reel，它們就比較像可重用的工作資產，而不是一次性 chat debris。透過 Highlight Reel MCP endpoint，支援的 AI 用戶端可以在你授權的範圍內搜尋保存的對話、取回有用的內容，並在支援且經過確認的情況下建立新的保存頁面。
例如，未來你可以在新的 AI 工作階段中問：
搜尋我保存的 Highlight Reel 對話，找出產品定位相關的討論，
再把相關逐字稿當成這次 landing page 草稿的背景脈絡。這不代表 AI 會自動判斷所有事情，也不代表所有 client 都支援同樣行為。authentication、user permission、client support 和 tool approval 仍然決定最後會發生什麼。MCP 做的是讓你保存好的脈絡有機會被下一個工具重新使用。
決策指南：你現在需要 MCP 連接器嗎？
| 情境 | 需要 MCP 嗎？ | 比較好的預設 |
|---|---|---|
| 只是要把一個答案給同事看 | 不一定 | 乾淨分享頁或 Markdown 匯出 |
| 每次都在重貼同一份專案背景 | 值得考慮 | 先保存來源，再讓支援的 client 搜尋 |
| 需要 AI 搜尋過去的對話或文件 | 通常需要 | 從 search/fetch 這種讀取工具開始 |
| 需要 AI 建立或更新紀錄 | 看情況 | 只在權限清楚、可確認時啟用 write tools |
| 內容含有客戶或內部敏感資料 | 謹慎 | 最小權限、先測 read-only、審查 scope |
| 你用的 AI client 尚未支援 | 不需要硬上 | 先用匯出、複製貼上或原生分享 |
常見問題
MCP 只給工程師用嗎？
不是。工程師通常負責建立或設定 MCP server，但使用者價值不只在工程。當 AI 工具可以安全地讀取保存文件、專案筆記或對話紀錄時，非工程角色也能少重貼很多背景。
MCP 代表 ChatGPT 和 Claude 可以看見我的所有資料嗎？
不是。MCP access 取決於 connector、驗證方式、scope、server 設計和 AI 用戶端實作。好的連接器應該只暴露你授權的工具與資料。
ChatGPT connectors 和 ChatGPT apps 是同一件事嗎？
不完全是同一個詞，但在目前 OpenAI 文件中，很多過去叫 connectors 的 ChatGPT 資料型功能已改稱 apps。搜尋語言和產品命名可能不同，所以要以你當下看到的 ChatGPT 介面與官方文件為準。
MCP 連接器可以寫入或修改資料嗎？
有些可以。OpenAI developer mode 文件描述 full MCP access 可以包含 write tools；OpenAI Help Center 也說明寫入或修改動作會顯示確認。Claude 也可能透過 MCP tools 執行動作。只要會改資料，就要像真正操作系統一樣審查。
Claude 支援 MCP connectors 嗎？
支援，但不同產品表面不一樣。Claude、Claude Desktop、Claude Code 和 Claude API 的設定方式、限制和可用能力不同。實作前要看你使用的是哪個 Claude 入口。
最安全的開始方式是什麼？
先從只能搜尋或讀取的工具開始。確認結果有用、scope 清楚、撤銷方式明確後，再考慮 create 或 update。不要一開始就把高風險 write tools 當成預設。
一句話結論
MCP 連接器把 AI 對話從孤立聊天，往「可以使用已授權脈絡和工具的工作流程」推進一步。它可以幫 ChatGPT、Claude 和其他支援的 AI 用戶端找到你允許的資料或執行你允許的工具。
對 Highlight Reel 使用者來說，最實際的版本很簡單：把值得留下的 AI 對話保存好，等到下一次需要時，再透過支援 MCP 的 AI 用戶端把它們搜尋、取回、重用。