云代理碰到 MCP 限流会先停这一个工具
10 月 5 日那一周的 Cloud Agents 说明写：MCP 服务器限流某个工具时，云代理会按服务器要求的时长暂停这个工具，同时继续用该服务器的其他工具，并被告知何时可以重试。Slack 反复限流时，等待大约封顶一分钟。
cursor 云代理 mcp 限流等待发生在工具被服务器限流的时候，不是整台代理停摆。Cloud Agents 发行说明「10 月 5 日那一周」写：MCP 服务器对某个工具限流时，代理会按服务器要求的时长暂停这一个工具，继续使用该服务器的其他工具，并且会被告知什么时候可以重试。
暂停的是被点名的那个工具
说明的主语是「那个工具」。同一台 MCP 服务器上没被限流的工具还可以调用。这和「服务器断开后所有工具一起失败」不是同一种记录。同一周的修复里另有一句：MCP 工具调用在服务器重启后可以恢复，而不再直接失败；参数不合法时会给出具体原因。重启恢复是连接回来了。限流等待是服务器还在，但这一个工具要等。
Slack 被反复限流时，等待大约封顶在一分钟。原文写的是 “about a minute”，并且只点了反复出现的 Slack 限流。别的服务器若在响应里要求等更久，说明没有说也会被砍到一分钟。不要把这一分钟套到每一个 MCP。
说明没有写限流响应里要有哪个头或哪一个 JSON 字段，代理才认这段等待。服务器没有给出时长时会不会有默认值，原文也没有写。
本地窗口和命令行不在这句里
这节的产品是 Cloud Agents。本地 Cursor 窗口里的 MCP，以及 CLI 里的 MCP 登录，都没有出现在这句话里。本地调用被 429 挡住时，不能用「云代理会暂停约一分钟」来预期。
云代理因为机器内存耗尽被杀死，是另一条说明，见 云代理内存被杀时会被告知上限。那条谈的是 shell 被系统杀掉并带上内存上限。MCP 限流不会报内存上限，也不会把整次运行标成内存耗尽。
写作日没有把某个 MCP 打到限流，没有看到暂停时长和「何时重试」的原文提示。10 月 15 日核对的是这一周的 MCP 小节。