MCP正在吞噬API经济

Model Context Protocol对API集成做的事，正是REST对SOAP做的事：用代理可以自己发现和使用的东西，替换掉手写的集成层。

大多数资深工程师第一次看到MCP服务器时，会把它当作JSON-RPC的包装器打发掉。它确实是。2005年的HTTP上的REST也一样。

MCP真正回答的问题，正是REST二十年来回答得很糟糕的那个问题：一个软件如何向从未见过它的另一个软件暴露自己的能力？REST的回答是"读文档然后写个客户端"。那个答案只在读者是人类开发者时才成立。

REST API是为写客户端代码的人类设计的。端点、文档、按正确顺序用正确参数手写的fetch调用。每个集成都是定制的。

当消费者是人类开发者时，这运作得很好。当消费者是LLM时，它就崩溃了。LLM不会读你的Swagger文件然后决定把十二个端点中的哪三个串起来。它需要在输入里描述好能力：工具名、它做什么、输入schema、输出schema、副作用。

MCP正好给出了这种形态。一次`tools/list`调用返回每个能力以及模型可以在推理时处理的JSON schema。没有SDK，没有代码生成，没有接入工单。

让MCP具有变革性的不是任何单一功能。是运行时组合。

当每个服务都将自己暴露为MCP工具时，代理可以在推理时发现并串联它们。一个支持代理读取CRM、查询计费服务、撰写Slack消息、开出工单——使用它三十秒前才知道的工具。没有硬编码的集成。没有供应商特定的中间件。

这就是应用到代理上的Unix哲学。小而专注的工具相互组合。组合者不再是shell脚本；它是一个可以推理该组合哪些工具以及按什么顺序组合的模型。

让把代理连到任意工具变得易如反掌，也让把代理连到恶意工具变得易如反掌。工具投毒——描述承诺一种行为而实现做另一件事——是MCP时代的SQL注入。

今天发布MCP服务器的大多数团队没有在想这个。他们专注于让事情跑起来。网络历史上每一次重大安全危机都是这样开始的。

在MCP经济中获胜的团队不是最快发布的。是那些在不得不用痛苦方式学会之前，就搞定了工具来源、输出净化和沙箱的团队。

如果你构建的是会被其他软件消费的软件，你本该已经在发布MCP接口了。经济账逼着你做。

一次REST集成要花开发者几天。一个MCP工具要花几分钟。当集成变得便宜100倍时，你不会得到100倍同样的集成——你会得到整类以前不值得做的集成。Stripe已经在发布MCP服务器了。Linear也是。Supabase也是。

每个SaaS最终都会暴露MCP工具。每个内部服务都会有MCP接口。唯一真正的问题是你是否会在竞争对手之前发布一个。