MCP 工具调用总是超时，是我的配置有问题还是模型本身就这样？

我这边也卡过，后来发现是文件监听太多目录拖慢了响应，建议先精简下映射路径试试。

我之前也碰到过类似的情况，后来发现是 filesystem server 默认会对整个目录做递归扫描，哪怕你换了个小目录，只要里面 node_modules 没排除，一样卡到爆。建议在配置里加上 ignore 规则，把 .git、node_modules 这些直接屏蔽掉试试。另外 MCP 的超时其实是客户端侧控制的，Claude Desktop 这边好像默认 60 秒左右就会断，server 如果还在跑也没用。你可以先手动跑一下 server 用 curl 或者命令行调一次工具，看看到底是响应慢还是根本没返回。

我前段时间也踩过这个坑，后来发现不一定是配置的问题。Claude Desktop 那边其实有个隐性的工具调用等待窗口，server 响应稍微一慢就容易触发超时，官方 filesystem server 在大目录下遍历文件确实会拖时间。你可以先试试把目录缩到只有几个文件，看还超不超时，这样能区分是 server 慢还是客户端等不及。另外换个第三方实现的 filesystem MCP 有时反而更稳，官方那个在某些系统上 IO 处理确实一般。

我之前也碰到过类似的情况，后来发现是 MCP 的 stdio 传输方式下，客户端等的是 server 走完整个 JSON-RPC 往返，目录一深文件一多，光遍历目录就够呛。你可以试试在 server 启动参数里把允许访问的路径收窄，别让它递归扫整个项目。另外超时不一定在客户端，Claude Desktop 那边日志不太透明，建议先用 mcp inspector 单独跑一下 server，看单次 tools/call 实际耗时多少，心里就有数了。

我也碰到过类似的情况，不过我是接的自己的 server，排查下来发现跟 MCP 的超时机制关系不大，更多是 client 那边等 server 的 stdio 响应。你可以试试在 server 里加点耗时打点，看看到底卡在哪一步。还有个坑是默认配置里文件监听范围太大，就算目录小它也可能在扫描别的东西，把 allow 路径收紧一点会快不少。

我前段时间也踩过这个坑，后来发现是 Claude Desktop 那边对 MCP 调用有个隐藏的超时上限，跟 server 响应速度关系不大。你可以先看下 server 的 log 里从收到请求到返回花了多久，如果很快但客户端还是断，那基本就是客户端侧的问题。另外官方 filesystem server 在大目录下会递归扫文件，换成小目录记得重启一下 MCP 进程，不然缓存还是旧的。我现在改用自己写的轻量 server 只暴露需要的接口，超时基本没再出现过。

我也遇到过，换成绝对路径别用相对路径就快多了，超时基本是server那边卡在解析上。

我前阵子也碰到类似情况，后来发现是 MCP 的 stdio 传输在 Claude Desktop 里有个隐性的启动握手，第一次调用会特别慢，尤其目录里文件多的时候，server 要先建索引。你可以试试在配置里把那个目录换成只有几个文件的小文件夹，看是不是第一次调用慢、后面就正常了。如果一直超时，大概率是客户端这边有默认的调用超时窗口，跟 server 响应速度关系不大。

我也折腾过这套组合，确实容易卡在工具调用那一步。你看到 server log 里请求发出去了但响应慢，其实超时判断大多在客户端这边，Claude Desktop 会等一个默认时限，server 没在这个窗口里返回它就直接掐断，所以报超时不一定代表 server 挂了。filesystem server 本身是 node 进程，如果目录里文件多或者有 node_modules 这种巨量小文件，它遍历起来会慢到离谱，换小目录还慢可能是它在做路径校验或者被系统权限拦了。可以在终端里手动跑一下那个 server 命令，再用 MCP inspector 直接打一次工具调用，看纯 server 侧到底要多久，这样就能把锅分清楚。另外 Claude Desktop 的日志在开发者模式里能翻到更细的报错，比只看 server log 有用。我后来把项目根目录换成只含源码的子目录、加了个忽略规则，情况好了一大截，你也可以试试把大文件目录先排除掉。

我之前也这样，后来发现是MCP客户端等server响应有默认超时，不是模型慢，调大timeout就好多了。

学到了，感谢分享！

刚入门，这个对我帮助很大。

我前段时间也碰到过类似的情况，后来发现是 Claude Desktop 那边默认超时时间设得比较短，server 其实还在处理但客户端已经断了。你可以看下 MCP 的配置里有没有 timeout 相关的参数，把它调大一点试试。另外官方 filesystem server 在大目录下遍历确实会慢，换个 node_modules 少点的目录对比一下就知道是不是这个原因了。

我前段时间也踩过类似的坑，Claude Desktop 接 filesystem server 读大一点的目录确实容易卡。你说的 log 里请求发出去了但响应慢，我建议先看看是不是 server 在启动时对整个目录做了索引或者递归扫描，默认配置下有些版本会这么干，换成小目录还慢的话可能不是这个原因。超时这块我的理解是客户端那边有个等待上限，server 返回慢到超过阈值就直接断了，所以 log 里看着请求正常但客户端已经放弃了。你可以试试把 server 单独跑起来用命令行手动调一下工具，看响应到底要多久，这样能区分是客户端卡还是 server 慢。我最后是把目录范围缩到具体几个文件、关掉不必要的 watch，情况好了不少。另外 Claude Desktop 的版本也有影响，旧版本对 MCP 的等待处理比较粗暴，升级一下说不定就顺了。

我这边也碰到过，后来发现是客户端等响应的时间设太短了，调大点就好很多。

先看下客户端超时设的多少，filesystem server 本身挺快的，大概率是默认超时太短了。