详细内容或原文请订阅后点击阅览
适用于认为不需要 MCP 的开发人员的 MCP
以下文章最初出现在 Block 的博客上，经作者许可在此重新发布。最近，我在网上看到越来越多的开发者开始关注 MCP。 Darren Shepherd 的一条推文对此进行了很好的总结：大多数开发人员都是通过编码代理（Cursor、VS Code）引入 MCP，并且大多数开发人员都在努力 [...]
来源:O'Reilly Media _AI & ML以下文章最初出现在 Block 的博客上，经作者许可在此重新发布。
最近，我看到越来越多的在线开发者开始关注 MCP。 Darren Shepherd 的一条推文总结得很好：
大多数开发人员是通过编码代理（Cursor、VS Code）引入 MCP 的，并且大多数开发人员在这个用例中都很难从 MCP 中获取价值……所以他们拒绝 MCP，因为他们有可用的 CLI 和脚本，这对他们来说更好。
公平。大多数开发人员都是通过一些与代码聊天的经验了解 MCP 的，有时感觉并不比打开终端并使用您知道的工具更好。但事情是这样的……
MCP 不仅仅为开发人员构建。
它们不仅仅适合 IDE 副驾驶或代码伙伴。在 Block，我们在各个方面都使用 MCP，从财务到设计，从法律到工程。我对不同的团队如何使用 goose（一种 AI 代理）进行了完整的演讲。重点是 MCP 是一个协议。您在其之上构建的内容可以服务于各种工作流程。
但我明白了……让我们来谈谈值得您花时间的开发特定内容。
GitHub：不仅仅是 CLI
如果您的第一个想法是“当我有 CLI 时为什么要使用 GitHub MCP？”我听到了。 GitHub 的 MCP 现在有点臃肿。 （他们知道。他们正在努力。）
而且：你的想法太本地化了。
您正在想象一个单独的开发设置，您在终端中使用 GitHub CLI 来完成您的工作。老实说，如果您所做的只是打开 PR 或检查问题，那么您可能应该使用 CLI。
但 CLI 从来就不是为了跨工具进行协调。它是为本地线性命令而构建的。但是，如果您的 GitHub 交互完全发生在其他地方怎么办？
当您的工作涉及 GitHub、Slack 和 Jira 等多个系统而无需将其拼接在一起时，MCP 就会大放异彩。
这是我们团队的一个真实示例：
松弛线程。真正的实时开发人员。
Dev 1：我认为 xyz 有一个错误
Dev 2：让我检查一下……是的，我认为你是对的。