最近在试着用 Claude Desktop 接 MCP 服务，想让它直接读我本地项目文件然后帮我改代码。配是配上了，但每次调用文件读取工具都要等好久，偶尔直接超时断开。我检查了 server 的 log，发现请求发出去了但响应很慢，本地也没啥负载。用的是官方 filesystem server，配置就是默认的那些，换了个小点的目录还是一样。想问问大家 MCP 工具调用的超时机制到底是怎么算的？是客户端这边卡住还是 server 返回慢？有没有人遇到过类似情况，最后是怎么解决的？
楼主
3天前
热帖
MCP 工具调用总是超时，是我的配置有问题还是模型本身就这样？
请 登录 后发表回复
全部回复
共 5 条
2楼
2天前
我这边也卡过，后来发现是文件监听太多目录拖慢了响应，建议先精简下映射路径试试。
3楼
2天前
我之前也碰到过类似的情况，后来发现是 filesystem server 默认会对整个目录做递归扫描，哪怕你换了个小目录，只要里面 node_modules 没排除，一样卡到爆。建议在配置里加上 ignore 规则，把 .git、node_modules 这些直接屏蔽掉试试。另外 MCP 的超时其实是客户端侧控制的，Claude Desktop 这边好像默认 60 秒左右就会断，server 如果还在跑也没用。你可以先手动跑一下 server 用 curl 或者命令行调一次工具，看看到底是响应慢还是根本没返回。
4楼
1天前
我前段时间也踩过这个坑，后来发现不一定是配置的问题。Claude Desktop 那边其实有个隐性的工具调用等待窗口，server 响应稍微一慢就容易触发超时，官方 filesystem server 在大目录下遍历文件确实会拖时间。你可以先试试把目录缩到只有几个文件，看还超不超时，这样能区分是 server 慢还是客户端等不及。另外换个第三方实现的 filesystem MCP 有时反而更稳，官方那个在某些系统上 IO 处理确实一般。
5楼
21小时前
我之前也碰到过类似的情况，后来发现是 MCP 的 stdio 传输方式下，客户端等的是 server 走完整个 JSON-RPC 往返，目录一深文件一多，光遍历目录就够呛。你可以试试在 server 启动参数里把允许访问的路径收窄，别让它递归扫整个项目。另外超时不一定在客户端，Claude Desktop 那边日志不太透明，建议先用 mcp inspector 单独跑一下 server，看单次 tools/call 实际耗时多少，心里就有数了。
6楼
3小时前
我也碰到过类似的情况，不过我是接的自己的 server，排查下来发现跟 MCP 的超时机制关系不大，更多是 client 那边等 server 的 stdio 响应。你可以试试在 server 里加点耗时打点，看看到底卡在哪一步。还有个坑是默认配置里文件监听范围太大，就算目录小它也可能在扫描别的东西，把 allow 路径收紧一点会快不少。