Plan Around Rate Limits When MCP Tools Fire Parallel Requests
You will cap how many MCP tool calls run at once and keep their outputs small, so one burst does not stall or overflow the agent. The steps are general planning advice, since the threads I checked do not document a rate-limit error.
- Plan the batchGroup tool calls that hit the same API or browser.
- Cap result sizeRequest excerpts instead of full files or large responses.
- Retry with backoffWait longer between each retry of a throttled call.
- Check the recordUse session.md and trace files to see where the run stalled.
Why it matters
Parallel tool calls can send many requests in the same moment, and a burst like that can slow or stop a whole task. None of the threads I checked report a rate-limit error directly, so treat this as planning advice. The closest real case is Roo-Code issue 1532 (opens external site), where one oversized read filled the context and the agent lost its instructions. Several large results arriving together can push the context the same way.
Steps
- Review the tool calls the agent proposes in one turn. If several of them hit the same external API or the same browser, approve them in smaller groups instead of all at once.
- Keep each tool result small. Ask for an excerpt or a summary rather than a full file or a large API response. The reporter in issue 1532 used this workaround by hand, and it usually worked for them.
- Run one browser session per task when you use Playwright MCP. Sessions that share state are harder to reason about when several requests land together.
- When a call fails with a throttling or timeout error, wait, then retry with a longer gap each time (exponential backoff). Do not resend the whole batch at once.
- Pin the Roo-Code and playwright-mcp versions you tested. The Roo-Code terminal thread shows version-specific regressions (3.7.8 returned output, 3.7.10 froze, 3.8.1 stalled), so a known-good version is easier to return to.
- If a run stalls and you need a record, check your installed playwright-mcp release for the
--save-sessionflag. In issue 734 the maintainer confirmed that this flag records user interactions and snapshots. Follow-up testing in that thread reported that using it together with--save-traceproduced a trace.zip and a session.md file. Note that issue #1007 reports--save-sessionstopping after about 7-8 actions, so check session.md for gaps.
Common mistakes
- Assuming the model will pace itself. It will not know about provider limits unless you split the work.
- Letting one large read or response fill the context, then blaming the rate limit.
- Retrying immediately in a tight loop, which adds load instead of clearing it.
- Changing the Roo-Code or playwright-mcp version mid-task without noting it.
Checklist
0 of 8 done