Hi openai-agents team,
First, thank you for creating this exciting library! I've been experimenting with it to build agents that use custom tools served over MCP.
Problem Description
I've encountered a significant limitation: there appears to be no public API to configure the timeout for tool calls. The default timeout seems to be hard-coded to a very short duration (around 5 seconds), which consistently causes tool calls to fail with the following error if they take longer to execute:
mcp.shared.exceptions.McpError: Timed out while waiting for response to ClientRequest. Waited 5.0 seconds.
This makes it impossible to use tools that perform reasonably long-running operations, such as making an API call to another LLM, executing a complex database query, or any other task that can't be guaranteed to complete within 5 seconds.
My Use Case
My agent uses a tool called concept_decomposition. This tool's job is to take a high-level conceptual query (e.g., "movies by a specific director's 'crew'") and make an API call to a separate Large Language Model to break it down into a list of concrete entities. This external LLM call naturally takes more than 5 seconds, causing the tool call to time out every time.
What I've Tried
I have attempted to set the timeout in various ways, assuming common API design patterns, but all of them have resulted in TypeError: ... got an unexpected keyword argument:
On MCPServerSse initialization (top-level): MCPServerSse(..., timeout=60.0)
Inside MCPServerSse's params dict: MCPServerSse(params={"url": "...", "timeout": 60.0})
On the Runner.run method: Runner.run(..., tool_call_timeout=60.0)
After inspecting the source code of the underlying mcp library, I believe the timeout is enforced in mcp/shared/session.py within the BaseSession.send_request method. This method does have a request_read_timeout_seconds: timedelta | None = None parameter, which is exactly what's needed to control this on a per-request basis.
The issue seems to be that the openai-agents framework, which sits on top of mcp, does not provide a "pass-through" mechanism to allow users to provide a value for this underlying parameter. The call stack from Runner.run down to BaseSession.send_request doesn't appear to propagate any user-configurable timeout.
Suggested Solution
The most intuitive and powerful solution would be to add a tool_call_timeout (or a similar name) parameter to the Runner.run method. This parameter would accept a float (in seconds) and would be propagated down the call stack to populate the request_read_timeout_seconds argument in BaseSession.send_request.
Thanks for reading, if there exists a way to solve this, plz let me know.