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

我之前也卡过这个，后来发现是Cursor读的是全局配置，不是项目里那个，改完重启才生效。你确认下~/.cursor/mcp.json里的路径是不是绝对路径，相对路径它经常解析不到。另外stdio模式下服务器千万不要往stdout打日志，会污染协议握手，工具列表就出不来了，日志走stderr试试。

我之前也踩过这个坑，折腾半天发现是Cursor读的配置路径和我改的文件不是同一个，白忙活。你可以在MCP设置面板里点开那个服务器的日志，看看有没有初始化时的握手信息，空列表一般是initialize没走通。另外确认下你Python环境里mcp包版本和Cursor内置的协议对不对得上，版本差太多会静默失败。还有个偏方，把命令写成绝对路径的python加上参数分开填，有时候它解析带空格的路径会出问题。

我前两天也踩了这个坑，折腾一晚上才发现是 stdio 传输下 print 输出污染了协议流。你服务器里是不是有 print 调试语句或者日志默认输出到 stdout 了？MCP 的 stdio 通道是走标准输入输出的 JSON-RPC，任何多余的输出都会让 Cursor 解析失败，但连接状态又显示正常，特别迷惑。建议把所有调试信息改成写 stderr 或者用 logging 输出到文件，再试一次。另外 Cursor 目前对 MCP 协议的初始化握手比较严格，服务端返回的 serverInfo 里 name 和 version 最好都带上，虽然理论上可选，但缺了有时候确实会静默失败。还有个小细节，配置里最好写绝对路径的 python 解释器，别用系统默认的 python，虚拟环境没激活的话依赖导入失败也是悄无声息的。你可以先在终端手动跑一下服务，然后手敲一个 initialize 请求看返回，这样能快速定位是服务端问题还是 Cursor 侧的问题。

我之前也卡在这个点上，状态显示connected但工具死活不出来，最后发现是Python环境的问题。你配置里写的是python /path/to/server.py，这个python是系统默认的还是你装mcp那个虚拟环境里的？Cursor启动服务器时用的环境很可能跟你终端里跑的不一样，如果mcp包装在venv里而系统python没装，进程能起来但工具注册直接静默失败。建议换成虚拟环境里python的绝对路径试试，比如/path/to/venv/bin/python /path/to/server.py。另外stdio模式下你在代码里print任何东西都可能污染协议通信，检查下有没有调试输出没删干净。还有个小坑是Cursor这边工具列表加载有缓存，改完配置最好完全重启一下客户端而不是只点refresh。如果这些都排除了，可以在服务器启动时往stderr打点日志确认initialize请求到底有没有进来。

我之前也踩过这个坑，connected但工具列表空，大概率是stdio模式下你的脚本往stdout打了别的东西，比如print或者日志，把JSON-RPC的握手消息给污染了。你可以把日志全改成写stderr，stdout只留给协议通信，试试看能不能刷出来。另外Cursor的MCP配置里最好把command和args分开写，别直接塞一整行python /path/to/server.py，有时候解析会出问题。

这个问题我上个月刚踩过，大概率是stdio模式下日志输出污染了协议通道。检查一下你的server.py里有没有print语句或者logging默认打到stdout，MCP走stdio时任何非协议输出都会让Cursor解析失败，工具列表自然就是空的。把日志全部重定向到stderr，或者用logging.basicConfig(stream=sys.stderr)试试看。另外Cursor的MCP配置里command和args要分开写，别把python和路径塞一个字符串里。

我之前也卡过这个，后来发现是Cursor读的是配置文件里的command字段，得把python换成绝对路径，比如/usr/bin/python3，不然它启动的可能是另一个环境。另外你的server.py里如果用了if __name__ == "__main__":记得确认mcp.run确实被调到了，我之前缩进错了导致根本没跑起来。还有个坑是Cursor的MCP面板有时候不会自动刷新，改完配置得把Cursor完全退出重开才行。