一个开发者的 MCP体验

Thoughts on Anthropic's MCP 对Anthropic MCP的思考

I've been playing with Anthropic's MCP for a little while now, and I have a few gripes. I understand it is undergoing a kind of Cambrian explosion right now, but I am not very impressed with it. Maybe it's echoes of TRON, but I can't bring myself to like it.

我已经玩了一段时间Anthropic的MCP，有一些不满。我明白它现在正处于一种寒武纪大爆发，但我对它并不太满意。也许是因为TRON的回声，但我无法喜欢上它。

Pointless Complexity 无意义的复杂性

I was looking at the Python SDK, and all I could see was wrappers inside wrappers into accessors and decorators that could probably be replaced by a few snippets of JSON and a dictionary. I understand that cosplaying as Java developers (or, worse, TypeScript) is a common affliction in modern Python codebases, but I kept wondering exactly why I would need to create a new server to expose an existing API, which leads me to my next point:

我在查看Python SDK，我看到的只是层层嵌套的包装器，从访问器到装饰器，这些可能可以用几段JSON和字典来替代。我明白模仿Java开发者（或者更糟糕的TypeScript）是现代Python代码库中常见的疾病，但我一直在想，我为什么要创建一个新的服务器来暴露现有的API，这让我想到了下一个问题：

Zero Re-use of Existing API Surfaces 未重用现有API接口

If I want an LLM to use an existing service, why don't I have the LLM just consume the API directly? Why do I need to create a new server that wraps the existing API? We have had REST and Swagger for a long time now, and it would be a lot easier to just take a Swagger spec and generate a simplified JSON schema from it that aligned with the usual tool definitions. Maybe FastOpenAPI would be a good fit for this, at least for some modern APIs.

如果我想让LLM使用现有服务，为什么不让LLM直接消费API呢？为什么我需要创建一个新的服务器来包装现有的API？我们已经有了REST和Swagger很长时间了，直接从Swagger规范生成一个与常用工具定义对齐的简化JSON模式会容易得多。也许FastOpenAPI适合这个用途，至少对于一些现代API来说是这样。

I also don't see a lot of emphasis on security, access control, or anything that would make me feel comfortable exposing an MCP server to an LLM. I get that this is a work in progress, but it feels like a lot of effort is being wasted on creating a new server for every API instead of just using the existing ones.

我也看不到很多对安全、访问控制或任何让我感到安心地将MCP服务器暴露于LLM的重视。我明白这还是一个正在进行中的项目，但感觉很多努力都浪费在了为每个API创建新的服务器上，而不是直接使用现有的服务器。

Persistent Connections 持久连接

I get that MCP is being designed to be a kind of "universal" interface for LLMs, but the fact that it is connection-oriented and stateful means that it is not necessarily a good fit for API-based applications.

我明白MCP正在被设计成一种针对LLMs的"通用"接口，但它是面向连接和有状态的，这意味着它不一定适合基于API的应用。

The design seems to assume you are either running a bunch of servers locally (as subprocesses, which, again, raises a few interesting security issues) or talking to something with enough compute power to run a stateful server, and isn't really a good fit for the way we use APIs today, considering many are usually run in stateless hosting environments like AWS Lambda or Cloudflare Workers.

设计似乎假设你要么是在本地运行大量服务器（作为子进程，这又引发了一些有趣的安全问题），要么是在与拥有足够计算能力以运行有状态服务器的系统进行通信，而这并不适合我们今天使用API的方式，因为许多API通常在无状态托管环境中运行，如AWS Lambda或Cloudflare Workers。

At least Anthropic had the good taste to use server-sent events (which is not popular with the SocketIO crowd, of course), but even if I remove the network component, the way local MCP servers are integrated and run as separate processes feels messy and wasteful (and don't get me started on the overuse of uv or uvx to pack everything into isolated environments).

至少Anthropic有品味地使用了服务器端发送事件（当然，这在SocketIO群体中并不流行），但即使我移除了网络组件，本地MCP服务器作为独立进程的集成和运行方式仍然显得杂乱无章、浪费资源（更别提过度使用uv或uvx来将所有内容打包到隔离环境中了）。

Too Many Options 选项太多

My limited experimentation quickly surfaced another issue, which is that MCP tends to crowd the model context with too many options. There doesn't seem to be a clear way to set priorities or a set of good examples to expose MCP server metadata–so your model API calls will just pack all the stuff an MCP server can do and shove it into the context, which is both wasteful of tokens and leads to erratic behavior from models.

我的有限实验很快暴露出另一个问题，那就是MCP往往会因为选项过多而使模型上下文变得拥挤。似乎没有明确的方法来设置优先级或提供一组良好的示例来展示MCP服务器元数据——因此你的模型API调用将把MCP服务器能做的所有事情都打包进上下文，这不仅浪费了令牌，还导致模型行为不稳定。

I think MCP is missing some form of "routing" or stepwise, selective exposure of options, which would allow you to expose only the relevant options for a given task.

我认为MCP缺少一种"路由"或逐步、选择性展示选项的形式，这将允许你仅展示给定任务的相关选项。

Conclusion 结论

Right now, I'm not overly excited by MCP over "standard" tool calling. I much prefer agents.json and the concepts around endpoint discovery, which feel much more natural if you are working with APIs.

目前，我对MCP与"标准"工具调用并没有过于兴奋。我更倾向于agents.json以及端点发现的概念，这些在处理API时感觉更为自然。

But of course everything around AI and LLMs is in a chaotic state of flux, and I've been around for long enough to know that the best ideas often take a while to surface. For now, I will most likely stick to standard tool calling.

但当然，围绕AI和LLMs的一切都处于混乱的变动之中，我经验丰富，知道最好的想法往往需要一段时间才能浮现。现在，我可能还是会坚持使用标准工具调用。