MCP是什麼？為什麼幾乎所有AI工具突然都在使用它？

在過去這十年裡，把AI模型連接到公司的工具，大多數時候都意味著每一對工具都要打造一套客製化整合。Anthropic在2024年11月推出的開放標準Model Context Protocol，用一個到處都能插上的接頭取代了這種做法——此後OpenAI、Google和Microsoft也都採用了它。以下說明它實際上是如何運作的，以及在把它連接到你團隊的資料之前，一份真正實用的檢查清單。

打開Claude的桌面應用程式，請它檢查你團隊目前開放中的pull request，它就能直接做到。這不是因為Anthropic在Claude裡內建了GitHub整合。而是因為在某個地方——你的IT團隊、某家供應商、GitHub上的某位開發者——有人寫了一個會說一種叫做MCP的協定的小程式，而Claude已經知道如何與任何說這種協定的東西對話。現在ChatGPT、Google的Gemini以及Microsoft Copilot也都是如此。這種匯流，比任何單一功能發布都更能說明，為什麼MCP在過去一年裡幾乎成了每家AI供應商都投入心力去支援的東西。

MCP到底是什麼

MCP是Model Context Protocol的縮寫。它由Anthropic設計，並於2024年11月25日連同最早的SDK一起開源了規格。Anthropic自己的發布資料用了一個讓人印象深刻的類比來形容這個概念：把MCP想成AI應用程式的USB-C埠——一種統一的實體接頭標準，而不是每個配件都要用不同的連接線。發布時，Anthropic列出了已經在自家產品裡打造MCP支援的早期採用者，包括企業軟體公司Block和Apollo，以及開發工具製造商Zed、Replit、Codeium和Sourcegraph。Claude的桌面應用程式在同一天上線，就具備了在使用者自己的機器上本機執行MCP伺服器的能力。

MCP解決的問題：N個工具乘以M個資料來源

MCP所解決的問題，工程師習慣用一個名稱來稱呼：N乘M整合問題。假設一家公司使用五種需要存取公司資料的AI工具——Claude、ChatGPT、GitHub Copilot、Cursor，以及一個內部客服機器人——而這些資料分散在八個地方：Slack、GitHub、一個Postgres資料庫、Salesforce、Notion、Google Drive、Jira，以及一個內部API。若沒有共用的協定，要把每個工具都以有用的方式連接到每個資料來源，最多需要四十個各自獨立的整合——五乘八——每一個都有自己的驗證機制、自己的錯誤處理方式，而且每當其中一個API的結構改變，就要付出一次維護成本。再加入第六種AI工具，這個數字就跳到四十八。實際上，沒有人會把這四十個全部做出來。每家AI供應商只做了它認為值得投入工程時間的那一小部分，其餘的都仍靠人工：複製、貼上、重新說明一次，然後重複。

MCP把乘法變成了加法。一家想讓Claude讀取自家Postgres資料庫的公司，不需要打造一個專屬於Claude的Postgres連接器。它只需要建置——或是重複使用別人已經發布過的——一個能公開Postgres的MCP伺服器，而這個伺服器就能配合Claude、ChatGPT、Gemini，或任何其他相容MCP的代理運作，不需要再寫額外的程式碼。Anthropic自己在發布時列出的清單，就包含了針對Google Drive、Slack、GitHub、Git、Postgres，以及一個叫Puppeteer的瀏覽器自動化工具所預先建置的伺服器。重點從來不是Anthropic要把這些全部做出來，而是任何人都能做，而如今可用伺服器的目錄，早已遠遠超出任何一家公司能自行維護的規模。

這個協定實際上是如何運作的

拿掉包裝之後，MCP其實是一個相當平實的用戶端-伺服器協定，設計上刻意做得不花俏。它定義了三種角色。Host是使用者實際打開的應用程式——Claude Desktop、像Cursor這樣的IDE、ChatGPT應用程式。Host內嵌了一個MCP Client，它會對MCP Server開啟一個直接、具狀態的連線——MCP Server是一個公開某個特定系統的小程式：一個資料庫、一個工單工具、一個檔案系統、一個內部API。用戶端與伺服器之間交換的訊息採用JSON-RPC 2.0格式——一種已經廣泛應用在現有基礎設施中的輕量級遠端程序呼叫格式——透過兩種傳輸方式之一：當伺服器是在同一台機器上本機執行的程式時使用stdio；當它是在別處執行的託管服務時，則使用Streamable HTTP。

