文章核心内容：作者认为在某些任务中，代码比MCP（Model Context Protocol）表现更好，尤其是当命令行工具可用时，代理编码工具更倾向于使用这些工具。然而，CLI工具存在平台依赖、版本依赖和文档不全等问题，导致初次使用时经常失败。作者提出了一种新思路，即使用MCP服务器暴露单一工具，并接受编程代码作为输入，以解决这些挑战。

文章标题：你的MCP不需要30种工具，它需要代码

主要内容：

在2025年8月18日发布的一篇文章中，作者探讨了为什么在某些任务中，代码比MCP（模型上下文协议）表现更好。作者指出，虽然命令行工具（CLI）在某些情况下非常有用，但它们存在一些难以解决的挑战，如平台依赖性、版本不一致性和文档缺失等问题。这些问题在使用工具时常常导致失败，尤其是在处理非ASCII字符串输入或复杂字符编码时。

作者提出了一种新的思路：通过MCP服务器暴露一个单一工具，该工具接受编程代码作为输入。这种方法的核心是使用Python解释器作为MCP服务器，允许代理通过发送Python代码来执行任务。这种方法不仅简化了工具的使用，还提高了代码的可重用性和可组合性。

主要挑战： 1. CLI工具的局限性：CLI工具常常依赖于特定的平台和版本，且文档不完善，导致初次使用时容易失败。 2. 复杂字符处理：在处理非ASCII字符串或控制字符时，CLI工具表现不佳，甚至需要额外的工具来解决这些问题。 3. 会话管理：CLI工具在多轮交互中难以保持会话状态，导致代理可能丢失会话或重新开始。

解决方案： 作者通过实验展示了如何使用Python解释器作为MCP服务器，允许代理通过发送Python代码来执行任务。这种方法不仅简化了工具的使用，还提高了代码的可重用性和可组合性。例如，作者开发的pexpect-mcp工具允许代理通过Python代码与命令行程序进行交互，并在会话中保持状态。

优势： 1. 代码可重用性：代理可以将会话中的代码保存为可重用的Python脚本，减少了后续任务的复杂性。 2. 状态管理：MCP服务器可以保持会话状态，避免了CLI工具在多轮交互中的状态丢失问题。 3. 灵活性：通过Python代码，代理可以灵活地组合和执行各种任务，而不需要依赖多个独立的工具。

未来展望： 作者还探讨了将这种方法应用于其他工具的可能性，例如使用JavaScript代替Python来执行Playwright API。虽然目前的结果还不够成熟，但这种方法展示了通过单一工具暴露编程语言的潜力，进一步简化了代理与工具的交互。

总结： 通过将MCP服务器与编程语言结合，作者提出了一种简化工具使用、提高代码可重用性和可组合性的新方法。这种方法不仅解决了CLI工具的局限性，还为未来的工具开发提供了新的思路。

评论内容主要围绕MCP（Model Context Protocol）的优缺点、安全性、替代方案以及实际应用中的问题展开。以下是总结：

1. MCP的局限性与批评：

   • 评论8指出，MCP虽然承诺“连接模型与世界”，但实际上限制了LLM的能力，更像是“护栏”而非“超能力”。
     • 引用：“By giving an LLM a set of tools, 30 in the Playwright case from the article, you’re essentially restricting what it can do.”
   • 评论10提到，随着工具数量的增加，代理选择错误工具的频率显著上升，可能是一个难以解决的问题。
     • 引用：“the agent picks the wrong tool a lot of the time and it seems to have gotten significantly worse the more tools I added.”

2. 安全性与沙箱：

   • 评论3强调将AI助手置于沙箱中以确保安全，并分享了使用Guix和Bubblewrap的实践经验。
     • 引用：“I put my AI assistant in a sandbox. There, it can do whatever it wants, including deleting or mutating anything that would otherwise be harmful.”
   • 评论7介绍了一个安全的MCP服务器，允许LLM在受限制的环境中生成和执行JavaScript代码。
     • 引用：“Lets the LLM safely generate and execute whatever code it needs. Bounded by statement count, memory limits, and runtime limits.”

3. 替代方案与改进：

   • 评论5提出了一种替代协议，允许代理直接调用本地端点，而不是启动专用的MCP服务器。
     • 引用：“Started on working on an alternative protocol, which lets agents call native endpoints directly (HTTP/CLI/WebSocket) via ‘manuals’ and ‘providers’.”
   • 评论12介绍了一个改进的MCP服务器，通过YAML描述工具，提高了可发现性和执行效率。
     • 引用：“You write a yaml describing your tools (lint/format/test/build), and it exposes them to agents MCP.”

4. MCP的必要性与质疑：

   • 评论9质疑MCP的必要性，认为现有的Swagger或gRPC协议已经足够。
     • 引用：“I wish someone would write a clear, crisp explanation for why MCP is needed over simply supporting swagger or proto/grpc.”
   • 评论18批评MCP缺乏正式的行为规则，认为其本质上无法实现其承诺的功能。
     • 引用：“MCP is not a protocol. Which is the point of MCP, making it essentially worthless because it doesn’t define actual behavioral rules.”

5. 实际应用中的问题：

   • 评论6分享了使用MCP构建CLI工具时的失败经历，认为MCP过于复杂且不必要。
     • 引用：“Fails and i’ve no idea why, meanwhile python code works without issues.”
   • 评论13对允许黑盒运行任意Python代码的安全性表示担忧。
     • 引用：“Imagine 50 years of computer security to have articles come up on hackernews saying ‘what you need is to allow a black box to run arbitrary python code’.”

总结：MCP在连接LLM与外部工具方面有其优势，但也存在限制、安全性和复杂性问题。许多评论者提出了替代方案或改进建议，同时对MCP的必要性和实际应用中的问题提出了质疑。