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

SaaS 產品長期以來都有一個老問題：實現價值（time-to-value）太慢。很多使用者在到達「啊哈」時刻之前就流失了。

我們針對 Logto 的導入流程優化過很多次，雖然有幫助，但瓶頸依然存在。最後你還是得看文件、翻教程、裝 SDK、配置設定、寫程式，然後還要除錯最後那 10% 才能跑起來。

因此我們嘗試了新的方式：將遠端 MCP 伺服器作為 Logto 的 IDE 原生控制平面。你不再需要點擊管理後台，而是可以直接在開發應用程式時，透過對話配置 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 伺服器則部署在伺服器，使用者透過網址連線並用 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，導致很多問題：

• API 如果有變動怎麼辦？
• CLI 如果不相容怎麼辦？
• 如何升級、發佈 Skill？

你還得分發 CLI、管理分散的憑證、適配多平台、引導使用者升級，效益嚴重偏低。

MCP 伺服器則簡單很多。使用者只需要連到一個網址，它永遠指向最新版本。我們更新 MCP 伺服器，用戶下次連線就自動拿到更新。完全不用升級。如果 API 改變，我們只要更新 MCP 伺服器內部即可。

多數 SaaS 產品本來就有堅強的基礎設施：API 很穩、認證很完整。MCP 伺服器自然成為 API 的「AI 介面」，就像管理後台是同一組 API 的另一層 UI。

對 Logto 而言，選擇 MCP 伺服器非常貼合我們的架構，也能發揮現有優勢。

同時也能把所有請求集中一個入口。記錄與稽核更容易。許可權很清楚：AI 只能做使用者授權的事。這對企業和合規場景來說，架構上更乾淨。

上線 MCP 伺服器時遇到的問題，以及我們的解法#

MCP 不完美。多數問題其實來自生態尚未成熟，這些都會隨時間改善。短期內，我們用一些權宜之計來滿足真實需求。

MCP 功能支援碎片化#

MCP 規範定義了很多功能，但各 client 支援不同：

• 工具：普遍支援
• OAuth：VS Code 支援良好，像 Cursor 這類工具則需要透過 mcp-remote 當橋樑
• 其它功能（Resources、Prompts、Instructions）：支援不一

目前，工具是最穩定、最共通的層（可參考 MCP 生態頁面 看不同 client 支援哪些功能）。

所以我們的策略很單純：專注在工具上。

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

這是商業層的問題。

以 Agent Skills 來說，商業邏輯和背景知識會一起打包，LLM 就能知道怎麼用。MCP 只提供工具。連結以後，LLM 並不知道：

• 使用情境
• 呼叫順序
• 業務限制

MCP 有 Instructions 這個設計，但不是所有 client 都支援。而且 Instructions 在連線時會把所有內容塞進 context，導致 token 浪費。

另一個辦法是把指引（guidance）寫在工具描述裡。但這有兩個問題：

• 描述變得很複雜，多工具交互會讓邏輯混亂難維護。
• 工具數一多，描述就佔掉大量 context window。

我們的權宜做法：提供 getInstructions 工具

原理很簡單：如果 Instructions 支援度不好，就把它轉成一個工具。

LLM 可以隨時呼叫 getInstructions。
比如遇到任務 A，就呼叫 getTaskAInstructions。MCP 伺服器會回一段提示，教它怎麼完成任務 A、如何組合其它工具。

這樣複雜的商業邏輯藏在 instruction 工具裡，其他工具維持簡單，工具描述只講自己功能。

這有點像 Agent Skills：需要時才把提示載入，比一次塞全域 Instructions 更省 token。

LLM 可能洩漏你的機密資訊#

很多 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 只提供直達後台的連結，讓使用者去完成正式密鑰設定。

我們怎麼設計 MCP 工具#

方法歷程#

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，就是「另一個管理後台」。

MCP 工具設計重點#

規則很顯然：

• 如果你的服務是用戶直接操作（像後台），工具設計偏好業務導向。
• 如果你提供基礎模組給別人組裝，工具就設計成極簡與原子級，例如一個 filesystem MCP server 只要有 read_file、write_file，讓 coding agent 自己組合就好。

補充原則：

• 工具邏輯和描述保持簡單，節省 context。
• 較複雜的工作流程用 getInstructions 這樣的工具，按需載入指引說明。工具描述也同樣要簡潔。

我們對 MCP 未來的期待#

打造 MCP 伺服器期間，我們也在思考生態未來該優化哪些點。

Skill 級能力交付#

有時 MCP 伺服器不僅要提供工具，還得像 Agent Skills 那樣傳遞怎麼組合工具完成任務的指引。

這在 SaaS 很常見，例如 GitHub MCP Server、Logto MCP Server、分析平台。大家要的是一個 workflow，不是原子級呼叫。

getInstructions 是權宜措施。如果協定支援會更好。

Session 級 MCP 啟用#

一個 client 會連很多 MCP 伺服器，但並非每次對話都需要全部，Session 級啟停能大幅減少 context 浪費。

MCP 工具呼叫時的 context 隔離#

工具呼叫會吃掉大量 context。如果 MCP 交互由 sub-agent 處理，主對話只需要收到濃縮結果即可。

總結#

這就是我們開發遠端 MCP 伺服器的實戰心得。

如果你有興趣探索這條路，歡迎直接 試用 Logto MCP Server ，或加入我們的 Discord 跟社群一起交流實戰經驗。

之後我們還會分享架構設計細節、OAuth 流程等內容，敬請期待。