背景 在 MCP 出现之前，我也会用外部工具增强 AI 的能力。比如我开发了一个助手 bot ，开发和使用流程如下：
在 python 里定义一些工具函数（比如生成图片或下载文件等）。 当用户向 bot 发送文本时，bot 把工具的描述和用户文案给到 AI ，让 AI 判断需要调用哪个工具。 当工具执行完后，再将执行结果发给 AI ，让 AI 决定是继续调用工具、还是向用户输出结果。
这套流程只能说在我的场景勉强够用，问题主要有两个：
工具函数不够通用，只能在这个 bot 里使用 对话都在一个 bot 聊天框里完成，上下文管理让人头疼
MCP 的愿景 虽然 MCP 出来有一段时间了，但昨天才真正开始上手使用，用的公司内部工具。首次使用时 MCP 给我的愿景还挺好的：我只需要维护工具函数的代码，就可以在各种客户端（ cluade desktop/cusor 等）中复用，甚至共享给其他人，看起来很好解决了我上面的两个问题。 今晚和昨天我重点关注 MCP 服务器的开发、MCP 客户端的体验，也在过程中碰到了不少槽点，在此记录一下。
- 协议交互
OpenWebUI 没有选择标准 MCP 协议，而是特立独行自创了一套 OpenAPI 的协议。虽然可以用 mcpo 命令很容易地转换，但这也增加了部署和理解成本。转换后每个工具函数还被加上了_post 后缀，强迫症震怒。 sse 协议下，MCP 服务器重启后 MCP 客户端也要跟着重启，否则下次调用工具函数时就会报错
- 工具函数 to AI MCP 协议主要定义了 client 和 server 的交互。client 在获取到工具函数后如何传递给 AI ，这各软件各显神通了。
trae 海外版隐藏了提示词，但有意思的是，使用官方模型能很顺利调用 MCP 的工具函数；但如果是填写 key 、调用第三方的模型（甚至是火山引擎），AI 就基本无法感知用户的输入和工具函数，开始胡言乱语。可能是提示词设计的问题。 cline/roo code 等插件，将 MCP 的工具函数塞到自己本来就已经很长的提示词（ 10k+ tokens!）里了，可能会导致AI 优先使用内置的工具。当然这点可以通过提示词强调优先使用 MCP 、或切换 roo code 的模式来缓解。 OpenWebUI 又特立独行，每次对话时会先根据少量上下文和用户输入让 AI 决定是否调用工具函数。如果没有调用工具、或工具调用结束，AI 是感知不到工具函数的。也就是说，如果你问 AI 当前有哪些工具、或者某个工具的参数是什么，AI 是回答不出来的。
另外，cline/roo code 和 AI 交互用的是 xml 格式 prompt ，OpenWebUI 用的是 json 格式 prompt ，反正都不是大模型标准的 tools 格式哈哈。 3. 上下文管理 这一部分槽点也较少。不过点名批评 OpenWebUI ，由于工具的调用判断是单独的链路，所以就会出现很多奇特现象：
你无法向 AI 询问当前有哪些工具，或者工具的参数定义 工具调用完成后，AI 就感知不到工具了。导致无法实现“用户提问 -> AI 调用工具 1 -> AI 基于工具 1 的结果调用工具 2 -> AI 给用户结果“的链式调用。 工具调用完成后，AI 调用工具的参数、工具的返回值都不会记录在对话上下文里。虽然用户可以看到这些内容，但 AI 是永远不会知道了……
相比之下，cline/root code 都是将全量信息记录在上下文里，使用起来顺畅很多。 4. 用户界面和其它
trae 海外版，前端明显有 bug ，看不到工具函数的返回值，只能按复制按钮把返回值粘贴到其它地方看。 cline ，工具函数的返回值没法折叠。roo code 也不支持折叠，甚至还不支持在对话框里展示图片内容。 OpenWebUI 在处理 json 数据（工具函数定义/展示参数、响应）时，会用 unicode 格式（/uffff ）处理，可读性基本没有。 ChatGPTNextWeb 宣称 v2.16 支持了 MCP ，但我启动 v2.16 的 docker 镜像后，前端显示依然是 v2.15 版本，也不支持 MCP……你赢了 网页版本 Claude 我能正常使用，但 Claude Desktop 提示我 APP 不可用。
总结 MCP （或者说用通用协议来增强 AI 对真实世界的感知和操作能力）确实是一个非常有潜力的技术。但它太新了、协议覆盖的范围也太小了，业界还没有一个如何用好 MCP 的最佳实践。当然也有可能是我太穷了，说不定直接用 cursor 就没啥问题了（ 希望不久的将来，有完善的 MCP 客户端和成熟的 MCP 生态，能让每个人都能用上便捷好用的 AI 和工具。