Modem 发布 MCP server 与公开 API，让编码智能体直接读取客户反馈
Your coding agent should know what your customers said
Modem 的 MCP server 和公开 API 现已向所有用户开放，任何 MCP 客户端均可接入，让编码智能体直接查询经合成的客户反馈主题。其提供 search_modem、merge_topics 等读写工具及 invoke_modem_agent 子智能体。
Modem 的 MCP 服务器和公共 API 现已面向所有 Modem 用户开放。任何 MCP 客户端都可以通过 https://mcp.modem.dev/mcp 连接。
在构建过程中，我们发现把相关的客户反馈引入工作中很有用：谁遇到了这个 bug，他们期望什么，他们提出了什么要求。这让我们始终在构建正确的东西。
你的 agent 已经可以逐个访问这些来源：Slack 有 MCP 服务器，Intercom、Linear 等也有。但返回的是原始素材：线程、工单和重复报告，一次一个工具。Modem 将来自所有这些连接的反馈综合成主题、去重后的发现，并附上证据和报告者数量。我们的 MCP 服务器把这种综合结果交给你的 agent。
现在 agent 只需开口问就行。
你的 agent 能得到什么
通过 MCP 连接 Modem，你的编码 agent 将获得三样东西：
- 读取工具：
search_modem接受一个用自然语言提出的问题，搜索你已综合的主题，返回附有证据和报告者数量的发现。 - 写入工具：
merge_topics用于去重，update_topic用于重新排定优先级，create_companies用于创建或关联公司，等等，全部无需离开会话。 - 子 agent：
invoke_modem_agent运行完整的 Modem agent，适用于需要将 Slack、Gong、Intercom 和主题放在一起推理的问题。
用用户反馈来构建
Neil Chudleigh 开发了 superwhisper，一款面向 macOS 的 AI 驱动听写应用。他当时正在处理一个粘贴检测 bug 的 PR：在 Electron 和浏览器应用中听写后，录音窗口会卡住，但在 Apple Notes 中却正常。在编码会话中，他问 Modem 用户都说了些什么。回复是：
Claude Code 会话
modem - search_modem("recording window hangs after paste in electron")
返回 3 个相关主题
Modem 结果。按与我正在构建的 macOS 修复的相关性分组：
- Slack / Discord：三名用户报告在粘贴到聊天应用后录音窗口卡住；在 Apple Notes 中正常。主题：Recording window hangs after paste in Electron（5+ 名报告者）。
- 浏览器 + Claude 桌面应用：窗口不会隐藏，“只在某些应用中，比如我的浏览器或 Claude 桌面应用。”
- 一位队友确认了根本原因：基于浏览器的应用处理文本字段的方式与原生应用不同，因此粘贴永远不会通知录音窗口关闭。
- VS Code、OpenCode、iTerm2：在这些应用中粘贴后窗口也会卡住，但原因不同。此修复不涵盖这些情况。
- 自动提交：三名用户说他们的消息在听写后从不自动发送。这是另一个 bug；此 PR 不处理它。
结果按与它们打开的修复的相关性分组。仪表盘做不到这一点；它不知道你正在构建什么。
最上面的结果就是 Modem 的一个主题：来自 Slack 和 Discord 的报告，去重后合并为一条发现，并附有报告者数量。Neil 完全不必阅读其背后的 400 条消息。
Slack · #support
粘贴到 Slack 后录音窗口卡住
Discord · #bugs
在我的浏览器中听写后悬浮窗不会隐藏
Slack · #bug-reports
在 Claude 桌面中卡住，在 Apple Notes 中正常
modem
Recording window hangs after paste in Electron
bughigh priority5+ reporters
在原生应用中正常。在 Electron 和浏览器文本字段中可复现。
来源：Slack · Discord
modem
Neil 在会话结束时的结论：
今天用 mcp 还挺有用的
我们收下了。
我们如何写这篇文章
我们用 MCP 服务器发现了那个故事。为了准备写这篇文章，我们向 Modem MCP 提问：
客户对我们的 mcp 服务器有什么评价？
这一个问题就找出了那些在 API 存在数月前就提出需求的客户。它还重新浮现了上面 Neil 的故事，既突出了他的经历，也把他的引述作为证据。在此过程中，我们发现了自己产品中的一个缺口，并在同一次会话中使用写入工具为此提交了一个 Linear issue。
Token 高效
使用 Modem 搜索客户反馈既快速又 token 高效。你当然可以直接查询每个来源——Slack、Linear、GitHub、Intercom——但这些来源返回的是原始线程和工单，而 agent 在拼凑它们时要为读取的每个 token 付费。
我们测量过：在全新的 Claude Code 会话中问同一个问题，每次限制在一个来源。Modem 通常通过一次 search_modem 调用就能回答。其他会话则要搜索、拉取线程和 issue，并核对返回的内容。
| 来源 | 工具调用 | Token / 问题同一个问题，全新会话 | 对比 Modem |
|---|---|---|---|
| Modem · MCP | 1 | 28,255 | 基线 |
| GitHub · gh CLI | 32 | 66,404 | 2.4× |
| Linear · MCP | 10 | 70,966 | 2.5× |
| Slack · MCP | 10 | 72,180 | 2.6× |
| 三者全部 · 同一会话 | 14 | 129,558 | 4.6× |
任何单一来源都至少使用 2.4 倍的 token，却只能得到部分答案；每个来源只了解自己的孤岛。要匹配 Modem 的覆盖范围，意味着要在同一会话中查询全部三个来源，token 用量为 4.6 倍。综合在会话开始前就已经完成，因此 agent 读取的是发现结果，而不是线程。
这种模式并非特定于某个模型。我们用 Opus 5 和 Fable 5 在 Claude Code 中、GPT-5.6 Sol 在 Codex CLI 中、GLM 5.2 在 opencode 中重新进行了正面对比——同一会话中全部三个来源对比仅用 Modem：
| 模型 | Token / 问题同一个问题：仅 Modem MCP 对比全部三个来源 | 对比 Modem |
|---|---|---|
| Fable 5 · Claude Code | Modem22,264全部 3 个61,875 | 2.8× |
| Opus 5 · Claude Code | Modem33,134全部 3 个116,370 | 3.5× |
| Sonnet 5 · Claude Code | Modem28,255全部 3 个129,558 | 4.6× |
| GPT-5.6 Sol · Codex CLI | Modem30,995全部 3 个181,220 | 5.8× |
| GLM 5.2 · opencode | Modem8,388全部 3 个112,678 | 13.4× |
每个模型都因跳过综合环节而付出了成倍的代价，从 2.8 倍（Fable 5）到 13.4 倍（GLM 5.2）。GPT-5.6 Sol 为得出聚合答案付出的努力最多，平均每次会话调用 61 次工具；有一次运行调用了 95 次。
开始使用
在 Claude Code 中：
claude mcp add --transport http modem https://mcp.modem.dev/mcp然后运行 /mcp 进行授权。授权通过浏览器中的 OAuth 完成；无需配置 API 密钥。Cursor、VS Code、Copilot、Codex 和 opencode 通过 Streamable HTTP 连接到同一端点，文档中有各客户端的配置说明。
然后就可以像在 PR 过程中随手打字那样，询问你正在处理的事情：
我在修文件上传的超时问题。哪些用户遇到过这个问题，他们是怎么说的？
如果你想从自己的系统向 Modem 推送上下文，还有一个位于 api.modem.dev/v1 的公共 API。那个值得单独写一篇文章，很快就会发布；API 参考中现在已有详细信息。
把它连接起来，然后问问你今天正在构建的东西。
来源：Modem Blog · modem.ai