构建 MCP 的 16 个层级

📢 本文同步发布於公众号：Power Platform · 最佳实践
🔗 原文链接：https://johnliu.net/blog/16-levels-of-building-an-mcp/

如何驾驭一个会产生幻觉的天才？

构建 MCP 服务器是有层级之分的。

一开始，它看起来简直太简单了——你有一个 REST API，把每个端点包装成一个 MCP 工具，让 agent 指向它，agent 调用工具，然后一些有用的事情就发生了。

接着你惊恐地看着 agent 自信满满地选错了工具、传错了参数、忘记了你在五分钟前才告诉它的事情，然后你意识到这不仅仅是一个集成问题。

这是一个接口设计问题。

MCP 不仅仅是调用 API 的传输通道。它是确定性软件系统与非确定性 agent 之间的桥梁——这些 agent 不像人类那样思考，不像人类那样阅读文档，也不总能记住你希望它们记住的那部分上下文。

以下是我目前构建 MCP 服务器的阶梯。用阶梯来比喻其实不太准确，它更像是一个 RPG 角色在升级。你解锁一个能力，发现之前的选择是错的，重新分配几个工具的技能点，然后不断变得更好。

抱歉这个列表最后变得这么长。也许把它当作一份清单，对照你自己的经验来检查会更好。你可以随时让一个 agent 来总结这篇文章，并与你的项目进行对比。

Level 0：你有一个 API 或 CLI

❌ 不要：把 API、CLI 和 MCP 当作同一接口的不同传输方式。

✅ 要：保留 API 给确定性软件用，CLI 给人类和 agent 用，MCP 专门给 agent 用。

在 MCP 之前，通常已经有了一些东西。也许是一个 REST API，也许是一个 CLI，也许是一堆只有某位资深工程师才知道如何安全运行的脚本。那一层仍然很重要。当另一个系统已经确切知道自己想要什么时，直接调用 API 是很好的选择。

CLI 又不一样。你是在为人类写作，而且越来越多地也在为 agent 写作。人类想要可读的命令、帮助信息、示例、管道、标志和良好的终端输出。Agent 也可以使用这些。

但当你编写 MCP 时，你只是在为 agent 写作。

人类从中受益。人类可能通过它来批准操作。人类可能看到一个 MCP App。但接口本身是给 agent 用的。

MCP 不会取代 API 或 CLI。当调用方是一个需要发现能力、结构化信息、安全性和引导的 agent 时，MCP 位于它们之上。

你要 100% 专注于构建最优秀、最专用的 agent 接口，来让用户惊叹。每一次都是如此。

如果你把 MCP 当作又一个 API 客户端来构建，你会过早停下。MCP 从来不是构建一次、部署完就忘记的东西。

❌ 不要：暴露每一个端点，然后就说完成了。

✅ 要：从小处着手，然后把 schema、参数、示例和返回结构当作 agent 的用户体验来对待。

这是我们大多数人起步的地方。而且这是一个好的开始。

你把每个 REST 端点暴露为一个工具：

你学会了脚手架。你看到 agent 发现工具、调用工具、处理结构化输入/输出。

然后你看着 agent 读取这些工具，不知怎么地选错了。它编辑了本不该编辑的东西……