最近在折腾 MCP,想让本地的 Claude Desktop 连上自己写的一个 server,结果每次调用工具都卡住,最后报 timeout。server 是用 Python SDK 写的,本地 curl 测试接口是通的,但一到 Claude 里就挂。看日志好像请求根本没到 server 那边,也不确定是 stdio 传输的问题还是路径没配对。有没有人遇到过类似情况?是我 config 里 command 写错了,还是 MCP 对 Python 环境有要求?求指点一下排查思路。
MCP 工具调用总是超时,是我哪里配置错了吗?
全部回复
共 8 条我之前也踩过这个坑,大概率是 stdio 启动时环境变量没继承,Claude Desktop 拉起子进程用的 PATH 跟你终端里完全不一样。你试试把 command 写成 python 的绝对路径,别用相对路径或者依赖虚拟环境激活。另外日志里如果连请求都没到 server,基本就是进程根本没起来,可以手动在终端跑一遍 config 里的完整命令看报什么错。
我之前也踩过这个坑,大概率是 stdio 启动时环境变量没继承,Claude Desktop 拉起来的子进程 PATH 跟你终端里不一样,Python 解释器或者依赖根本找不到。建议先在 config 的 command 里写绝对路径,比如 /usr/bin/python3 或者虚拟环境里的那个,别指望它自己找。另外 log 里请求没到 server 基本就是进程没起来,可以手动在终端里用同样的命令跑一下,能复现就说明配置问题。
我之前也踩过这个坑,十有八九是 stdio 启动时用的命令有问题。Claude Desktop 不是在你终端那个环境里跑,它用的是系统默认 PATH,所以你写 python 或者 uv 经常会找不到解释器,得换成绝对路径才行。另外建议手动在终端里按 config 里那串 command 加 args 跑一遍,看能不能正常握手,这样最容易定位是环境问题还是协议问题。还有日志一定要开 MCP_DEBUG,不然真的很难看出请求卡在哪一步。
我之前也踩过这个坑,大概率是 stdio 启动时 Python 环境没对上。你在 config 里写的 command 最好用绝对路径的 python,或者干脆用 uv run,别指望 Claude Desktop 继承你终端里的 venv。还有个隐蔽的点是 server 启动后往 stdout 打印了日志,MCP 会把它当成协议数据直接搞崩,日志记得全丢 stderr。先在终端手动跑一遍同样的 command,看能不能正常握手,能跑通再回 Claude 里试。
我之前也踩过这个坑,八成是 stdio 传输的问题。Claude Desktop 启动 server 时不会走你 shell 的环境变量,Python 路径不对的话进程直接就起不来,日志里自然啥都看不到。建议你在 config 里 command 用 python 的绝对路径,args 里把脚本路径也写全,然后先手动跑一遍那个命令看能不能起来。另外记得在 server 里加点 stderr 日志,不然出错了真的两眼一抹黑。
我之前也踩过这个坑,八成是 stdio 那块的问题。你 config 里 command 如果写的是 python,最好换成绝对路径,比如指向虚拟环境里的 python,不然 Claude Desktop 启动时用的解释器跟你终端里根本不是同一个。还有个容易忽略的点,server 里 print 调试信息会污染 stdio 通道,日志一定要走 stderr。先在 config 里开个 mcp 的 log 看看,一般能看到具体卡在哪一步。
日志里没请求到server,多半是command路径或Python环境没对上,先换成绝对路径试试。
我之前也踩过这个坑,日志里请求没到 server 基本可以排除业务逻辑问题,八成卡在 stdio 启动那一步。Claude Desktop 拉起的 command 得写绝对路径,用 python 的话最好直接指向虚拟环境里的解释器,别指望它认你 shell 里的 PATH。另外 server 启动时如果有任何 print 输出到 stdout,协议直接就乱了,建议先把日志全打到 stderr 试试。