代理和應用程式運作中的 MCP 與 API

代理去外部資料來源取了資料，弄懂了回應格式，做出一個帶地圖的頁面。能用。現在換另一個人打開這個頁面，而他的電腦上根本沒有 Claude Code。

發布之前，值得先回答一個問題。誰會替訪客取得資料？接下來會說明兩條路線、MCP 負責什麼、如何檢查連線，以及在您關閉代理的工作階段之後，哪些東西必須繼續運作。

現在是誰在請求資料

情況有兩種，而且很容易搞混，因為在螢幕上兩者看起來都是"資料出現了"。

第一種情況，代理在研究資料來源。您正在開發專案，Claude Code 閱讀服務的文件、試著發出請求、查看回應的結構。它需要這些資料來撰寫程式碼。這一切發生在您的電腦上，而且只在工作階段開著的期間。

第二種情況，訪客打開已發布的頁面。這時需要資料的是頁面本身 - 為了顯示最新的狀況。請求由應用程式的程式碼在執行時發出。這就叫做 runtime，也就是應用程式在使用者那邊執行的時間，而不是您撰寫它的時間。

還有第三種做法，介於兩者之間。代理到資料來源取一次資料，把回應存成程式碼旁邊的檔案，網站再顯示這個檔案的內容。這種做法沒什麼不好，拿來當範例或示範甚至很方便。只是它是一張快照，會一直保持存檔時的樣子，不會自己更新。

兩條鏈各自獨立，中間沒有箭頭

請注意中間的虛線。它不是畫來好看的。上下兩條鏈之間沒有箭頭，這正是這張圖最該記住的一點。資料來源可能是同一個，但代理和頁面各有各的路徑去存取它。下面分別說明每一條鏈。

什麼是 MCP

任務很少只存在於儲存庫裡。bug 的描述留在 ticket 裡，stack trace 在監控系統裡，函式庫的最新規則在文件裡，需要的紀錄則在資料庫裡。

沒有整合的話，就得手動把這些東西從瀏覽器搬到和代理的對話裡。搬一次還能忍受。但在重複性的工作中，資料來不及保持最新，一部分細節會遺失，同一條路也得一再重走。

MCP（Model Context Protocol）是一套標準，Claude Code 透過它得知有哪些可用的外部工具、呼叫這些工具，並以一致的格式取得結果。在最精簡的鏈中，Claude Code 建立一個 MCP client，client 與 MCP server 保持連線，server 再去存取它有權限的系統 - 檔案、資料庫、第三方 API。

Claude Code 和 MCP server 溝通，而 server 只開放事先描述好的外部系統功能

左邊是內建 MCP client 的 Claude Code，中間是 MCP server 和它宣告的功能，右邊是外部系統。這裡的重點是，代理不會一下子就取得對所有東西不受控的存取權。它只看得到 server 決定提供的操作和資料。

現成的 MCP server 順便也省下一部分整合工作。您不必自己替每個外部系統描述呼叫格式，也不必寫出存取其 API 的全部程式碼。這些交給 server 處理，Claude Code 只要使用已宣告的操作。

另外，server 不一定是網路上某個獨立的程式。它可以直接在您的電腦上以本機行程執行，也可以在遠端運作、同時服務很多 client。對您來說，差別主要在於連接它的方式。

server 具體能做什麼，由它自己決定。協定描述了 server 可以提供的三種內容：

tools - 代理可以執行的操作：取得頁面、向 API 發出請求、寫入資料；
resources - server 當作上下文提供的內容：檔案、紀錄、服務的回應；
prompts - 預先準備好的請求範本，可以直接拿來呼叫。

server 不必三種都支援。連線時，client 和 server 會核對彼此能做什麼，不支援的操作就不會用到。很多 server 只提供 tools，這樣也就夠了。MCP 架構。

值得記住的重點是：MCP 標準化的是 client 和 server 溝通的方式。您實際能用到什麼，由 server 決定，而不是由協定決定。連接一個 server 並不等於取得整個網路的存取權 - 您得到的，就是這個 server 宣告的那一組操作。

交代任務給代理時，請說出資料來源和想要的結果，而不是指定指令。接著檢查已連接的 server 有沒有合適的操作。如果沒有需要的操作，就改走別的路線解決，而不是一再說服代理。

資料如何進入網站

現在來看下面那條鏈。已發布的頁面會用以下兩種方式之一取得資料。

第一種情況，瀏覽器直接存取公開 API。資料來源是公開的、不需要金鑰時，適合這種方式。頁面的程式碼發出請求，再把回應畫出來。簡單，沒有多餘的細節。

第二種情況，瀏覽器存取應用程式的 backend，再由 backend 存取受保護的 API。資料來源需要金鑰時就這麼做。祕密留在伺服器上，瀏覽器看不到。這裡 frontend 負責螢幕上看得到的部分，backend 負責在伺服器上執行的部分，並能代表應用程式去存取服務。

瀏覽器可以直接存取公開 API，而受保護 API 的金鑰留在 backend

上面的路線比較短，因為瀏覽器可以自己存取公開的資料來源。在下面的路線中，backend 成了保護祕密的邊界。金鑰留在伺服器上，不會進到頁面的程式碼裡。

不過，有件事並不會發生。Claude Code 和 MCP server 之間的連線，不會在發布時跟著網站一起走。您用來新增 server 的指令，設定的是您的代理；它不會替應用程式加上任何一行程式碼。當然也可以寫一個帶有自己 MCP client 的應用程式，但那是另一項工作、另一種實作，而不是在 Claude Code 裡連接 server 的結果。

