大多数MCP都设计错了！

编辑  | 云昭

出品 | 51CTO技术栈（微信号：blog51cto）

最近 MCP 大火，一个好现象是，各个社区不再讨论“究竟什么是 MCP”、“MCP 与 A2A 区别是什么”这种概念性的问题了。也算是从炒作期开始正式进入实干期了。 

不过，话说回来，虽然很多厂家都宣称自己的产品接入了 MCP，但市面上构建的 MCP 水平如何？真的靠谱吗？

今天就分享一篇有关 MCP 服务器真实构建现状的干货。

一、大多数MCP服务器都是错建的

前两周，在逛 Reddit 时，发现了一个“火药味”十足的炮轰现在 MCP 的帖子。

“大多数 MCP 服务器都是错建的。”一位昵称为“incidentjustice”的网友称。

图片

太多初创公司在构建 MCP 服务器时，只是简单地把现有 API 包一包，就当任务完成了。这完全是本末倒置。

这位网友对于这种质量不合格的“急功近利”行为表示愤怒：

这些构建者简直不清楚 MCP 服务器该包含哪些内容！MCP 不仅仅是一个协议封装器，它是一份“设计契约”——规范了大模型该如何与你的系统交互。

如果你的服务器只是丢原始数据给 LLM，而不考虑上下文限制、切片、数据相关性，那它基本没用。一个好的 MCP 服务器应当只暴露所需内容，并提供合适的过滤、搜索和摘要机制。

他具体指出问题所在，“这不是在讲‘访问权限’，而是在说‘可用的、具上下文感知的访问’。”

很快，就有网友表示自己也越到了太多“鸡肋”一样的 MCP。他认为，很多数据库 MCP 就是这样：大多数只是暴露了一个简单的查询工具，完全没有上下文信息，也帮不了 Agent 去理解表结构或数据关系。

图片

不止，其实还有很多人持这样的观点。

图片

二、MCP ≠ 描述 + API

一位经常为各种场景构建 MCP 服务器的开发者 Tiemensma 最近分析了这种现象，并指出：

这种做法的结果，最多是“勉强能用”，最坏的情况是根本跑不通。

我经常看到的一个错误是：直接拿现有的 API，加点描述，然后就声称构建了一个 MCP 服务器。这种方式在 Glama、Smithery 等网站上的 MCP 工具中很常见，但效果往往平平，甚至彻底失败。

我做 MCP 服务器已经有一段时间了，想分享一些我的经验。我们真的该停止把 MCP 当作“带有更好描述的 API”来看待了。因为模型与工具的交互方式，和传统 API 的设计初衷之间，差异实在太大。

问题的根源在于：

API 是为人类开发者设计的，而 MCP 是为 AI 模型设计的。

开发者可以查文档、试错、积累经验记忆，逐步理解系统。而 AI 模型没有长期记忆，它只能根据「当前的自然语言请求」瞬间判断出该用哪个工具、怎么组合使用。

而就在这个调用发生的瞬间，存在一个巨大的机会，恰恰很多 MCP 服务器并没有利用好：通过把工具的响应设计为新的提示，来引导模型往正确方向走。

三、API 直转 MCP 的两个常见坑

如果你让大模型直接用 API 样式的 MCP，就会造成两个最直观的坑——

1. Token 膨胀

一个工具的 JSON schema 通常就要 50100 个 token，加上描述再来 200，多参数每个还要 2050。一个拥有 80 个端点的 API，只是定义 MCP 工具，就得用掉约 24,000 个 token。也就是说，模型还没开始用，就被 token 限制卡住了。

2. 概念混淆

API 中的术语对开发者有意义，但对模型极为混乱。

比如： “resource” vs “entity” vs “object”？

“community_members” 和 “space_members” 有啥区别？

模型根本没有这些概念上下文，结果就是一脸懵。

所以，Tiemensma 认为：优秀的 MCP 设计，是把每一次工具响应都当作“提示模型”的机会。

四、案例反思：MCP应该围绕用户意图来设计，而非API端点

Tiemensma 此前做过一个 Agent 的项目，是用来辅助管理 Circle.so 社区的。“我当时开放了一半的 API 端点给它通过函数调用使用，但始终表现不稳定。最近我重新思考了一下，如果是现在，我会怎么重新设计。”

一个很典型的用例是：获取用户活跃度信息。旧的 API 式做法是：让模型先调用 ​​get_members​​，然后再对每个成员分别调用 ​​get_member_activity​​、​​get_member_posts​​ 等等。这种方式既笨重、又耗费大量 token，而且很容易出错。

而意图导向的设计则是：创建一个叫做 ​​getSpaceActivity​​ 的工具，由服务端完成所有操作，并返回一个简洁而丰富的对象。

当你有了一个优秀的、以意图为中心的工具后，接下来的问题就是：你如何描述它。模型需要知道何时使用它、如何使用它。我发现，在工具描述中加入简单的 XML 标签非常有效，能清晰地区分“用途”和“使用方法”：

复制

<usecase>Retrieves member activity for a space, including posts, comments, and last active date. Useful for tracking activity of users.</usecase>
<instructions>Returns members sorted by total activity. Includes last 30 days by default.</instructions>

