MCP对接Cursor后，Agent总是调用失败，是我配置姿势不对吗？

大概率是Cursor对SSE的支持有坑，试试把transport换成streamable-http，新版SDK都推这个。

说实话你这套组合我上个月也踩过类似的坑，最后发现大概率不是配置姿势的问题，而是Cursor侧对MCP长连接的管理太粗暴了。FastMCP默认的stdio模式在Agent每次工具调用后，如果进程没完全退出，Cursor就会判定连接异常，我后来强制在服务端加了asyncio的task超时清理才稳定点。你试试把transport换成sse后，确认下服务端是不是真的在推事件流，Cursor的sse实现其实对heartbeat间隔特别敏感，默认的15秒可能刚好卡在它的超时边界上。另外0.45.x这个版本我记得对MCP的tool schema校验有bug，特别是参数里带optional字段时容易直接断连，建议先降级到0.43.x或者升级到最新0.46+看看。日志没报错不代表没问题，我建议你开DEBUG级别抓一下Cursor自己进程的网络输出，有时候错误被吞在它的内部worker里了。版本匹配的话，MCP SDK 1.2.0跟Cursor 0.45确实有已知的协议兼容问题，官方issue里有人提过，主要是initialize请求里的protocolVersion协商不一致。你不如换个思路，先本地写个最小demo只暴露一个无参数工具，排除是工具定义太复杂导致的序列化问题，一步步加复杂度。

我之前也踩过这个坑，后来发现是Cursor那边对stdio的启动命令解析有点问题，路径里带空格或者用了虚拟环境的相对路径就容易连不上。你试试把Python解释器和脚本都写成绝对路径，命令参数拆开单独填，别一股脑塞一行里。另外SDK 1.2.0跟0.45.x的Cursor确实有过兼容问题，可以降到1.1.x或者升级Cursor试试，我升到0.46后stdio就稳多了。

我上周也这样，把MCP SDK降到1.0.0就通了，版本兼容确实有坑。

我之前也踩过这个坑，Cursor 0.45.x 对MCP的SSE支持确实有点拉胯，stdio反而更稳一点。你试试把FastMCP的启动命令写成绝对路径，别用相对路径，Cursor有时候工作目录不对就静默挂了。另外SDK 1.2.0和这个版本的Cursor好像有个握手超时的小bug，降级到1.1.x会好很多。日志的话建议开MCP的debug模式看下stderr，光看Cursor那边基本看不出啥。

Cursor 0.45 的 MCP 确实有点抽风，我升到 0.46 后 stdio 就稳了，你试试降级 SDK 到 1.1.x 看看。

我之前也踩过差不多的坑，后来发现是Cursor那边对stdio模式下的进程启动路径挺敏感的，稍微有点环境变量差异就会静默断连。你可以在MCP配置里把command写成绝对路径，再手动加上cwd参数试试看。另外1.2.0的SDK跟0.45.x确实有几个已知的兼容问题，升级到最新版可能会好点。