OpenAI Agents SDK MCP calls queue despite parallel tool requests

A model can request several independent tools at once while the user still waits for them one after another. An open Agents SDK issue reports that MCPServerStreamableHttp serializes requests through a per-server lock with mcp 2.x. Its controlled test measured four three-second tools taking about twelve seconds on one connected server; this is the reporter’s measurement, not a benchmark for every deployment.

Measure where latency accumulates

Trace model time, MCP call start/end, server execution and transport wait separately. Reproduce with two safe independent tools on one connected server, then compare with a different supported transport or separate sessions. Keep server rate limits and tool dependencies visible in the comparison.

Avoid unsafe lock removal

The issue explains why the lock was originally added for failure isolation. Removing it locally may change how a dropped connection affects in-flight calls. Prefer a reviewed SDK fix, or isolate independent workloads when the latency benefit outweighs connection and resource costs.

Set a user-facing budget

For interactive agents, decide how much of the response-time budget tools may consume and which calls actually need parallelism. If one shared MCP session queues all calls, a “parallel” prompt alone does not meet that budget.

Adovo’s view

Parallel intent is not parallel execution. A useful agent owns the full path from the model’s plan to the transport that carries it. Optimize the wait a customer feels, with failure behavior preserved.