OpenAI Agents SDK Parallel MCP Calls Turning Serial? Testing and Fix

Issue: Why Do Parallel Calls Become Serial?

Recently, developers discovered a performance issue with the OpenAI Agents SDK when calling remote MCP tools: when the model requests multiple tool calls simultaneously, these calls are not executed in parallel but processed one after another serially. Taking 4 tool calls each requiring 3 seconds as an example, the total time reaches 12 seconds instead of the expected 3 seconds. This issue was reproduced on OpenAI Agents SDK 0.24.0 and MCP 2.3.0 (both the latest versions on PyPI), specifically manifesting as the streamable HTTP client sending only one request at a time.

The insidious nature of this problem is that it doesn't cause crashes, just slow operation, making it easy to overlook. If you're using MCP 2.x and connecting to remote MCP servers via streamable HTTP, you've likely already encountered this issue.

MCP (Model Context Protocol) is an open protocol launched by OpenAI in 2024, aimed at standardizing the connection between AI models and external tools and data sources. It allows models to call remote services through a unified interface, such as querying databases, executing code, or accessing APIs. MCP adopts a client-server architecture, where the Agents SDK acts as the client and communicates with MCP servers through transport layers like HTTP or stdio. Streamable HTTP is a transport method introduced in MCP 2.x that supports streaming responses and more efficient connection reuse, but requires the client to correctly handle concurrent requests. Understanding the basic architecture of MCP helps locate the problem: parallel call serialization occurs at the client SDK's request scheduling layer, not at the network or server side.

Reproduction Steps: 8 Lines of Code Reveal the Bottleneck

To verify this issue, developers conducted a clean reproduction experiment. The environment used a fresh virtual environment, Python 3.13.5, and precisely installed OpenAI Agents 0.24.0 and MCP 2.3.0. No model or API key was needed; the server side implemented a tool called slow with just 8 lines of code, which sleeps for 3 seconds before returning. The client established a single connection, initiated 4 calls to slow simultaneously, and printed the completion time of each call.

The results showed completion times of 3 seconds, 6 seconds, 9 seconds, and 12 seconds respectively, with a total time of 12.1 seconds, failing the check. This proves that calls were queued and executed one by one on a single connection.

Root Cause Analysis: Legacy Lock Mechanism

Why does serialization occur? The root cause can be traced back to the MCP 1.x era. At that time, to address the issue where a failed request could cancel other requests, a per-server lock was introduced in PR 2682. This lock was reasonable in MCP 1.x, but in version 0.24.0, it still applies to streamable HTTP. In the SDK, every request goes through this check, and when the flag is set to true, each request waits for the lock to be released, resulting in serial execution.

GitHub issue #5474 (reported on November 1) points out that MCP 2.x may no longer need this lock, but OpenAI has not yet replaced this mechanism, and the MCP 2.x side has not responded. Therefore, this is currently only the reporter's analysis, not an officially confirmed fix.

Per-server lock is a synchronization mechanism used to ensure that requests on the same server connection are processed in order. In MCP 1.x, because the underlying session management was not robust enough, concurrent requests could cause a failure of one request (such as timeout or cancellation) to affect other requests on the same connection, so this lock was introduced to isolate failures. However, this lock sacrifices parallelism. In MCP 2.x, the protocol layer may have solved this problem through improved flow control and error handling, but the OpenAI Agents SDK still retains compatibility logic for legacy behavior. The _serialized_session_requests flag is exactly the switch that controls whether to enable this lock, with a default value of true, forcing serialization even when using streamable HTTP. This reflects the SDK's lagging trade-off between backward compatibility and performance optimization.

Official Status and Community Progress

As of November 4, the issue remains open, with no maintainer response, no fix PR, and no new version release. Another developer reproduced the issue, and another published a root cause analysis. The community is waiting for an official response.

Temporary Solution: Unofficial Workaround

There is currently a tested unofficial workaround: after the server connection is established, set the _serialized_session_requests attribute to false. This only applies to MCP 2.x, and since it's a private attribute, any SDK update could break it. On version 1.x, the lock exists for a reason; according to the issue, if the connection disconnects, all in-progress calls fail together, so it's not recommended to use this on 1.x.

Another approach is to use a separate connection for each run, but this won't help parallelize calls within a single run, and it hasn't been tested.

After applying the workaround, in the same test, all 4 calls completed within 3.1 seconds, with a total time of 3.1 seconds, passing the check. Repeated three times, each time was 3.1 seconds; without the workaround, each time was 12.1 seconds. The only change was this flag, reducing the time from 12.1 seconds to 3.1 seconds.

How to Determine If You're Affected

You can test yourself using a similar method: create a tool that sleeps for 3 seconds and initiate 4 calls simultaneously. If the total time is about 12 seconds, you're experiencing this issue; if it's about 3 seconds, you're not. The developer reproduced the issue on November 4.

If you encounter it, you can provide your SDK version, MCP version, and operating system information under the issue to help the community push for a fix.

One-line Summary

OpenAI Agents SDK 0.24.0 and MCP 2.3.0 cause parallel tool calls to execute serially due to a legacy lock mechanism, with 4 three-second calls taking 12 seconds instead of 3 seconds.

Paragraph Summary

This article reveals a performance issue in OpenAI Agents SDK 0.24.0 and MCP 2.3.0: when connecting to remote MCP servers via streamable HTTP, multiple tool calls are executed serially instead of in parallel. A developer reproduced it with 8 lines of code, where 4 calls each requiring 3 seconds took a total of 12 seconds. The root cause is a per-server lock mechanism introduced in the MCP 1.x era, which may no longer be needed in 2.x but hasn't been removed. GitHub issue #5474 has been reported but not officially fixed. The community provides an unofficial workaround: setting _serialized_session_requests to false can reduce the time to 3.1 seconds, but it only applies to MCP 2.x and is a private attribute. The article also provides a self-test method and calls for community information to push for a fix.