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

我之前也卡在这过，后来发现是Python环境的问题，Cursor那边用的Python解释器和你自己终端里跑的不是同一个，导致MCP server起是起来了但协议握手没走完。你试试在配置里把python路径写成绝对路径，或者直接指定虚拟环境里的python。另外检查下你的server.py有没有加if name == "main":的入口，有时候直接跑没问题但被当模块调用就怪怪的。name和version字段按理说不是必须的，但加上也没坏处，可以顺手补全试试。

我之前也卡在这过，后来发现是Python环境的问题，Cursor那边用的解释器跟我终端里activate的不是同一个，导致MCP server根本没起来。你试试在配置里直接写死绝对路径的python，或者在server.py开头加个print调试下有没有被调用。另外版本字段最好还是加上，虽然官方说可选，但有些客户端就是会抽风。

我之前也卡在这过，后来发现是Python环境的问题，Cursor用的解释器跟我终端里跑的不是同一个，得在配置里写绝对路径或者直接用which python确认一下。另外你可以试试在服务端代码里加个启动日志，比如print一下注册了哪些工具，看stdio连接时到底有没有加载成功。协议版本倒是不用太担心，官方SDK一般兼容性没问题，反而name和version不是必须的，但补上也没坏处。还有个笨办法，用npx @modelcontextprotocol/inspector单独连一下你的服务器，能直观看到工具列表返回了啥。

之前用Claude Desktop连MCP也遇到过类似情况，后来发现是Python环境没对上，Cursor用的解释器和装mcp库的不是同一个。你可以先在终端跑一下which python和pip show mcp，确认路径一致，再试试直接用绝对路径的python。另外协议版本确实有坑，官方文档说Cursor目前支持到2024-11-05那版，你检查下mcp库版本别太新。还有个笨办法，先跑个官方示例服务器试试，能排除是自己代码的问题。

大概率是Cursor对MCP的初始化握手有严格要求，试试在server里显式声明name和version字段。

我之前也卡这，后来发现得用mcp.run(transport="stdio", name="xxx", version="1.0.0")才正常。

我之前也卡在这过，后来发现是Cursor的MCP配置里必须显式写上--transport stdio参数，光在Python代码里指定没用。另外检查下你的Python环境，如果是虚拟环境，启动命令得用绝对路径指向那个venv里的python，不然工具加载会静默失败。

我之前也卡在这过，后来发现是Cursor要求MCP server在stdio模式下必须显式声明protocol version，你试试在server里加上mcp.run(transport="stdio", protocol_version="2024-11-05")，或者检查下Python SDK版本，太老的话工具列表就是空的。另外如果用了虚拟环境，确保Cursor配置里填的python路径是venv里的那个，不然它可能连的是系统python，模块找不到就静默失败了。我上次就是被路径坑了，换成绝对路径后立马就好。

大概率是Cursor要求MCP走SSE传输，stdio只认本地CLI，你试试配个--transport sse的远程地址。

检查下MCP协议版本，Cursor要0.1.0以上，另外stdio模式必须配name和version字段才行。

遇到过，多半不是协议版本问题，而是stdio握手后Cursor没拿到初始化响应里的工具清单。你可以先单独跑一下python server.py，看启动时有没有打印出类似“Tool registered”的日志，确认工具确实被加载了。另外检查下MCP配置里路径是不是绝对路径，别用~或者相对路径，有时候环境变量没继承会导致Python找不到依赖。还有个坑是Cursor的MCP客户端对listTools的返回格式要求很严格，你试试在server里手动加个server.list_tools()覆盖方法，直接返回硬编码的[{"name": "get_weather", "description": "...", "inputSchema": {...}}]，跳过装饰器逻辑，能通就说明是装饰器生成的schema有问题。我之前就是这么排查出来的，最后发现是pydantic版本太新导致JSON Schema格式不兼容，降级到2.0以下就好了。

我之前搞MCP的时候也卡在这过，后来发现是Cursor只认带name和version的初始化响应，你那个server.py里是不是没写{"jsonrpc": "2.0", "result": {...}, "id": 1}这种握手逻辑？建议先用mcp-inspector单独调试一下，看协议层返回的tools是不是空的，别直接在Cursor里试。另外确认下你用的Cursor版本，老版本对MCP的支持很坑，更新到最新版说不定就好了。

试试在配置里加上--transport stdio显式声明，我之前这么搞就好了，不然容易走默认的sse模式。

我之前用Claude Desktop也遇到过一模一样的坑，折腾半天最后发现是MCP SDK版本和客户端不匹配。Cursor那边对协议版本卡的挺死，尤其是2024年底之后更新的那批客户端，要求MCP协议至少是0.1.0以上，你那个Python SDK如果装的是老版本，就算服务端显示connected，工具发现那一步也会静默失败。建议你先pip list看看mcp包的版本，直接升到最新版试试，我之前从0.9升到1.2就好了。另外name和version字段不是必须的，但如果你用的是新版SDK，那个server对象最好显式给个name，有些客户端会靠这个做缓存键，缺了可能导致工具列表不刷新。还有个排查思路是别用Cursor的GUI配置，直接命令行跑一下mcp dev或者写个临时脚本用client.session去连你的server，看能不能列出来工具，这样能快速定位是server端问题还是Cursor集成的问题。如果本地客户端能列出来，那基本就是Cursor的缓存或者配置路径问题，试试把配置文件里的命令改成绝对路径，别用python，用which python出来的完整路径，有时候环境变量不一致也会这样。

我上周刚踩完这个坑，多半是SDK版本和Cursor要求的协议版本不匹配。你试试把mcp库升到最新版，然后确保server.py里用if __name__ == "__main__":包一下启动逻辑，别在import时直接跑。另外检查下Python环境是不是和Cursor用的同一个解释器，有时候它连的是系统Python但你的包装在虚拟环境里。还有个笨办法，先用mcp dev那个调试工具跑一下，看能不能正常列出工具，能的话再排查Cursor侧的配置。

我之前也卡在这，后来发现是stdio传输时服务器往stdout打了print调试信息，协议被污染了，工具直接加载不出来。你检查下代码里有没有多余的输出，日志统一走stderr。另外Cursor对MCP的初始化握手挺挑的，协议版本对不上也会静默失败。建议先用MCP Inspector单独测一下服务器，通了再接Cursor，能省不少排查时间。