远程 MCP 服务器实战：AI 时代下 SaaS 产品的新入口

SaaS 产品一直存在一个老问题：实现价值的时间太慢。很多用户还没到“aha”时刻就流失了。

我们在 Logto 的上手流程上做了很多次迭代。这是有帮助的，但瓶颈并没有完全消失。你还是需要去看文档、扫教程、装 SDK、配置参数、写代码，然后在最后 10% 调试通了才能跑起来。

于是我们尝试了另一种思路：把远程 MCP 服务器作为 Logto 的 IDE 内控制平面。客户不再需要点来点去地操作管理后台，而是直接在开发应用的 IDE 接口，通过对话配置 Logto 并生成集成代码。

只需一个提问就能让你从零到集成上线。Agent 不仅会生成代码，还会在你的租户中同步创建并配置 Logto 应用，全程都在 IDE 内完成。(试用 Logto MCP 服务器)

这篇文章会分享我们在构建 Logto MCP 服务器时的经验与思考，包括：

• MCP 与 Agent Skills：为何我们选择 MCP
• 实际部署 MCP 服务器时遇到的问题及我们的解决方案
• 我们是如何设计 MCP 工具的，以及你应该如何设计自己的工具
• 我们对 MCP 未来的展望

MCP vs. 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 个支持 MCP 的 AI 应用，包括 VS Code、Cursor、Windsurf 等工具。

Agent Skills 仍是平台特定的，即使很多平台都支持了 Skills，但当我们上线 MCP 服务器时，所有支持 MCP 的应用用户都能马上用；而如果上线 Skill，只有在对应平台的用户能用。

此外，MCP 还是 Agentic AI Foundation (AAIF) 的协议级标准，生态会继续壮大。对我们来说，MCP 值得长期投入。

交付与维护成本#

Agent Skills 依赖平台 API 或 CLI，很快会碰到这些问题：

• 如果 API 变了怎么办？
• 如果 CLI 不兼容了呢？
• Skill 怎么分发和升级？

你还需发放 CLI、管理分散的凭据、适配多平台、指导用户升级。ROI 很低。

MCP 服务器要简单很多，用户只需连 URL，总是最新版本。我们升级 MCP 服务器，用户下次连就自动获得新版，无需额外升级。如果 API 变了，只需在 MCP 服务器里动手就行。

大多数 SaaS 产品本身就有扎实的基础设施（完善的 API 和成熟的认证体系）。MCP 服务器完全可以作为 API 的“AI 接口”，就像后台控制台是另一个接口一样。

对 Logto 而言，选择 MCP 服务器既契合架构，也能发挥我们已有的能力。

这还能把所有请求集中在一个入口上，日志与审计更统一，权限也很清晰：AI 只能做用户授权的事。这种模式结构上更适合企业和合规应用场景。

部署 MCP 服务器时遇到的问题与解决方法#

MCP 还不完美。多数问题是生态成熟度引起的，随着时间会改善。在此之前，我们用各种折衷方案解决实际需求。

MCP 特性支持碎片化#

MCP 规范定义了很多能力，但客户端支持各异：

• Tools：广泛支持
• OAuth：VS Code 支持良好，Cursor 需靠 mcp-remote 作为桥接
• 其它特性（Resources、Prompts、Instructions）：支持不稳定

目前来看，Tools 是最可靠的公有层（可在 MCP 社区页面 查各客户端都支持哪些能力）。

所以我们的策略就是：基于 Tools 构建。

LLM 不会用你的工具#

这是业务层面的问题。

Agent Skills 会把业务逻辑和上下文绑定在一块，LLM 本身就会如何用。而 MCP 只是暴露一堆工具，连上后 LLM 其实并不知道：

• 该用在哪些场景
• 先调用哪个、再怎么组合
• 有哪些业务约束

MCP 规范有 Instructions 这个能力，但有的客户端不支持。Instructions 也会把所有内容一次性塞进上下文，很浪费 token。

另一种办法是把引导写进工具描述里。但这样有 2 个问题：

• 描述会变得非常复杂，多工具组合会导致描述逻辑难理顺且难维护。
• 工具多了，描述内容就会吃掉大量上下文窗口。

我们的折衷：提供 getInstructions 工具

思路很简单：Instructions 如果支持不好，那就变成工具。

LLM 可以按需调用 getInstructions。
比如做任务 A 时调用 getTaskAInstructions，MCP 服务器会返回一步步的提示、说明该如何做，以及如何用其它工具配合完成。

