工具怎麼接進 agent，MCP 定了格式，沒有定誰來實作那個 server。實際要接的時候會發現這件事有三條路：自己寫一個、用服務商託管的、把開源的實作架在自己機器上。今天把三條路的成本攤開來比，比的項目是資格門檻、維運責任，以及授權那一段的程式碼落在誰手上。

官方託管：端點現成，資格要申請

Google 這一側的 Workspace MCP 是八個遠端端點，一個產品一個：

八個全部處在 Developer Preview，設定頁列的必要條件第一項是取得 Google Workspace Developer Preview Program 的資格，另外要有一個啟用了對應 API 與 MCP 服務的 Google Cloud 專案，以及為客戶端建立的 OAuth 2.0 憑證。

資格這一項的性質與其他兩項不同：

• Cloud 專案與 OAuth 憑證：自己按幾個鍵就完成，時間可控
• Developer Preview Program：線上申請後等審核，通過與否由對方決定

Workspace MCP 只是其中一塊。Cloud Next '26 上公布的 Google 託管 MCP 總數，官方部落格寫的是：

在 Google Cloud Next '26，我們宣布超過 50 個 Google 託管的 Model Context Protocol（MCP）server 已正式推出或進入預覽，還有更多正在路上

「已正式推出或進入預覽」是把兩種成熟度合併計數的寫法，這個數字回答的是涵蓋面，不回答其中任何一個現在能不能用。要接的那一個屬於哪一類，得逐一去查它自己的文件。

審核過的目錄：一行指令裝好，清單由別人決定

Hermes 這一側有一份 Nous 審核過的目錄，hermes mcp catalog 列出來是 65 個項目，hermes mcp install <名稱> 一行裝好。裡面涵蓋的服務橫跨幾類：

• 開發與維運：GitLab、CircleCI、Buildkite、Sentry、Datadog、Grafana、Vercel、Netlify、Railway
• 資料庫與資料：Supabase、Neon、Prisma Postgres、MotherDuck
• 文件與知識庫：Notion、Context7、DeepWiki、Microsoft Learn、AWS Knowledge
• 商務系統：Stripe、Square、PayPal、Plaid、Attio、Close、Intercom
• 專案管理：Linear、Asana、ClickUp、monday.com、Todoist

65 個裡面沒有 Google Workspace。目錄的價值在於那份清單本身經過審核，代價是清單的範圍不在自己手上，要接的服務沒被收錄時這條路就走不通。

自己填 URL：先連上去看有什麼工具

目錄外的 server 走 hermes mcp add，它的參數把兩種傳輸方式分開：

指令的說明文字把自己定位成 discovery-first install，實際執行時它先連上去、把探索到的工具列出來、問要不要全部啟用，確認之後才寫進 config.yaml。寫進組態的是連線成功之後的結果，而非一組還沒驗證過的設定值。

三條路各自把成本放在哪裡

開源自架這一欄以 taylorwilsdon/google_workspace_mcp 為例，MIT 授權，README 寫明支援所有免費 Google 帳號與 Workspace 方案，執行時的旗標包含 --transport、--tools、--tool-tier、--read-only、--permissions 與 --disabled-tools。

最後一列是決定性的那一項。封裝對象在內網時，託管端點連不到那台機器，選擇範圍直接收斂成自建或自架兩條。

三條路的分野在責任落在哪一層

心得

這三條路我原本以為是照難易度排的，自建最難、託管最省事。實際跑過一次申請流程之後才發現排序的依據是別的東西。

官方託管那條路卡住的地方不在技術。文件讀完、Cloud 專案建好、OAuth 憑證也拿到了，剩下的那一項是等一封通知信。這件事寫在需求清單的第一行，跟其他幾項並列，讀的時候不覺得它特別，做到那裡才知道只有它不在自己手上。

那次之後選型的第一個問題就換了，不再先問哪個做起來快，改成先問哪一項的前提是別人決定的。

取得成本裡最貴的那一項，是決定權在別人手上的那一項

明天

把一組既有的 REST API 包成 MCP server，工具邊界、參數驗證與確認閘門各自寫在哪一層。