MCP服务器接入Cursor后工具列表是空的，有人遇到过吗？

我上周刚踩过这个坑，折腾了半天发现是Cursor对MCP的初始化握手有缓存，尤其是stdio模式，改完配置必须完全重启Cursor（不是重载窗口，是彻底退出进程），不然工具列表就是空的。另外你确认下Python环境变量对不对，有时候Cursor用的Python解释器和你的不是同一个，导致MCP服务虽然连上了但工具注册失败。还有个小坑，老版本Cursor不支持工具名带下划线，你那个get_weather按理说没问题，但可以试试改成小驼峰命名看看。实在不行就用npx跑一个官方的example server排除是不是自己代码的问题。

大概率是协议版本不匹配，我之前用fastmcp也这样，换成sse transport或者降级到0.1.x就正常了。

大概率是MCP的protocol version对不上，Cursor目前只支持特定版本，你检查下SDK版本和handshake的兼容性。

我之前遇到过类似情况，把mcp库升级到最新版，然后确保server里显式声明name和version字段就好了。

八成是MCP版本不匹配，我用fastmcp重写一遍就好了，官方SDK跟Cursor兼容有点迷。

我之前也卡在这过，后来发现是Cursor用的MCP SDK版本比较老，对协议里有些字段校验特别严格。你试试在server.py里显式加上name和version，最好再声明一下tools列表，别依赖装饰器自动注册。另外检查下stdio的日志输出，如果有print语句混进去也会导致解析失败，工具列表直接空白。

这问题我上周刚趟完，八成不是协议版本的事，Cursor对MCP的stdio支持其实挺宽松的。你试试在终端手动跑一下python /path/to/server.py，看能不能正常输出一次握手响应，我猜你本地环境里Python路径跟Cursor调用的不是同一个解释器，比如用了虚拟环境但配置里写的是全局python。另外@mcp.tool()装饰器没问题，但如果你用的是最新版MCP SDK，初始化Server对象时必须显式传name和version，这俩字段缺失会导致工具注册静默失败，日志里还看不出啥。我之前就是卡在这，加上Server("demo", version="0.1.0")后立马就好了。还有个坑是工具函数名不能跟Python关键字冲突，比如叫list或id，Cursor解析时会直接跳过。你检查下工具函数里有没有用asyncio事件循环，如果server在启动时阻塞了主线程，工具枚举请求就会超时，表现就是connected但list为空。实在不行开个--debug日志，把MCP的JSON-RPC消息打到文件里，看客户端发没发tools/list请求，以及你的响应体里tools字段是不是空数组。我最后是靠看原始通信消息定位到是返回格式里少了inputSchema，补上就全出来了。

我之前也碰到过一模一样的情况，折腾半天发现是Python环境的问题，Cursor那边用的解释器和本地终端的不一样，导致包没装上。你试试在MCP配置里直接用绝对路径指向venv里的python，别用系统默认的。另外检查下mcp库版本，太旧的话协议对不上也会这样，我升级到最新版就好了。

我之前也栽在过这个坑里，折腾了整整一个周末，最后发现是Python环境的问题。你本地命令行里能跑通不代表Cursor能调用到同一个解释器，特别是如果你用了conda或者pyenv，Cursor默认走的可能是系统python，你那个MCP server依赖的包压根没装进去。建议你先在终端里手动跑一下python /path/to/server.py确认能正常打印出启动日志，然后在Cursor的配置里把python路径换成绝对路径，比如/usr/local/bin/python3或者conda环境的完整路径。另外，你提到日志没报错，但工具列表空，我怀疑是stdio握手阶段卡住了——可以试试在server.py里加一行print("MCP server started", flush=True)，看看Cursor的输出面板有没有这个信息。至于协议版本，我记得Cursor目前支持的是2024-11-05这个版本，如果你的mcp库太新可能会默认发2025-03-26的协议头，导致服务端和客户端不兼容。我后来是把mcp库降级到1.2.*版本才稳定工作的。还有个小细节，@mcp.tool()装饰器的函数名最好和工具名一致，别用下划线开头，我之前因为函数名带了个下划线，工具就神秘消失了。你先试试环境变量和绝对路径这两招，大概率能解决。

我之前也卡在这过，后来发现是Python环境的问题，Cursor用的解释器和咱们终端里那个不是同一个，你试试在配置里直接写绝对路径的python，或者用which python看看路径对不对。另外stdio传输的话，建议先开个终端手动跑一下server.py，确认没有因为缺少依赖或者编码问题在启动时就崩了，connected但工具为空多半是握手失败了。MCP协议版本倒不用太担心，主流版本都兼容，但记得在server里显式加上name和version，有的客户端会严格校验这两个字段。