一個伺服器能公開的內容，歸結起來是三種基本元件。Tools是模型可以呼叫來執行動作的函式——例如create_task、run_query、send_message——模型會根據對話內容自行判斷何時呼叫。Resources是唯讀的內容，Host可以主動取得並交給模型，而不需要模型開口要求——例如一個檔案的內容、一個資料庫結構描述、一張工單。Prompts是可重複使用、由使用者觸發的範本——例如一個現成的「總結這個討論串」或「草擬一份狀態更新」，需要由使用者明確叫用，而不是模型自己決定要不要做。一個建置完善的伺服器，會清楚說明自己針對某項能力提供的究竟是這三者中的哪一種，因為這個區分正是決定一個已連接的AI工具能不能單純查看某項東西，或是能不能去改動它的關鍵。

還有誰採用了它，以及何時採用

MCP最初幾個月只是Anthropic自己的專案。這個情況很快就改變了，而且改變的方式在AI領域裡確實相當罕見：直接競爭對手不約而同地採用了同一家公司的協定，而不是各自打造自己的版本。OpenAI在2025年3月為其Agents SDK加入了MCP支援，讓開發者可以把代理工作流程連接到任何MCP伺服器，而不需要打造專屬於OpenAI的客製化工具整合。次月，Google DeepMind證實Gemini以及自家的代理開發套件也將支援MCP——Google同時搭配推出了自己互補的協定Agent2Agent，目的是讓獨立的代理彼此協調，而不是與工具協調。到2025年5月，Microsoft已經透過所謂的Windows AI Foundry，把原生MCP支援帶進了Windows 11，支援也一併進入GitHub Copilot與Copilot Studio。

這四家公司在模型架構、定價或平台策略上幾乎沒有共識。但如今這四家都推出了使用同一種協定，來把代理連接到工具的產品。在這個產業裡，這種情況已經算是相當罕見，本身就足以成為這個故事的重點——比MCP能實現的任何單一功能都更值得關注。

為什麼這是信任問題，而不只是管線工程

這種匯流確實很有用，但也正是MCP值得被仔細審視、而不是被盲目信任的原因。一個能讓代理輕輕鬆鬆連上你公司系統的協定，同樣也是一個能讓一個做得糟糕或設定不當的連線，輕輕鬆鬆碰到那些相同系統的協定。MCP本身並不會阻止這種情況發生。這份規格定義的是用戶端與伺服器之間如何對話——它完全沒有規定誰有權授予一個連線、那個連線被允許碰觸什麼，或者如果出了問題會不會有人發現。這些選擇完全取決於眼前這個特定伺服器或用戶端是由誰打造或設定的。有些供應商會把這一切都做得很仔細。有些則完全沒做，而協定並不會阻止他們這麼做。

連接之前的檢查清單

在你的團隊連接一個MCP伺服器之前——無論它是某家供應商的產品、有人在GitHub上找到的開源工具，還是內部自行打造的東西——有六個問題能夠區分出一個受到治理的連線，和一道完全敞開的門。這些問題都不需要去讀規格文件。它們只需要有人在點下「核准」之前先問一問，並真正讀懂連線畫面給出的答案。

一個建置完善的連線實際上是什麼樣子

FabricLoop自己的MCP設定，就是對這份檢查清單的一個具體回答——不是因為它有多特別，而是因為每一個環節都直接對應到上面六個問題中的一個，而且值得說明的是實際的運作機制，而不是行銷版本的說法。FabricLoop同時扮演這兩種角色：它是一個MCP伺服器，讓外部工具連進來，所以Cursor、Claude或ChatGPT可以用某個特定使用者自己在FabricLoop裡的權限，來建立任務、新增留言或讀取筆記——它同時也是一個向外連接的MCP用戶端，讓一個頻道可以把某家供應商的MCP應用程式（例如GitHub或Linear）拉進來，並像對待一個團隊成員那樣@提及它。

以上這些都不是什麼特殊的工程技術。它是一系列刻意做得不花俏、卻持續被貫徹執行的決定：限定範圍、綁定到個人、記錄下來、讓它能在不造成連帶損害的情況下被撤銷。這正是本站在更廣泛的可判讀性（Legibility）概念上一直強調的論點——你能夠具名、記錄並撤銷的存取權，勝過沒人需要去想的存取權——而MCP只有在有人真的這麼去打造它的時候，才會帶來這樣的結果。這個協定讓底層管線變成標準做法，但它並不會讓治理自動發生。

真正重要的決定

MCP不會消失，此時反對它多少有點像反對USB。現在每一家主要的模型供應商都提供了它，可用伺服器的清單持續增加，而對大多數實際工作而言，一個連不到你工具的代理，就是一個做不了太多事的代理。真正有意思的決定，並不在於是否要讓一個AI工具連上你的系統——愈來愈多時候，這個決定的某個版本早已在你不知情的狀況下，一次一個整合地被做出來了，因為你團隊已經在用的工具，正悄悄在你沒細讀條款就點進去的某個功能底下，加入了MCP支援。真正還掌握在你手上的決定，是你在點下「核准」之前，究竟檢查了什麼。