复杂的业务逻辑都放 instruction 工具背后，其它工具只需专注功能本身。工具描述只写核心用途。

本质上类似 Agent Skills：按需载入提示，比全局 Instructions 高效，因为不用一股脑塞进上下文。

LLM 可能泄露你的密钥#

很多 SaaS 产品中，有些密钥绝不能暴露（比如 client secret、API key、webhook 签名密钥）。一旦泄漏，别人可能伪造你或获取核心资源。

LLM 的风险在于聊天通道非安全，内容可能被记录、复制、转发、出现在调试日志中。你不能假设“只有我和模型能看到”。把长期密钥交给 LLM，或让它生成密钥给用户 copy，风险极高。

这在传统 web app 集成中很常见：开发者需要 secret 时，通常丢进服务器环境变量或配置文件，用来初始化 SDK。

为兼顾上手简单又不降低密钥安全性，我们做了三件事：

• 集成过程中只用临时密钥

  聊天式引导配置时，MCP 服务器只返回短时有效的临时密钥（比如有效期一小时），它们足以让集成跑起来，并且常常在你上线前就失效了。上线前开发者再由后台控制台生成和替换成长期生产密钥，整个过程不走聊天。

• 明确划定安全边界

  会清晰警告用户：不要在聊天中创建、粘贴或保存生产密钥。也提醒开发者，即使是环境变量或配置文件也可能泄露，只要 agent / LLM 能用工具或间接读取。因此，生产密钥只能放在无 AI 辅助集成的环境里。

• 生产密钥不走聊天，指引用户去后台控制台配置

  长期密钥一律不在聊天生成或传递，统一在后台凭据页面生成与管理。聊天期间只给用户一个直达控制台的链接，辅助他们补全生产密钥配置流程。

我们如何设计 MCP 工具#

我们的探索路径#

Logto 有完整的管理 API。最初我们的想法是：把每个 API endpoint 都做成 MCP 工具。

很快就发现这样不行。

一是上下文爆炸。Logto 的 API 很多，一一映射会把上下文窗口塞满，每个工具描述都要耗费 token。

二是丢失了业务语义。API 对开发者来说就是最小原子能力，但用 Logto MCP 服务器的大多数用户并不是要构建底层系统，他们只关心任务怎么完成，不在意有多少接口。

举例：Logto 有个 sign-in-experience API，用于品牌定制、登录方式、注册方式和安全策略。 一开始我们想让 LLM 能用全部参数，考虑怎么组合接口。

但这种思路错了。用户不是在调接口，他们只是想改品牌、设登录方式。

所以应该有 updateBranding、updateSignInMethod、updateSignUpMethod 这样按任务设计的工具，剩下接口拼接交给 MCP 服务器内部处理。

Logto MCP 服务器应被视作一个产品，而不是裸 API 封装。它就是“另一个管理员后台”。

MCP 工具设计思路#

共识就很清楚：

• 如果用户会直接用你的服务（像操作后台那样），工具就该面向任务、业务化。
• 如果是给别人搭建能力底座，工具就应保持原子化简单。比如文件系统 MCP 服务器，只提供 read_file、write_file，让 coding agent 自己组合。

补充原则：

• 工具逻辑和描述要尽量简洁省上下文。
• 复杂流程用 getInstructions 工具，按需加载指引，工具本身描述也要简单。

对 MCP 未来的期待#

构建 MCP 服务器过程中我们也思考了生态未来有哪些可改进之处。

Skill 级能力交付#

有时 MCP 服务器不仅要给工具，还需提供如何组合完成任务的业务指引，类似 Agent Skills。

在 SaaS 里很常见，比如：GitHub MCP 服务器、Logto MCP 服务器或数据分析平台。用户需要的是工作流，不是接口调用。

用 getInstructions 工具是一种折中，协议层支持会更好。

会话粒度的 MCP 启用#

客户端常常连多个 MCP 服务器，但每个会话其实未必全都用得上。会话级启用/关闭可节约上下文空间。

MCP 工具调用的上下文隔离#

工具调用占用大量上下文。如果 MCP 交互交给子 agent 来处理，主聊天里只显示精简后的结果即可。

总结#

以上就是我们在构建远程 MCP 服务器方面的经验分享。

如果你也在探索这个方向，可以试用 Logto MCP 服务器，或者加入我们的 Discord ，和社区伙伴交流更真实的落地经验。

后续，我们还会分享架构设计和 OAuth 流程的细节，敬请期待。