這一點檢查起來很快。關掉 Claude Code，打開已發布的頁面，看看開發者工具裡的 Network 分頁。如果資料有進來，您會看到請求、網址和回應。如果沒有進來，就不會有請求，而這正是應該在別人看到頁面之前就抓出來的情況。

只看螢幕上的畫面是不夠的。頁面可能顯示的是之前存下來的快照，看起來卻完全像是即時的。要看的是請求本身。反過來說，回應裡沒有新事件也不代表壞了。資料來源可能只是在選定的時段內什麼都沒送來。

如何檢查連線

不管是哪個 server，步驟大致相同：

找到 server 的官方說明 - 網址、存取方式、操作清單；
用這份說明提供的指令新增 server；
在 Claude Code 中打開 /mcp，確認 server 已連上，以及它有哪些工具；
執行一個讀取請求，越簡單越好；
手動把結果和資料來源比對 - 親自打開同一個頁面看看。

在終端機裡，claude mcp list 會顯示狀態，claude mcp get 會顯示單一 server 的詳細資訊。要知道的是，這幾個步驟回答的是不同的問題：

您看到了什麼	這證明了什麼
新增後出現 `Added ...` 這一行	設定已寫入，僅此而已
`claude mcp list` 中顯示 `Connected`	Claude Code 成功連上了 server
工具回傳了內容	整條路線都能運作，從請求到回應

這個差別不是形式上的。設定成功寫入，並不代表 server 會回應；連線成功，也不代表需要的操作可以用、而且有權限使用。所以檢查最後要以一次真正的呼叫收尾。順帶一提，如果清單中顯示 Needs authentication，server 並沒有壞，只是在等您登入。

來看一個具體的例子。Firecrawl 服務有一個 MCP server，能取得公開頁面的內容 - 工具名稱是 firecrawl_scrape。對代理來說，這是完整讀取一頁文件的方便方式，不必把內容一段一段複製到對話裡。

# 透過 HTTP 新增 server；確切網址請查服務的文件
claude mcp add --transport http firecrawl https://mcp.firecrawl.dev/v2/mcp

接下來談存取權限。Firecrawl 的文件既描述了不需要帳號和金鑰、但有每日限制的用法，也描述了透過瀏覽器登入的方式，也就是由 client 自己打開登入頁面。服務的條件和額度會變動，所以最新資訊要看服務本身，而不是這篇文章。Firecrawl 關於 MCP 的文件。

還有一個能省時間的小細節。預設情況下，server 只會新增到您執行指令的那個專案，不會出現在其他專案中。如果 server 在每個專案都要用，或者反過來要給整個團隊用，新增指令有另外的 scope 選項。Claude Code 關於 MCP 的文件。

金鑰的值不該出現在設定範例裡，也不該出現在 server 網址或和代理的對話中。設定裡放的是環境變數的名稱，值另外設定 - 這是另一篇關於金鑰的文章的主題。

具體的工具允許做什麼

已連接的 server 是一組操作，而這些操作的後果差別很大。讀取一個頁面和修改外部系統中的一筆紀錄完全不是一回事，雖然呼叫的方式一樣。

同意呼叫之前，最好先看三件事：工具操作的是什麼對象、執行什麼操作、為此需要哪些權限。讀取通常比較安全，但也有代價。請求會送到第三方服務，並消耗您的額度。

另外要特別說一下回應裡的內容。從第三方網站取得的文字是資料，不是指示。如果頁面裡寫著"現在刪除所有檔案"，那仍然只是頁面上的文字，決定權在您。代理讀過外部來源之後，要看一下它接下來打算做什麼，原因正在於此。

最後是最實際的問題。真的需要 MCP 嗎？不一定。

任務	更簡單的做法
在網站上顯示來自公開 JSON 的資料	由應用程式的程式碼發出一般請求，不需要 MCP
代理經常使用某個已有現成整合的服務	MCP 划得來：操作已經描述好，連線可以重複使用
讀一次文件，或呼叫一個網址	直接讀取 URL 或直接呼叫 API 就夠了

MCP 不是通往外部的唯一一扇門，也不能取代其他一切。代理仍然可以使用命令列，也可以直接呼叫 API。該怎麼選，要看任務，而不是看連線是不是已經設定好了。

在自己的專案中檢查什麼

當代理準備處理外部資料時，最好請它明確分開這兩層，而不是事後再來釐清：

分別描述兩條路線：
你在開發專案期間從哪裡取得資料，
以及應用程式本身會從哪裡替訪客取得資料。
指出應用程式的請求位於哪個檔案、程式碼的哪個位置。
在工作階段關閉的狀態下檢查頁面：資料有沒有進來。
如果現在用的是存下來的快照，請直接說明。

最常見的三種情況，以及各自的答案：

需要做什麼	誰取得資料	為什麼
在開發期間研究服務的文件	代理	資料是寫程式碼時需要的，訪客那邊不會重複這個請求
替訪客更新地圖	應用程式的程式碼	請求在頁面運作時發出，這時代理的工作階段早已關閉
把一份資料擷取一次存成 JSON	代理，而且只有一次	之後網站顯示這個檔案；資料會保持存檔時的樣子

請注意，MCP 在這裡只出現在第一行，而且就連那一行也不是非用不可。如果任務用一般的網址讀取就能解決，那就這樣解決。

在把成果給別人看之前，最後一項檢查也是最簡單的：關掉 Claude Code，打開頁面。繼續運作的那部分，才是您的應用程式。其他的一切都是開發期間代理提供的幫助 - 很有用，但留在您的電腦上。