我之前也卡在这过，后来发现是Cursor对MCP的初始化握手要求比较严格，特别是name和version字段缺一不可，你试试在server里显式加上server = Server("weather-server")再配个version，大概率能解决。另外工具列表空还有个坑是stdio模式下的日志输出会污染协议，你那个print调试信息全得去掉，不然协议解析会中断但又不报错。我上次就是被一行print卡了两小时，换成logging到文件才看出来。如果还不行，检查下Cursor版本，旧版对MCP支持有bug，更新到最新版试试。

我之前也卡在这过，后来发现是Cursor对MCP的初始化握手比较严格，光有工具定义不够，还得在server里显式返回server info，name和version字段确实不能少。你可以先用mcp CLI单独跑一下，看能不能正常列出tools，如果能列出来但Cursor还是空的，试试把stdio的编码强制设成utf-8，有时候Windows下Python默认编码会出这种怪问题。另外检查下Python环境是不是用了虚拟环境，Cursor那边路径得指向同一个解释器，不然模块加载不到也会静默失败。

我之前也卡在这过，后来发现是Python环境的问题，Cursor那边用的解释器跟我终端里activate的不是同一个，工具就加载不出来。你试试在配置里直接写绝对路径到venv里的python，别用系统默认的。另外协议版本倒不是关键，但name和version确实得补上，有些客户端会校验这个，缺了就直接静默失败。日志没报错的话，可以自己写个client连一下stdio接口，看能不能正常list tools，先排除服务端问题。

我之前也被这个坑过，大概率不是协议版本问题，而是Cursor读取工具列表的时候需要MCP server输出严格的初始化响应。你试试在server启动时打印一下{"jsonrpc": "2.0", "result": {...}}，看下是否带了capabilities字段，特别是tools部分。另外，@mcp.tool()装饰器在最新SDK里可能要求显式声明name参数，不然工具名会解析成空字符串。我之前就是漏了这个，连错误日志都不给，直接静默失败。你可以先用mcp dev跑一下看是否正常，排除是Cursor端缓存的问题。

我之前也卡在这好久，后来发现是Python环境的问题，Cursor那边默认用的python可能不是你装了mcp库的那个。你试试在配置里写全绝对路径，比如/usr/bin/python3 /path/to/server.py，或者直接用which python查一下路径填进去。

另外stdio模式下建议把server里的print都去掉，或者重定向到stderr，不然输出混进协议流里工具列表也会是空的。协议版本的话，最新版的Cursor应该兼容1.0，你那个mcp库版本也得跟上，太旧了容易出这种玄学问题。

我之前也遇到过类似问题，后来换了方案。

协议版本这块确实容易踩坑，建议先查下MCP SDK版本和Cursor支持的版本对不对得上。

我之前也遇到过，后来发现是少了name和version字段，加上再重启下就正常了。

我之前也卡在这过，后来发现是Cursor的MCP配置里command和args要分开填，不能写成一条python /path/to/server.py，得拆成command是python，args是路径数组。另外你试试在server.py里加个if __name__ == "__main__":再调mcp.run，有时候直接跑会不走协议握手。还有个坑是别用新版mcp库，降到0.9.x试试，新版协议版本和Cursor不兼容。

我上次也这样，后来发现是Python环境变量没对上，试试在配置里写绝对路径的python解释器。

我也遇过一模一样的情况，折腾半天最后发现是Python环境的问题，Cursor那边默认用的解释器跟你终端里跑的不是同一个。你试试在MCP配置里直接写绝对路径的python，比如/usr/bin/python3或者conda环境的完整路径，有时候工具加载失败就是静默的。另外你可以先用mcp dev那个调试工具单独测一下server，能正常列出工具就说明是Cursor这边解析的问题，顺便确认下MCP SDK版本别太新，有些版本跟Cursor的兼容性确实有坑。

我上周也卡在这，后来发现是Cursor的MCP客户端默认走的是SSE协议，stdio模式虽然显示connected但工具发现那步根本没触发。你可以试试在配置里加个--transport sse，或者直接换成本地HTTP服务。另外检查下Python环境，Cursor有时候用的是自己的虚拟环境，你本地装的mcp库它压根没引用到。

我之前遇到过类似的，最后发现是JSON-RPC的初始化握手没完成。你可以在server.py里加个日志打印，看看有没有收到initialize请求，如果没收到那就是协议版本不匹配。Cursor现在好像强制要求MCP用2024-11-05那个协议版本，你检查下mcp库版本，太老的话工具列表就是空的。

工具列表空多半是list_tools响应格式不对，Cursor对返回的JSON schema要求很严格，比如inputSchema必须是个object类型。你直接打印一下自己返回的原始数据看看，如果少了properties字段或者类型写错了，它就直接当空处理。我之前就是漏了"type": "object"这行卡了一晚上。

我也是被这个坑过，后来发现是Cursor的MCP配置里执行路径不能带引号，你把python /path/to/server.py改成绝对路径的python解释器试试，比如/usr/bin/python3 /path/to/server.py。另外确认下server.py