简体中文
远程 MCP 服务器实战：AI 时代下 SaaS 产品的新入口
学习如何为你的 SaaS 产品构建远程 MCP 服务器。我们分享了关于 MCP 与 Agent Skills 的对比、OAuth 集成以及 MCP 工具设计的经验。
Yijun
Developer
Developer
学习如何为你的 SaaS 产品构建远程 MCP 服务器。我们分享了关于 MCP 与 Agent Skills 的对比、OAuth 集成以及 MCP 工具设计的经验。
SaaS 产品一直存在一个老问题：实现价值的时间太慢。很多用户还没到“aha”时刻就流失了。
我们在 Logto 的上手流程上做了很多次迭代。这是有帮助的，但瓶颈并没有完全消失。你还是需要去看文档、扫教程、装 SDK、配置参数、写代码，然后在最后 10% 调试通了才能跑起来。
于是我们尝试了另一种思路：把远程 MCP 服务器作为 Logto 的 IDE 内控制平面。客户不再需要点来点去地操作管理后台，而是直接在开发应用的 IDE 接口，通过对话配置 Logto 并生成集成代码。
只需一个提问就能让你从零到集成上线。Agent 不仅会生成代码，还会在你的租户中同步创建并配置 Logto 应用，全程都在 IDE 内完成。(试用 Logto MCP 服务器)
这篇文章会分享我们在构建 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 个支持 MCP 的 AI 应用，包括 VS Code、Cursor、Windsurf 等工具。
Agent Skills 仍是平台特定的，即使很多平台都支持了 Skills，但当我们上线 MCP 服务器时，所有支持 MCP 的应用用户都能马上用；而如果上线 Skill，只有在对应平台的用户能用。
此外，MCP 还是 Agentic AI Foundation (AAIF) 的协议级标准，生态会继续壮大。对我们来说，MCP 值得长期投入。
Agent Skills 依赖平台 API 或 CLI，很快会碰到这些问题：
你还需发放 CLI、管理分散的凭据、适配多平台、指导用户升级。ROI 很低。
MCP 服务器要简单很多，用户只需连 URL，总是最新版本。我们升级 MCP 服务器，用户下次连就自动获得新版，无需额外升级。如果 API 变了，只需在 MCP 服务器里动手就行。
大多数 SaaS 产品本身就有扎实的基础设施（完善的 API 和成熟的认证体系）。MCP 服务器完全可以作为 API 的“AI 接口”，就像后台控制台是另一个接口一样。
对 Logto 而言，选择 MCP 服务器既契合架构，也能发挥我们已有的能力。
这还能把所有请求集中在一个入口上，日志与审计更统一，权限也很清晰：AI 只能做用户授权的事。这种模式结构上更适合企业和合规应用场景。
MCP 还不完美。多数问题是生态成熟度引起的，随着时间会改善。在此之前，我们用各种折衷方案解决实际需求。
MCP 规范定义了很多能力，但客户端支持各异：
mcp-remote 作为桥接目前来看，Tools 是最可靠的公有层（可在 MCP 社区页面 查各客户端都支持哪些能力）。
所以我们的策略就是：基于 Tools 构建。
这是业务层面的问题。
Agent Skills 会把业务逻辑和上下文绑定在一块，LLM 本身就会如何用。而 MCP 只是暴露一堆工具，连上后 LLM 其实并不知道：
MCP 规范有 Instructions 这个能力，但有的客户端不支持。Instructions 也会把所有内容一次性塞进上下文，很浪费 token。
另一种办法是把引导写进工具描述里。但这样有 2 个问题：
我们的折衷：提供 getInstructions 工具
思路很简单：Instructions 如果支持不好，那就变成工具。
LLM 可以按需调用 getInstructions。
比如做任务 A 时调用 getTaskAInstructions，MCP 服务器会返回一步步的提示、说明该如何做，以及如何用其它工具配合完成。
复杂的业务逻辑都放 instruction 工具背后，其它工具只需专注功能本身。工具描述只写核心用途。
本质上类似 Agent Skills：按需载入提示，比全局 Instructions 高效，因为不用一股脑塞进上下文。
很多 SaaS 产品中，有些密钥绝不能暴露（比如 client secret、API key、webhook 签名密钥）。一旦泄漏，别人可能伪造你或获取核心资源。
LLM 的风险在于聊天通道非安全，内容可能被记录、复制、转发、出现在调试日志中。你不能假设“只有我和模型能看到”。把长期密钥交给 LLM，或让它生成密钥给用户 copy，风险极高。
这在传统 web app 集成中很常见：开发者需要 secret 时，通常丢进服务器环境变量或配置文件，用来初始化 SDK。
为兼顾上手简单又不降低密钥安全性，我们做了三件事：
集成过程中只用临时密钥
聊天式引导配置时，MCP 服务器只返回短时有效的临时密钥（比如有效期一小时），它们足以让集成跑起来，并且常常在你上线前就失效了。上线前开发者再由后台控制台生成和替换成长期生产密钥，整个过程不走聊天。
明确划定安全边界
会清晰警告用户：不要在聊天中创建、粘贴或保存生产密钥。也提醒开发者，即使是环境变量或配置文件也可能泄露，只要 agent / LLM 能用工具或间接读取。因此，生产密钥只能放在无 AI 辅助集成的环境里。
生产密钥不走聊天，指引用户去后台控制台配置
长期密钥一律不在聊天生成或传递，统一在后台凭据页面生成与管理。聊天期间只给用户一个直达控制台的链接，辅助他们补全生产密钥配置流程。
Logto 有完整的管理 API。最初我们的想法是：把每个 API endpoint 都做成 MCP 工具。
很快就发现这样不行。
一是上下文爆炸。Logto 的 API 很多，一一映射会把上下文窗口塞满，每个工具描述都要耗费 token。
二是丢失了业务语义。API 对开发者来说就是最小原子能力，但用 Logto MCP 服务器的大多数用户并不是要构建底层系统，他们只关心任务怎么完成，不在意有多少接口。
举例：Logto 有个 sign-in-experience API，用于品牌定制、登录方式、注册方式和安全策略。
一开始我们想让 LLM 能用全部参数，考虑怎么组合接口。
但这种思路错了。用户不是在调接口，他们只是想改品牌、设登录方式。
所以应该有 updateBranding、updateSignInMethod、updateSignUpMethod 这样按任务设计的工具，剩下接口拼接交给 MCP 服务器内部处理。
Logto MCP 服务器应被视作一个产品，而不是裸 API 封装。它就是“另一个管理员后台”。
共识就很清楚：
read_file、write_file，让 coding agent 自己组合。补充原则：
getInstructions 工具，按需加载指引，工具本身描述也要简单。构建 MCP 服务器过程中我们也思考了生态未来有哪些可改进之处。
有时 MCP 服务器不仅要给工具，还需提供如何组合完成任务的业务指引，类似 Agent Skills。
在 SaaS 里很常见，比如：GitHub MCP 服务器、Logto MCP 服务器或数据分析平台。用户需要的是工作流，不是接口调用。
用 getInstructions 工具是一种折中，协议层支持会更好。
客户端常常连多个 MCP 服务器，但每个会话其实未必全都用得上。会话级启用/关闭可节约上下文空间。
工具调用占用大量上下文。如果 MCP 交互交给子 agent 来处理，主聊天里只显示精简后的结果即可。
以上就是我们在构建远程 MCP 服务器方面的经验分享。
如果你也在探索这个方向，可以试用 Logto MCP 服务器，或者加入我们的 Discord ，和社区伙伴交流更真实的落地经验。
后续，我们还会分享架构设计和 OAuth 流程的细节，敬请期待。