Model Context Protocol 正在成为 AI 应用连接外部工具的标准通道。当越来越多的 agent 开始通过 MCP 调用服务器，SaaS 团队面临的就不只是“服务挂了没有”的问题，而是“agent 是否选错了工具”“模型是否把参数传歪了”这类更微妙的问题。Spanly 就是冲着这个空白来的——它的定位是 MCP 服务器的可观测性与监控平台。
从官网信息来看，Spanly 主打的是“drop-in”式的接入体验。你不用改业务代码，通过 CLI 或 SDK 就能为现有的 MCP 服务器接入监控。它监控的维度包括 错误率、会话轨迹、延迟、客户端分析以及部署告警，基本覆盖了一个生产级服务需要盯住的全部关键指标。
监控的不只是健康状态
传统监控工具关注 p95 延迟和错误码，但 MCP 服务器的问题往往更深一层。Spanly 官网展示的界面里，问题被归类为“工具投毒”“Schema 正确性”“运行时安全”等类型。举几个例子：提示注入出现在工具输出里、工具参数中返回了密钥、工具名称让 agent 选错指令、schema 接受格式错误的参数——这些都不是传统 APM 能直接告诉你的。
官方强调，扫描器已经分析了大量生产 MCP 服务器（官网当天显示“11,127 台 MCP 服务器被扫描”），因此它“知道问题长什么样”。这种基于大规模扫描积累的检测能力，是它区别于通用监控工具的关键卖点。
从发现问题到自动修复
更实用的一点是，Spanly 不只是报问题，还尝试给出补丁。官网截图显示，它可以针对某个工具的重命名、schema 收紧、输出裁剪等提出修改建议，并且通过 A/B 方式先在 10%～20% 的实时会话中测试，验证有效后再逐步应用到全部流量。这个“先小范围验证再全量上线”的思路，对生产环境来说很务实。
同时，它会把修复建议按来源分门别类，有的等待上游更新，有的可以直接应用。这意味着团队不用自己从头分析 MCP 协议细节，省掉不少排查时间。
集成与数据驻留
在现有监控栈的处理上，Spanly 没有打算取代 Datadog、Sentry 或 New Relic，而是作为补充，与它们共存。如果你已经在用这些工具，可以把它当成 MCP 层的专用探针。此外，它提供美国与欧盟两个地区的数据驻留选项，对数据合规要求高的企业会比较友好。
具体部署方式上，官方提供 CLI 脚本和 SDK，支持 30 秒免费扫描。价格方面，明确有免费层，但完整价格体系没有完全公开，需要以官网为准。
适合谁用
如果你的团队已经在生产环境对外提供 MCP 服务器，并且用户是各类 AI agent 客户端，那 Spanly 会是一个值得试用的补充监控层。它特别适合那种“明明服务没挂，但 agent 就是表现不对”的场景——问题往往不在响应状态码里，而在工具暴露的方式上。
另一个典型场景是，当一个 MCP 服务器要同时服务 Claude、Cursor 等多种客户端时，不同客户端对工具的调用方式可能存在差异。官网那句话“Works in Claude, Broken in Cursor”说的就是这种痛苦。用统一的扫描和监控来提前暴露问题，比等客户投诉要聪明得多。
当然，Spanly 本身还很年轻，公开的技术细节有限，扫描器的检测准确性也需要更多实际部署来验证。建议先跑一次免费扫描，看看它能不能命中你已知的几个隐患点，再决定要不要深入接入。
对任何正在把 MCP 推向生产的人来说，可观测性迟早要补上。Spanly 是这一领域走得比较早的玩家之一，值得关注。
评论
暂无评论
成为第一个评论的人