遠端 MCP 伺服器實戰：AI 時代 SaaS 產品新入口

SaaS 產品長久以來都面對一個問題：Time-to-value 太慢，很多用戶在到達 “aha” 時刻之前就流失了。

我們曾多次優化 Logto 的上手流程，雖然有所改善，但瓶頸依然存在。你仍然需要閱讀文件、快速瀏覽教學、安裝 SDK、設定配置、編寫代碼，最後還要除錯那最後 10% 才能運行成功。

所以，我們嘗試了全新做法：將遠端 MCP 伺服器作為 Logto 在 IDE 內建的控制中心。你無需再逐步點擊管理後台，而是在開發 APP 的同時，通過對話方式配置 Logto 並生成整合代碼。

只需一個提示，從零到整合完成全部搞掂。Agent 不僅能生成代碼，還會自動建立並配置你租戶下的 Logto 應用，全部由 IDE 內完成。(試用 Logto MCP Server)

本文會分享我們在打造 Logto MCP 伺服器時的經驗與思考，包括：

• MCP 與 Agent Skills：我們為何選擇 MCP
• 發布 MCP 伺服器時遇到的問題及解決方法
• MCP 工具設計思路，及如何設計屬於你的工具
• 我們對 MCP 未來的期望

MCP 與 Agent Skills：我們為何選擇 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，往往出現：

• API 變動怎麼辦？
• CLI 不兼容又如何？
• 如何升級、重新分發 Skill？

你還需分發 CLI、管理零散憑證、對應多平台，並指導用戶升級，ROI 超低。

MCP 伺服器則簡單得多，用戶只連 URL，永遠指向最新版本。MCP 伺服器更新，用戶下次連接即獲新版，無需升級。如 API 變更，只要伺服器內部更新即可。

大多數 SaaS 已有完善基礎設施：API 穩健，權限/驗證體系成熟。MCP 伺服器天生適合成為 “AI 界面”，就像管理後台是 API 之上的另一個界面一樣。

對 Logto，採用 MCP 伺服器貼合現有架構，發揮我們優勢。

同時，所有請求匯聚於單一入口，日誌、審計操作更易。權限分明：AI 只可做用戶授權之事。此模式對企業和合規場景架構更乾淨。

發布 MCP 伺服器時遇到的問題與解法#

MCP 不是完美方案，大多問題來自生態成熟度，隨時間會改善。在此之前，我們用一些變通方案以解決實際需求。

MCP 特性支援分散#

MCP 協議規範很多特性，但各客戶端支持情況不一：

• Tools：廣泛支援
• OAuth：VS Code 支援良好，Cursor 等工具需用 mcp-remote 作橋樑
• 其他功能（Resources、Prompts、Instructions）：支持情況不穩定

目前，Tools 是最可靠的共同層（可參考 MCP Community Page 查看各客戶端支援哪些功能）。

所以我們策略很簡單：專注於工具層設計。

LLM 不知如何使用你的工具#

這屬於業務層問題。

用 Agent Skills，業務邏輯與上下文一併封裝，LLM 知道怎麼用。而 MCP 只提供工具，連接後 LLM 不知道：

• 什麼情境可用
• 調用先後順序
• 有哪些業務限制

MCP 有 Instructions 概念，但並非所有客戶端支援且會於連接時一次性塞進上下文，浪費 token。

有一種做法，把引導寫進工具描述，卻會引發兩大問題：

• 描述變得複雜，有多工具組合時邏輯易纏繞，也難維護。
• 隨工具增多，大量 token 浪費於描述文字。

我們的解法：提供 getInstructions 工具

思路很簡單：Instructions 層支援不足，就轉成工具。

LLM 需要時可隨時呼叫 getInstructions。
要處理任務 A 時，呼叫 getTaskAInstructions，MCP Server 給它一個 prompt，詳述如何處理 A 及怎樣組合其它工具。

繁複的業務邏輯藏於指令工具後，其餘工具保持單純。工具描述僅專注自己功能。

這很像 Agent Skills：按需加載指令，比起全局 Instructions 節省 token，更高效。

LLM 可能洩露你的機密#

許多 SaaS 產品有敏感機密（如 client secrets、API key 或 webhook 簽名 key）不容外露，否則他人可冒充身份或直接訪問資源。

用 LLM 風險在於對話不是安全通道，內容易被記錄、複製、轉發、留在 debug log。不能假設「只有我和模型能見」，將長期有效密鑰交給 LLM 或要求其翻出給用戶複製，風險極高。

傳統 web 整合常見把密鑰設進 server 環境變數/配置後初始化 SDK。

我們想讓上手簡單又不降低密鑰安全，做了三件事：

• 整合期間只用臨時密鑰

  聊天式設置中，MCP 伺服器僅發放短時效臨時密鑰（例：有效期 1 小時）。足夠推進整合，實際上 go live 前就過期。正式上線前，開發者需在聊天外另創長期密鑰。

• 明確劃定安全邊界

  清楚提醒用戶：禁止於對話產生/粘貼/儲存正式密鑰。也提示開發者，即使設進環境變量或配置，Agent/LLM 若透過工具能間接獲取，依然可能外洩。請只在無 AI 整合環境下配置正式密鑰。

• 聊天內不處理正式密鑰，指引用戶到後台操作

  長期密鑰絕不通過對話生成或派發，只能通過後台憑證頁建立及管理。聊天流程僅引導/提供直鏈方便用戶完成正式密鑰步驟。

我們如何設計 MCP 工具#

我們的路徑#

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 包裝器”。

MCP 工具設計心得#

規律很明顯：

• 如果用戶像用後台一樣直接用你的服務，工具就必須以業務為導向設計。
• 如果你只提供底層能力給他人組合，工具保持簡單原子化。比如 filesystem MCP server 只需 read_file、write_file，所有組合交由代理智能體解決即可。

額外原則：

• 保持工具邏輯和描述簡單，節省上下文；
• 複雜工作流程用 getInstructions 隨需求即時加載指令，其工具描述也務求極簡。

我們對 MCP 未來的期望#

在實現 MCP 伺服器時，我們也思考過生態哪些方面可以改進。

提升 Skill 級能力交付#

有時 MCP 伺服器不只需交付工具，還需交付怎麼組合成任務的指導（如同 Agent Skills）。

這在 SaaS 類特別常見，例如 GitHub MCP Server、Logto MCP Server 或分析平台，用戶想用工作流而非原子操作。

getInstructions 工具是一種變通，更好的方式是協議級原生支援。

支援會話級 MCP 使能#

客戶端會連接多個 MCP 伺服器，但每個對話會話並非全用，能夠針對會話啟用/停用可減少 context 損耗。

MCP 工具調用 context 隔離#

工具調用會消耗大量上下文資源。若 MCP 交互能以子代理分憂，主線對話只需收取精煉結果即可。

結語#

這就是我們實踐遠端 MCP 伺服器的經驗。

如果你也在探索這條路，歡迎 試用 Logto MCP Server 或加入我們的 Discord，與社群一起交流真實落地經驗。

我們日後會陸續分享架構設計、OAuth 流程等專題細節，敬請關注。