MCP 真香还是鸡肋？生产环境实战揭秘

Ask HN: Who is using MCP in production?

▲ 180sukit191 HN 评论区

我关注 MCP 很久了，但很少看到有人在生产环境使用。大家真的在用吗？具体用来做什么？相比直接调用 API 或 CLI，MCP 到底有什么独特优势？

我们用它做了一个 AI 工具，让用户直接报告 Bug 或提需求。它能自动查重、撰写工单并提交。作为生产工具，我们需要低成本且准确，用 MCP 比手写 API 适配器更自然，Linear 的 MCP 设计尤其出色。
我们刚上线了一个新工具，MCP 让应用资源间的沟通更顺畅。它是 Agent 与远程资源交互的标准方式，Agent 能更直观地理解可用功能及使用方法，具体可参考 mcp tools/resources/prompts。
我觉得 CLI 或直接调用 API 便宜又快速。目前我只用 Jira MCP，纯粹是因为很久前配置过就一直没动，其他场景下 MCP 优势不明显。
阅读原文 →RSS

HN 评论区

191
  1. Aldipower

    我们从 3 月 26 日起就在生产环境中使用 MCP，用于面向用户的耐力运动分析和规划，该系统直接集成了 MCP 主机，也就是 ChatGPT、Claude、Grok、Perplexity.ai、Mistral 等聊天界面，你懂的。所有这些平台都允许用户添加自定义 MCP 服务器，用户只需简单说明即可操作。以连接 Claude 为例：https://www.tredict.com/faq/connect-claude-web-with-tredict/

    通过这种方式，用户可以让 Claude 基于先前的分析，创建并向他们的 Garmin 设备推送训练计划。

    我们还有一个 ChatGPT 应用，后台使用了 MCP：https://chatgpt.com/plugins/plugin_asdk_app_69aef5b699a08191...

    重点在于，MCP 是产品的核心支柱，它让普通用户无需了解任何技术细节就能完成各种操作。

    关于“MCP 是否无用”的讨论，从普通消费者用户的角度来看完全是毫无意义的，他们甚至有时根本不知道 MCP 是什么。Tredict 的 ChatGPT 应用只需一键点击和简单的 OAuth 流程即可连接。就这么简单。

  2. 5ersi

    MCP 的价值正在略微下降，因为 AI Agent 在调用 API/CLI 方面变得越来越智能。例如，我通过 Claude 使用 gh cli，而不是他们的 MCP，因为我已经配置好了 cli，所以没必要再用 MCP。

    如果 MCP 能够跨多个数据源整合结果，那将具有巨大的潜在价值。例如，在工作中我们使用内部 MCP 在五个不同的（遗留）系统中搜索日志和指标。它能在几分钟内发现不同系统事件之间的关联。

  3. MitziMoto

    我们在生产环境中使用 MCP 来支持面向客户的语音代理。我们的自定义 MCP 服务器定义了语音代理与客户服务交互所需的工具和资源（例如：预约安排、查询订单状态等）。

    现在，我们可以将任何我们选择的语音代理平台——ElevenLabs、vapi、pipecat 等等——指向我们的自定义 MCP 服务器，它们就能立即理解可用的工具、输入参数以及使用方法。

    与 HN 上大家推崇的替代方案（如 CLI 和 API）相比，这简直是不二之选。老实说，我甚至不确定现实的替代方案会是什么。

    难道我应该打包分发一个 CLI 给 ElevenLabs，然后要求他们使用吗？还是给他们一份完整的 API 规范让他们去实现？

    我只需提供一个端点和凭证，他们的平台就能立刻知道如何与我的系统通信。ElevenLabs 没有人知道也不关心我们的实现细节。

    HN 很难跳出“开发者在终端里用 Claude Code 写代码”这一使用场景来看待 AI 的使用。真正的生产级 Agent 有着截然不同的用例！

    当你无法掌控与另一个系统集成时的所有环节时，就需要一个定义良好的标准。这正是 MCP 提供的东西。

  4. navigate8310

    我对中文教材进行了 OCR 处理，并制作了一个无状态的 MCP，让我能够仅依据教材来夯实中文学习基础。有了它，我可以开始测验，理解同义词之间的差异，而在复习时不会输入任何额外的语法知识。我特意使用 glm 5.3，因为它是理解细微差别的语言专用 LLM 中最强的。

    这里是仓库：https://github.com/iodize6399/xuexi-keben

    这里是服务器本身：https://keben.555420.xyz

  5. hkchad

    MCP 对于将你的服务推广到开发者圈子之外非常有用。非技术用户只需点击链接，触发 OAuth 流程即可完成认证。这是 API 做不到的。API 对于通过 CLI 使用 AI 的开发者来说仍然更好，但对于基于 Web 或桌面的客户端来说，MCP 更容易被采纳。

  6. tasoeur

    我的背景是实时视觉特效制作，但我已在（原生）自定义框架中广泛使用 MCP，以此驱动应用内 UI 更新，当然还包括双向状态查询，以及用于闭环验证的帧缓冲区捕获。

    我觉得 CLI 可能也行，但那样我就得自己实现类似的东西。

    话虽如此，我也被那些老问题坑过：工具太多会导致上下文窗口迅速膨胀，而且有些 Agent 有时只会浏览工具列表的一部分而不查询全部，从而导致行为错误。

    如果你有 Token 可以烧，欢迎查看源代码，看看它是如何被广泛使用的：https://github.com/sxp-studio/subjective-zero

    （有一段视频展示 MCP 的实际效果，有点长，你可以跳过：https://www.youtube.com/watch?v=DcI1tsPJ8eM）

    我还遇到过另一种很酷的 MCP 用法，居然来自……法国政府！他们将其用于开放数据计划：https://github.com/datagouv/datagouv-mcp

  7. cagz

    是的，生产环境中有很多用例，主要用途是为 Agent 抽象 API 访问。在我们的案例中，这些大多是内部 MCP 服务器，专为特定 Agent 定制。

    为什么选择 MCP 而不是 CLI 或让 Agent 直接访问 API？

    直接访问（Curl/自定义小函数）：这要求 Agent 完全理解 API 规范。是的，可以通过渐进式披露来保护上下文，但这本质上意味着 Agent 每次在上下文中使用前都必须重新理解 API。此外，典型的 API 规范可能对 Agent 并不友好。如果在调用端点时有细微差别，该放在哪里？放进 OAS 描述里？可行，但很笨拙。

    CLI：效果很好，特别是当复杂的后端已有第三方 CLI 时。但这假设有一个文档完善、对 Agent 友好的 CLI，而大多数 CLI 是为人或 CI/CD 设计的。说到 MCP 占用太多上下文，想想 Agent 从 my_cli --help 开始，逐个查看开关和参数以弄清楚如何调用 CLI 的场景。当调用知名 CLI（如 aws）时问题不大，但任何更小众（或自定义）的 CLI 都需要多轮对话才能组合出最终的 CLI 命令。

    MCP：虽然也有问题，但它提供了一种原生的 Agent 解决方案。Agent 需要了解关于工具的所有信息一次性提供。在企业环境中，MCP 可以通过 MCP 网关提供服务，提供治理和权限管理，这与 [...] 截然相反。

  8. jamesponddotco

    我为我的语音助手构建了一个 MCP 服务器。默认情况下，Home Assistant 为模型提供了一些工具，但我觉得还不够，所以我自己做了一个。

    它包含获取真实笑话、做数学运算、单位换算、获取股票信息、使用 Kagi 搜索网络以及其他我认为语音助手必备的功能。甚至我老婆都批准了。

    在工作中，我也用我们的 MCP 服务器来调试和排查代码问题。就在昨天，我用它来找出为什么某个标签没有出现在追踪日志中；借助 MCP 服务器，LLM 能够看到该标签存在于父级追踪中，但在过程中丢失了，并找出了原因。

    没有 MCP 服务器能找到这个问题吗？可以，但我得花几个小时去翻阅冗长的追踪日志，而 MCP 和 LLM 几分钟就找到了问题所在。

同日更多故事

2026-09-04