最近在折腾MCP(模型上下文协议),想把本地部署的Qwen2.5接进Claude Desktop当工具用。我按教程写了个最简单的stdio server,用Python的mcp库起的,模型走的是Ollama的API。现在问题是:Claude那边一调用工具就报“connection timed out”,但我在终端里直接跑server脚本,curl一下Ollama的接口是通的,延迟也就几十毫秒。
MCP服务器连本地大模型总是超时,是配置问题还是我姿势不对?
全部回复
共 3 条我之前也栽在过这个坑里,大概率不是Ollama的问题,而是stdio server那边没有正确把请求转发出去。你试试把server脚本里的stdin/stdout缓冲关掉,或者用--no-buffer跑一下,还有就是确认Claude Desktop的MCP配置里command路径是不是写全了,有时候它找不到python环境也会超时。
另外你curl测的是HTTP,但MCP走的是子进程管道,两边网络栈完全不一样,不能直接类比。建议在server代码里加个日志打点,看看Claude的请求到底有没有进到你的脚本里,如果连日志都没输出,那八成是MCP握手阶段就断了。
我之前把Ollama的host从localhost改成127.0.0.1,再把server的timeout调大到30秒,莫名就好了,你试试这两个方向。
我猜大概率是stdio server的握手方式跟Claude Desktop那边不兼容,尤其是超时时间设得太短了。Ollama虽然响应快,但MCP初始化时要先做能力协商,这步如果卡住就会直接掐断连接。你可以试试把server的启动日志打到文件里,看看是卡在transport层还是tool调用层,另外确认下Claude Desktop的node版本和Python环境是不是匹配,我之前遇到过类似问题就是环境变量没传进去。
我刚开始搞MCP也踩过这个坑,大概率不是Ollama的问题,而是stdio server的启动方式不对。Claude Desktop调用的时候会拿它自己的环境变量去跑你的Python脚本,如果你用了venv或者conda,路径对不上就很容易超时。你试试在配置里写死python的绝对路径,或者先确认下server有没有真的被拉起,我那时候就是卡在这。另外也可以看看日志,MCP的stderr输出有时候会直接吞掉,但错误信息其实都写在里面。