关键在于，把每一个响应都当成是一次提示模型的机会。模型不会记住 API 的流程，因此你必须每次都用响应来“提醒”它。一个好的响应，不仅仅是返回数据，还应该引导模型进行下一步合理操作，比如：

“已找到 25 位活跃成员。可使用 ​​bulkMessage()​​ 工具与他们联系。”

这在错误响应中尤为关键。一个典型案例是 Supabase 的 MCP。我曾在 Claude 4 Opus 上使用过，它有时候会“幻想”出一个 ​​project_id​​。当模型使用一个虚构的 ​​project_id​​ 调用工具时，MCP 返回：

复制

{"error": "Unauthorized"}

这个响应技术上没错，但完全没帮助。它让模型误以为自己没有权限，从而直接“卡死”。

注意：错误信息，就是当下的文档，它必须具备“教育性”。更好的响应应该是：

复制

{"error": "Project ID 'proj_abc123' not found or you lack permissions. To see available projects, use the listProjects() tool."}

这会告诉模型为什么出错，以及接下来该怎么做。

这样的机制还能减少初始 prompt 的冗余。如果模型在 90% 的情况下都能正确调用工具，而在出错时也能靠好错误提示迅速纠正，就没必要在最初的描述中穷举每一个边缘情况。

五、转变思路：不要站在“开发者”的角度设计 MCP

其实，相信很多开发者最初做 MCP 工具时都会犯了这个错：习惯用 API 的最佳实践去设计，因为这样做非常符合程序员的审美：模块化、干净、职责分离……

可事实证明：AI 根本不是按这种方式“思考”的。以下才是对模型真正重要的事：

1. 以“用户意图”为核心，不是“API 操作”

别再以系统结构来定义工具，要从“用户想完成什么事”出发。

2. 每个响应都引导下一步

模型是无状态的，响应不能只说“操作成功”，而是要告诉模型“接下来做什么”。

这里注意：不仅是错误提示，每一次返回都可以嵌入“下一步指令”。

例如，在搜索结果中返回：

“Found 5 results. Use getDetails() for full information.”

这样模型就知道怎么继续，不用你再解释一堆流程。

3. 信息要有，但不能啰嗦

模型不能看文档，所以你要把该讲的讲清楚。但 token 是有限的，必须“聪明压缩”信息，比如用分页、简明描述等方式。

PS：这里有一个反直觉的经验：描述不是越详细越好。

真正有效的 MCP 描述，往往是结构化描述 + 高质量的错误提示引导。这样做的目标，不是“覆盖一切”，而是“90% 情况下能走对”。

推荐下面两段式的描述结构：

复制

<usecase>
这个工具是做什么的、什么时候该用它
</usecase>

<instructions>
具体该怎么用
</instructions>

这样模型可以先判断这个工具是否相关，然后再读细节。

此外，Tiemensma 还给出了一个写描述的 90/10 原则：把复杂留给错误提示。

与其预先写一大段字段和格式要求，不如只给出必要信息，其它靠错误提示动态引导。

例如：

如果模型漏填 ID，你可以返回这样的错误："No ID provided for update. Use searchRecords() to find record IDs."

比起事前讲一堆规则，这种方式更有效，也省 token。

4. 一个小技巧：做 MCP 工具时的合并策略

既不要把每个 API 端点都做成一个 MCP 工具（太碎），也不要所有操作塞进一个大工具（太复杂）。而应该：

（1）按“用户意图”来归类。比如发送消息、查询成员、获取活跃度等。

（2）分开那些风险高的操作（如删除、更新）——可以要求审批或限制模型调用。

六、网友：好了，现在又多了一个 MCP 需要维护！

以上，就是这些 MCP 服务器的构建方法。可以看出，现在许多 MCP 的构建水分还是很大的。有归有，但实际使用还有很大的问题要处理。

一位 Reddit 网友表示：

我现在的挣扎点是，我是不是要预判所有针对自定义数据集的使用场景？直接包装 API 很简单，但现在还要维护数据库、API、前端和 MCP，这会不会太复杂了？

即便是只维护 MCP 服务器，也有网友表示很繁琐：

MCP 协议为啥不允许对整个服务器进行描述？现在只支持 per-tool 的描述。比如多个工具都要接收 file path，那路径格式描述每个工具都得写一遍，太低效了。

如果 MCP 工具的使用思路不够直观，即便底层做得再好，LLM 也很难用起来。除了逐个工具的描述外，能不能有一段全局的指引或 prompt？

不过有一点可以确定，MCP server 的构建已经日益流行。大家应该摒弃 API 包装器的思维，而需要将其视为一种“全新应用形态”来设计。

毕竟，它应该是为一个有能力的、多模态的大模型或“智能体”来构建的接口，否则就很容易成为流于形式、徒有其表的噱头了。

本篇文章到此结束，剩下的内容交由评论区的各位大佬发表看法了。周末愉快～

参考链接：

https://www.reddit.com/r/mcp/comments/1lhws59/most_mcp_servers_are_built_wrong/

本文转载自​​​51CTO技术栈​​​，作者：云昭