没人讨论新版的 mcp 协议吗，感觉进步很大

在这之前我都直接让智能体走 curl ，发现又快兼容性又好🐶

一版都是你这*，block

@xyooyx 少量单个接口肯定没啥问题的，给终端客户就不太行了

1. 算是个大进步，不过以前连接过一层负载均衡后固定连到一台服务器上，整体上看也没什么大问题
2. 没啥用
3. 没啥用，MCP 不应该是干长任务的，特别有需求的话本来后端也能拆 tool 实现
4. 老版本够用

说到 MCP ，MCP 规范里现在实际只有 tool 在用，resource 、prompt 都已经路边一条了（比如 Claude Code 就不支持 prompt ，国内云厂商的市场基本都是支持 tool ）

@yh7gdiaYW 我们的业务交互流程比较多，第二点还适合我们的。第三点也是我们的特性吧，一些长时间的如导入导出原生支持会很好。第四点权限有用，但又不够用，因为我们会做到字段级的权限

@beautyplus 你这**

MCP Apps：支持交互式 UI
这个还挺重要的，我们现在就被这个困扰，，，，，想 codex 和我们的东西联动，

@Meteora626 是的业务稍微复杂一点就需要交互式 ui ，体验更好

@beautyplus 24 年加入的**,block

@xyooyx 没错 :)

之前的 MCP 也支持交互 UI ，基于 tool calling 实现的

我实际就遇到了 mcp 协议中，想要通过 tools 上传附件的问题，由于只能传字符串，所以没有解决，最后用 skills + curl 的方式了。

现在 skill + api 很方便呀

@novojo 类似于 ChatGPT Apps 吗

@novojo 看了下可以实现更加复杂的逻辑，可以多个组件联动，像微前端

@yh7gdiaYW 我觉得反而很有用， 这几个你是完全割裂来看看了。
这次的升级最核心的就是把 state 消除掉， 从 server 移动到了 client, 从而保证 server 是 stateless ， 从而保证 可扩展性。
1. 你说的 sticky session 可以用，但不可扩展， 一旦 crash 完蛋
2. apps 和 长任务， 都是有状态， 所以在客户端的话， 那么依然是为了 server 的 stateless
3. 企业认证和权限， 显然也很重要

感觉唯一不好的是，apps 居然是 iframe 实现的。。。不过倒不是很大的问题， 毕竟 MCP 说到底是 server ， 如果协议不支持 stateless ， 那么只能压缩 MCP 自己的功能， 让他强制变成 stateless ， 那这样的话，MCP 和 HTTP 没有啥大的本质区别，无非是多了一个 tools schema validation 。。。

MCP Tool 太占用 Token 了，不好渐进式披露，tool_search 也不好用，还是 CLI 好用，--help 可以一点点加载子命令