了解如何為你的 SaaS 產品構建遠端 MCP 伺服器。我們分享了 MCP 與 Agent Skills 的比較、OAuth 整合以及 MCP 工具設計的經驗。
SaaS 產品長久以來都面對一個問題：Time-to-value 太慢，很多用戶在到達 “aha” 時刻之前就流失了。
我們曾多次優化 Logto 的上手流程，雖然有所改善，但瓶頸依然存在。你仍然需要閱讀文件、快速瀏覽教學、安裝 SDK、設定配置、編寫代碼，最後還要除錯那最後 10% 才能運行成功。
所以，我們嘗試了全新做法：將遠端 MCP 伺服器作為 Logto 在 IDE 內建的控制中心。你無需再逐步點擊管理後台，而是在開發 APP 的同時，通過對話方式配置 Logto 並生成整合代碼。
只需一個提示，從零到整合完成全部搞掂。Agent 不僅能生成代碼，還會自動建立並配置你租戶下的 Logto 應用，全部由 IDE 內完成。(試用 Logto MCP Server)
本文會分享我們在打造 Logto MCP 伺服器時的經驗與思考，包括：
在決定 AI 應該如何訪問 Logto 前，我們比較了兩種方案：MCP 伺服器和 Agent Skills。
MCP 伺服器有兩種形式：本地與遠端。
本地 MCP 伺服器運行在用戶本機，需要安裝服務、設定環境、憑證或特殊登入流程。在用法與交付方式上，其實很像 Skills。
遠端 MCP 伺服器則在服務端托管，用戶通過 URL 連接並以 OAuth 授權。這種模式更接近 SaaS 服務擴展。
從架構上看，Agent Skill 是 “商業邏輯 + 底層能力” 的組合。這些能力可用工具、CLI 或 API 封裝。MCP 工具可統一承載這一層。
所以關鍵並不是能力如何實現，而是如何交付給用戶。
Agent Skills 的交付方式：完整本地工具鏈（Skill 套件 + 本地執行環境 + API Key 或平台憑證 + CLI 工具 + 安裝、配置、升級、維護流程）。
實質上，即是將能力提供給用戶自用。
遠端 MCP 伺服器交付方式：遠端服務入口（URL + OAuth 登入）。
實質上，你以服務方式交付能力。
以下從用戶體驗、生態覆蓋，以及交付與維護成本三方面比較：
Agent Skills 普遍依賴平台 API 或 CLI。用戶必須先建立 API Key，或安裝登錄 CLI。這些步驟雖然不算難，但無形中提高了門檻。
MCP 伺服器支持 OAuth，相當於用 SaaS 帳號登錄，體驗類似 “用 Google 登錄”。
對用戶來說，MCP 伺服器體驗極簡：輸入 URL，登錄，連接 — 這就是我們想要帶來的體驗。
在 MCP 官方網站 已有 104 款 AI App 支援 MCP，例如 VS Code、Cursor、Windsurf 等。
Agent Skills 仍屬平台專用，即使越來越多平台支持，但只要我們發布 MCP 伺服器，用戶即可即時試用；Skills 只限該平台能用的用戶。
此外，MCP 亦被 Agentic AI Foundation (AAIF) 納入協議級標準，生態會持續擴展。對我們而言，投資 MCP 是長期合理選擇。
Agent Skills 依賴平台 API 或 CLI，往往出現：
你還需分發 CLI、管理零散憑證、對應多平台，並指導用戶升級，ROI 超低。
MCP 伺服器則簡單得多，用戶只連 URL，永遠指向最新版本。MCP 伺服器更新，用戶下次連接即獲新版，無需升級。如 API 變更，只要伺服器內部更新即可。
大多數 SaaS 已有完善基礎設施：API 穩健，權限/驗證體系成熟。MCP 伺服器天生適合成為 “AI 界面”，就像管理後台是 API 之上的另一個界面一樣。
對 Logto，採用 MCP 伺服器貼合現有架構，發揮我們優勢。
同時，所有請求匯聚於單一入口，日誌、審計操作更易。權限分明：AI 只可做用戶授權之事。此模式對企業和合規場景架構更乾淨。
MCP 不是完美方案，大多問題來自生態成熟度，隨時間會改善。在此之前，我們用一些變通方案以解決實際需求。
MCP 協議規範很多特性，但各客戶端支持情況不一：
mcp-remote 作橋樑目前，Tools 是最可靠的共同層（可參考 MCP Community Page 查看各客戶端支援哪些功能）。
所以我們策略很簡單：專注於工具層設計。
這屬於業務層問題。
用 Agent Skills，業務邏輯與上下文一併封裝，LLM 知道怎麼用。而 MCP 只提供工具，連接後 LLM 不知道：
MCP 有 Instructions 概念，但並非所有客戶端支援且會於連接時一次性塞進上下文，浪費 token。
有一種做法，把引導寫進工具描述，卻會引發兩大問題：
我們的解法：提供 getInstructions 工具
思路很簡單：Instructions 層支援不足，就轉成工具。
LLM 需要時可隨時呼叫 getInstructions。
要處理任務 A 時，呼叫 getTaskAInstructions，MCP Server 給它一個 prompt，詳述如何處理 A 及怎樣組合其它工具。
繁複的業務邏輯藏於指令工具後，其餘工具保持單純。工具描述僅專注自己功能。
這很像 Agent Skills：按需加載指令，比起全局 Instructions 節省 token，更高效。
許多 SaaS 產品有敏感機密（如 client secrets、API key 或 webhook 簽名 key）不容外露，否則他人可冒充身份或直接訪問資源。
用 LLM 風險在於對話不是安全通道，內容易被記錄、複製、轉發、留在 debug log。不能假設「只有我和模型能見」，將長期有效密鑰交給 LLM 或要求其翻出給用戶複製，風險極高。
傳統 web 整合常見把密鑰設進 server 環境變數/配置後初始化 SDK。
我們想讓上手簡單又不降低密鑰安全，做了三件事：
整合期間只用臨時密鑰
聊天式設置中，MCP 伺服器僅發放短時效臨時密鑰（例：有效期 1 小時）。足夠推進整合，實際上 go live 前就過期。正式上線前，開發者需在聊天外另創長期密鑰。
明確劃定安全邊界
清楚提醒用戶：禁止於對話產生/粘貼/儲存正式密鑰。也提示開發者，即使設進環境變量或配置，Agent/LLM 若透過工具能間接獲取，依然可能外洩。請只在無 AI 整合環境下配置正式密鑰。
聊天內不處理正式密鑰，指引用戶到後台操作
長期密鑰絕不通過對話生成或派發，只能通過後台憑證頁建立及管理。聊天流程僅引導/提供直鏈方便用戶完成正式密鑰步驟。
Logto 有完整 Management API。我們最初想法很直接：曝光每一個 API endpoint 成為 MCP 工具。
結果很快失敗。
首先是上下文爆炸。Logto API 很多，一對一映射極易塞爆 context window。每個工具描述都要花費 token。
再來是失去意義。API 對開發者來說是最小組件，但 MCP 的用戶並非在造系統，而是想完成任務，壓根不關心有多少 API。
例如 Logto 有 sign-in-experience API 用於 branding、登入方法、註冊方法、安全策略等。
我們一開始想怎樣把所有參數都曝光給 LLM，去教它組合多次調用。
但這是錯誤思路，用戶要的不是調 API，他們只要能改品牌樣式或設登入方式。
所以工具應設為 updateBranding、updateSignInMethod、updateSignUpMethod，至於組合底層 API 的細節交由 MCP 伺服器內解決。
Logto MCP Server 應該被看做 “另一個管理後台”，而不是 “API 包裝器”。
規律很明顯：
read_file、write_file，所有組合交由代理智能體解決即可。額外原則：
getInstructions 隨需求即時加載指令，其工具描述也務求極簡。在實現 MCP 伺服器時，我們也思考過生態哪些方面可以改進。
有時 MCP 伺服器不只需交付工具，還需交付怎麼組合成任務的指導（如同 Agent Skills）。
這在 SaaS 類特別常見，例如 GitHub MCP Server、Logto MCP Server 或分析平台，用戶想用工作流而非原子操作。
getInstructions 工具是一種變通，更好的方式是協議級原生支援。
客戶端會連接多個 MCP 伺服器，但每個對話會話並非全用，能夠針對會話啟用/停用可減少 context 損耗。
工具調用會消耗大量上下文資源。若 MCP 交互能以子代理分憂，主線對話只需收取精煉結果即可。
這就是我們實踐遠端 MCP 伺服器的經驗。
如果你也在探索這條路，歡迎 試用 Logto MCP Server 或加入我們的 Discord，與社群一起交流真實落地經驗。
我們日後會陸續分享架構設計、OAuth 流程等專題細節，敬請關注。