架一台 MCP Server

先把定義釘清楚。MCP 的全名是 Model Context Protocol,模型上下文協定。它是一套標準,規定 Agent 要怎麼去接外面的工具跟資料。而 server,就是把能力擺出來、等著被拿的那一端。順帶講一下它的身世,因為這對企業要不要押注很重要:MCP 是 Anthropic 在二〇二四年十一月提出並開源的,但在二〇二五年十二月,他們把它捐給了 Linux Foundation 底下新成立的基金會,跟另外幾家一起當發起單位。所以它現在不只是「開源」,而是交給中立的組織治理 —— 這才是「不會被某一家收回去」這句話真正站得住的原因。

那 server 具體是什麼角色?它站在工具那一端。你有一個能力 —— 可能是查你們公司的庫存、可能是讀一份內部文件、可能是呼叫一個你們自己寫的服務 —— 你把它包成一個標準的、任何 Agent 照同一套規矩就能呼叫的東西,那個包裝就是 server。補充一點,因為這點會影響你的設計:**這條線其實是雙向的**。server 大多數時候是被呼叫的一方,但它也可以反過來要求使用者補資料 —— 比如少了一個必填的參數、或需要你去瀏覽器完成一次登入授權。它可以請對面去問人,而不是自己硬猜一個值填下去。

一台 server 架好之後,會對外宣告三種東西。第一種是 tools,可以被呼叫的動作 —— 查一筆庫存、送出一張單、算一個數字。第二種是 resources,可以被讀取的資料 —— 一份文件、一張表、一段設定。第三種是 prompts,可以直接套用的提示範本 —— 把「處理這類問題該怎麼問」先寫好,讓使用的人不用自己摸索。這三類是目前的核心。協定本身還在演進,像是「工作要跑很久、不可能當場等結果」這種需求,也已經有專門的機制在標準化了。你先把這三類吃透,後面的擴充都是長在這個骨架上。

架一台 server,五個步驟。第一,決定開放哪些能力。第二,把每一個能力定義成一個清清楚楚的工具。第三,決定這台要怎麼跑:是只跑在自己的機器上給自己用,還是要放到網路上給別人連。第四,把它跑起來。第五,到 Agent 那一端做設定,讓它連上你這台。我要特別把第三步標出來,因為很多教學會把它吞掉 —— 但那一步決定了你後面要做多少工,而且是「會用」跟「會架」之間最真實的一條分界線。

第一步,決定開放哪些能力。這一步是設計題,不是技術題,而且做得好不好差很多。你要先想清楚:你希望 Agent 拿這台 server 做什麼?然後只挑真的需要的開出去,不是把手邊全部功能一次攤開。拿捏在兩邊:開得太少,Agent 幫不上忙,大家用兩次就放棄;開得太雜,你後面每一項都要管權限、管稽核,自己把自己壓垮。我的建議是從「你每天都在手動做、而且做起來很煩」的那幾件開始。

第二步,把每個能力定義成一個工具。三件事,而且第三件最容易出事。第一,取一個一看就懂的名字。因為挑工具的是 Agent 不是人,名字模糊它就挑錯。第二,輸入不是寫一段文字說明就好,而是要定義成一份**機器讀得懂的規格**:哪些欄位、什麼型別、哪些必填。Agent 是照這份規格組參數的,規格越明確,它越不會亂給。第三,這一點是「會用」的人完全不用管、但你要架就一定得管的:**那些參數是 AI 產生的,你要把它當成陌生人從網路上送進來的東西**。該檢查的一樣都不能少。實際掃描過的資料顯示,很多公開的 MCP server 就是栽在這裡 —— 直接把 AI 給的字串接進系統指令或資料庫查詢,結果被人一句話打穿。你寫一般網站後端會做的輸入驗證,在這裡一項都不能省。

第三步,也是我最想強調的一步。概念上,對內跟對外是一樣的 —— 你都是把能力擺出來讓 Agent 來拿。但我要老實跟你講,**工程上這是兩件事**。對內的版本,通常就是一支程式跑在你自己的機器上,由 Agent 那端直接把它叫起來。它跟你是同一個身分、同一份權限,不需要登入,也不需要驗證誰是誰。這種你一個下午可以做出來。對外的版本走的是網路,你等於在對整個網際網路開一個門:誰能進來、他是誰、他手上那張通行證是不是發給你這一台的 —— 全部都要驗。這在規範裡不是建議,是硬性要求。所以我的建議是:**先從對內那一種開始練**,把能力設計清楚;要跨出去對外的時候,你要處理的就不只是 MCP,而是一整套標準的授權機制。那時候請把它當成一個正式的對外服務來做,而不是把本機那台直接搬上去。

第四步跟第五步就相對機械了。第四步,把你定義好的那些工具跑成一台 server。第五步,到 Agent 那一端做設定,告訴它「有這麼一台,連上去」。接下來兩邊就照同一套協定講話,不用你再為每一個 Agent 各寫一套接法 —— 這正是標準真正的價值。

我們走一次完整的來回,你就有畫面了。Agent 連上來的第一件事,是問你這台:你有哪些工具、各是做什麼的?你這台把宣告的那三類東西回給它。接下來 Agent 做事的時候,發現需要你這裡的某個能力,它就從清單裡挑一個、帶上該帶的參數,發出呼叫。你這台實際把事情執行掉,再把結果回傳,Agent 拿到結果接著往下做。這裡有個細節要提醒架 server 的人:在多數 Agent 工具裡,「發出呼叫」跟「真的執行」中間,還有一道給人按確認的關卡。但那道關卡是**使用端的軟體提供的,不是協定規定的** —— 換一個 client 可能就沒有,或者使用者早就嫌煩把它關掉了。所以會造成不可逆後果的動作,你要在自己這台上設防,不能指望對面一定會問人。

那為什麼值得花這個工?因為你把「只有你會、或只有你們公司有」的能力,變成了一個標準能力。包裝之前,誰想用都得為你客製一次;包裝之後,大多數支援 MCP 的 Agent 照同一套方式就能接上來。我不會說「任何 Agent 都能用」—— 各家對 MCP 的支援程度還是有落差,有的吃得比較完整、有的只吃基本款。但比起以前每接一家就要重寫一次,這已經是天差地遠了。

最後給要真的動手的人三個提醒,而且順序有意義。第一,**能只在自己機器上跑的,就不要急著放到網路上**。一放上去,你要處理的東西會多一個量級,而且是資安等級的責任。第二,如果真的要對外,順序不能反:**先把身分驗證做好,再談功能**。現在網路上有非常多 MCP server 是完全沒有身分驗證、直接裸奔的,誰連上去都能用。不要成為其中一台。第三,承接剛剛講的:不要假設對面一定有人會按確認。會造成不可逆後果的動作 —— 刪東西、送出去、付錢 —— 在你自己這台上就要有防線。開放和邊界,是同一個動作的兩面。

如果今天你只帶走一句話:架一台 MCP server,就是把你的能力插上一個標準接頭,讓整個 Agent 世界都用得到。但要記住那條分界線 —— 對內跑一台,是一個下午的事;對外開放一台,那是一個正式的對外服務,身分驗證、輸入檢查、危險動作的防線,一項都不能省。你現在不用馬上動手寫,但要記得有這條路:以後當你想讓 Agent 用你自己的東西、或公司的系統,答案往往就是「幫它架一台 MCP server」。而你可以先從最小的那一步開始:挑一件你每天手動做、做起來很煩的事,在自己的電腦上把它包成一個工具。那台只有你自己用的 server,就是最好的練習。