我想不出MCP存在的任何强有力的技术理由。有很多微弱的技术原因，也有很强的社会学原因。讽刺的是，我仍然强烈地感到这是必要的。我写这篇文章是为了强迫自己理清自己的想法，并听取其他人的意见。

误解：MCP 不进入提示

您绝对可以直接将 MCP 工具声明中的 JSON 粘贴到提示中。它会起作用，而且可以说比使用 OpenAPI 做同样的事情更好。但它是 JSON，是一种非常易于解析的结构化信息，并且大多数法学硕士都接受过使用某些类似 XML 的变体进行函数调用的培训。

LLM 工具声明可以如下所示：

MCP 并不关心您的提示符是什么样子。这不是 MCP 的功能。

工具库

MCP 有两个主要功能：

它还执行许多其他操作（日志记录、采样等），但工具调用是最常实现和使用的部分。

您可以使用 OpenAPI 完成同样的事情：

这比您想象的还要容易。 OpenAPI 操作有一个operationId ，通常设置为服务器 API 的函数名称。

这是一个很好的论点，至少从表面上看是这样。以下是代表异步任务的典型 API 示例：

图 TD c((client))–>start_job c–>poll_status c–>get_result

您可以将所有这些包装到一个 MCP 操作中。一次操作比 3 次操作更好，因为它消除了 LLM 表现错误的可能性。

图 TD 子图 MCP c end client((client))–>cc[do_job]–>start_job c–>poll_status c–>get_result

好的，但为什么一定是 MCP？为什么不能使用 OpenAPI 做同样的事情？

是的，大多数 API 不能直接在 LLM 提示中正常工作，因为它们的设计或记录不完善。

MCP 生态系统中有用于构建服务器和操作、增强文档等的出色工具。因此从表面上看，MCP 似乎是 API 设计和文档方面的进步。

但话又说回来，为什么 OpenAPI 不能同样进步呢？没有技术原因。

事情是这样的。您可以使用 MCP 完成的所有操作也可以使用 OpenAPI 完成。但..

为什么不做呢？在异步 API 的示例中，操作可能需要很长时间，因此它是异步 API。没有任何技术原因可以解释为什么 API 不能花费很长时间。事实上，MCP通过服务器发送事件（SSE）来实现工具调用。 OpenAPI可以代表SSE。

我们不这样做 OpenAPI 的原因是因为工程团队已经习惯于密切关注操作延迟。如果 API 操作花费的时间超过几百毫秒，则应该有人在图表上发现这一点并诊断原因。造成这种情况的原因有很多，但从根本上来说是社会学的。

SSE 是一项较新的技术。当我们测量 SSE 操作的延迟时，我们测量第一个字节的时间。所以它是 100% 可解决的，但异步 API 更熟悉，所以我们就这样做。

MCP 最有力的论据是，做事的方法大多只有一种。

如果您想浪费工程团队一整天的时间，请查找任意 API POST操作并询问，“但这不应该是PUT吗？”您很快就会发现 HTTP 有很多歧义。即使事情很清楚，它们也并不总是能很好地符合我们通常的想法，因此它的实施不一致。

标准主要是社会学的进步。是的，它们关注技术，但它们控制着社会如何与它们互动。 MCP 的最大原因很简单，就是其他人都在这样做。当然，您可以是一个纯粹主义者并要求 OpenAPI 足够，但是有多少客户端支持它？

大家都同意 MCP 的原因是它比 OpenAPI 小得多。 MCP 服务器工具部分中的所有内容都与 OpenAPI 中的其他内容直接同构。事实上，我可以轻松地从openapi.json文件生成 MCP 服务器，反之亦然。但 MCP 比 OpenAPI 规模小得多，而且目标明确。