繁體中文（台灣）
遠端 MCP 伺服器實戰：AI 時代 SaaS 產品的新進入口
了解如何為你的 SaaS 產品打造遠端 MCP 伺服器。我們分享了 MCP 與 Agent Skills 的經驗、OAuth 整合，以及 MCP 工具的設計心得。
Yijun
Developer
Developer
了解如何為你的 SaaS 產品打造遠端 MCP 伺服器。我們分享了 MCP 與 Agent Skills 的經驗、OAuth 整合，以及 MCP 工具的設計心得。
SaaS 產品長期以來都有一個老問題：實現價值（time-to-value）太慢。很多使用者在到達「啊哈」時刻之前就流失了。
我們針對 Logto 的導入流程優化過很多次，雖然有幫助，但瓶頸依然存在。最後你還是得看文件、翻教程、裝 SDK、配置設定、寫程式，然後還要除錯最後那 10% 才能跑起來。
因此我們嘗試了新的方式：將遠端 MCP 伺服器作為 Logto 的 IDE 原生控制平面。你不再需要點擊管理後台，而是可以直接在開發應用程式時，透過對話配置 Logto 並生成整合用程式碼。
一個提示就能帶你從零到完成整合。Agent 不只自動產生程式碼，還會在你的租戶中創建並配置 Logto 應用。全部都在你的 IDE 內完成。（試用 Logto MCP Server）
本文會分享我們打造 Logto MCP 伺服器時的經驗與思考，包括：
在決定 AI 如何存取 Logto 之前，我們評估了兩種選項：MCP 伺服器與 Agent Skills。
MCP 伺服器有兩種形式：本地型與遠端型。
本地 MCP 伺服器運行在使用者機器上。它需要安裝服務、設定環境、輸入憑證或有特殊登入流程。用法與交付都跟 skills 類似。
遠端 MCP 伺服器則部署在伺服器，使用者透過網址連線並用 OAuth 授權。這更接近 SaaS 服務的擴展。
從架構上看，Agent Skill 是「商業邏輯＋底層能力」的組合。這些能力可以是工具、CLI 或 API。MCP 工具則能以統一方式承載這層。
所以核心問題不是能力怎麼實作，而是要怎麼交付給使用者。
Agent Skills 的交付：一整套本地工具鏈（Skill 套件＋本地運行時＋API 密鑰或平台憑證＋CLI 工具＋安裝、設定、升級與維護流程）。
本質上，你把能力交給使用者自己運行。
遠端 MCP 伺服器的交付：一個遠端服務入口（網址＋ OAuth 登入）。
本質上，你把能力作為服務對外提供。
下面我們從使用者體驗、生態覆蓋範圍，以及交付與維護成本三個面向比較兩者。
Agent Skills 通常依賴平台 API 或 CLI。使用者必須先申請 API 金鑰，或安裝、登入 CLI。步驟雖然不複雜，但就是提高了進入門檻。
MCP 伺服器支援 OAuth，使用者只需用 SaaS 帳號登入。體驗類似「以 Google 帳號登入」。
對使用者來說，使用 MCP 伺服器只需：輸入網址、登入、連線。這正是我們想帶給大家的體驗。
在 MCP 官方網站 上，已經有 104 個支援 MCP 的 AI 應用，例如 VS Code、Cursor、Windsurf 等工具。
Agent Skills 目前仍偏向平台專屬。就算很多平台開始支援，一旦我們上線 MCP 伺服器，所有平台的使用者都可以立刻使用；如果是 Skill，只有特定平台的用戶能用。
MCP 也被 Agentic AI Foundation（AAIF） 納入，是協定層級標準。生態會持續成長，對我們而言，MCP 值得長期投入。
Agent Skills 仰賴平台 API 或 CLI，導致很多問題：
你還得分發 CLI、管理分散的憑證、適配多平台、引導使用者升級，效益嚴重偏低。
MCP 伺服器則簡單很多。使用者只需要連到一個網址，它永遠指向最新版本。我們更新 MCP 伺服器，用戶下次連線就自動拿到更新。完全不用升級。如果 API 改變，我們只要更新 MCP 伺服器內部即可。
多數 SaaS 產品本來就有堅強的基礎設施：API 很穩、認證很完整。MCP 伺服器自然成為 API 的「AI 介面」，就像管理後台是同一組 API 的另一層 UI。
對 Logto 而言，選擇 MCP 伺服器非常貼合我們的架構，也能發揮現有優勢。
同時也能把所有請求集中一個入口。記錄與稽核更容易。許可權很清楚：AI 只能做使用者授權的事。這對企業和合規場景來說，架構上更乾淨。
MCP 不完美。多數問題其實來自生態尚未成熟，這些都會隨時間改善。短期內，我們用一些權宜之計來滿足真實需求。
MCP 規範定義了很多功能，但各 client 支援不同：
mcp-remote 當橋樑目前，工具是最穩定、最共通的層（可參考 MCP 生態頁面 看不同 client 支援哪些功能）。
所以我們的策略很單純：專注在工具上。
這是商業層的問題。
以 Agent Skills 來說，商業邏輯和背景知識會一起打包，LLM 就能知道怎麼用。MCP 只提供工具。連結以後，LLM 並不知道：
MCP 有 Instructions 這個設計，但不是所有 client 都支援。而且 Instructions 在連線時會把所有內容塞進 context，導致 token 浪費。
另一個辦法是把指引（guidance）寫在工具描述裡。但這有兩個問題：
我們的權宜做法：提供 getInstructions 工具
原理很簡單：如果 Instructions 支援度不好，就把它轉成一個工具。
LLM 可以隨時呼叫 getInstructions。
比如遇到任務 A，就呼叫 getTaskAInstructions。MCP 伺服器會回一段提示，教它怎麼完成任務 A、如何組合其它工具。
這樣複雜的商業邏輯藏在 instruction 工具裡，其他工具維持簡單，工具描述只講自己功能。
這有點像 Agent Skills：需要時才把提示載入，比一次塞全域 Instructions 更省 token。
很多 SaaS 產品，一些機密資訊如 client 秘鑰、API 密鑰、webhook 簽章金鑰等，絕對不能外洩。一旦洩露，別人就能冒用你或直接存取資源。
風險在於 LLM 對話不是安全通道，訊息可能被記錄、複製、轉貼、進到 debug log。你不能假設「只有我和模型能看見」。給 LLM 長效密鑰、或讓它吐密鑰給使用者複製，都很危險。
這在傳統 Web App 整合很常見：開發者需要密鑰，貼到 server 聲明或 config，然後完成像 SDK 初始化這些步驟。
要讓導入流程簡單但不犧牲安全性，我們採取三個做法：
整合過程只用臨時密鑰
在聊天導入過程中，MCP 伺服器只給短效臨時密鑰（例如 1 小時過期），只要讓整合跑通，通常在上線前就過期了。要用正式長效密鑰，得由開發者在 chat 之外另行建立並替換。
明確劃分安全邊界
明確警告使用者：不要在 chat 內貼、建立、保存正式密鑰。也提醒開發者，就算在環境變數或 config 檔，若 agent / LLM 可透過工具或間接方式讀到，也可能洩露。正式密鑰僅放在沒任何 AI 參與整合的環境裡。
不要在 chat 裡處理正式密鑰，直接引導用戶到後台
長效密鑰完全不會在 chat 產生、傳遞，由 console 憑證頁建立與管理。chat 只提供直達後台的連結，讓使用者去完成正式密鑰設定。
Logto 有完整的管理 API，我們最直覺的想法就是把每個 API endpoint 都包成一個 MCP 工具。
結果失敗了。
首先是 context 爆炸。Logto API 太多，一對一映射會把 context 擠滿，每個工具描述都要佔 token。
其次失去意義。API 是開發者用的積木，但 MCP Server 使用者不是要寫系統，他們只關心任務能不能完成，不在乎有多少 API。
例如 Logto 有個 sign-in-experience API，和品牌、登入方式、註冊方式、資安策略有關。
最初我們還在想怎麼把所有參數 expose 給 LLM，怎麼教它組合呼叫。
但這其實是錯誤的思維。使用者不是要呼叫 API，只是想改品牌、調登入方式。
所以工具應該設計成 updateBranding、updateSignInMethod、updateSignUpMethod，API 組合邏輯內部自動處理即可。
Logto MCP Server 要當產品想，不是 API wrapper，就是「另一個管理後台」。
規則很顯然：
read_file、write_file，讓 coding agent 自己組合就好。補充原則：
getInstructions 這樣的工具，按需載入指引說明。工具描述也同樣要簡潔。打造 MCP 伺服器期間，我們也在思考生態未來該優化哪些點。
有時 MCP 伺服器不僅要提供工具，還得像 Agent Skills 那樣傳遞怎麼組合工具完成任務的指引。
這在 SaaS 很常見，例如 GitHub MCP Server、Logto MCP Server、分析平台。大家要的是一個 workflow，不是原子級呼叫。
getInstructions 是權宜措施。如果協定支援會更好。
一個 client 會連很多 MCP 伺服器，但並非每次對話都需要全部，Session 級啟停能大幅減少 context 浪費。
工具呼叫會吃掉大量 context。如果 MCP 交互由 sub-agent 處理，主對話只需要收到濃縮結果即可。
這就是我們開發遠端 MCP 伺服器的實戰心得。
如果你有興趣探索這條路，歡迎直接 試用 Logto MCP Server ，或加入我們的 Discord 跟社群一起交流實戰經驗。
之後我們還會分享架構設計細節、OAuth 流程等內容，敬請期待。