`McpError` when `run-mcp-python` code sandbox handles concurrent requests

[ivo-1]

Initial Checks

• I confirm that I'm using the latest version of Pydantic AI
• I confirm that I searched for my issue in https://github.com/pydantic/pydantic-ai/issues before opening this issue

Description

We are facing issues with the run-mcp-python code sandbox on concurrent requests.

Context:

• we are using pydantic_graph
• we are using temporal to execute the nodes as activities
• we are running the mcp-run-python server with the streamable_http protocol
• we observe no issues when the code sandbox only has to handle one request at a time
• we are wrapping the agent.run() call like so and passing in the run-mcp-python server as a remote MCPServerStreamableHTTP with a read timeout of 60s:

async with agent:
  return await agent.run(toolsets=mcp_servers)

Issues:

1. The run-mcp-python server seems to have issues with handling concurrent requests (starts happening at 2 concurrent requests). It reliably times out after 60s. I'm not sure what the expectation is regarding handling concurrent requests but my understanding was that this is handled.
2. More notably: This results in failures of agent.run() with 2 sub-cases we observe

• The tool call itself times out resulting in a ToolRetryError. This makes sense and is fine.

• Other (parallel) tool calls that are successful still lead to errors in agent.run() -- more specifically the GET and POST requests to /mcp timeout which seems to lead to that. This results in McpError for agent.run() and bubbles up to a unhandled errors in a TaskGroup (1 sub-exception) in the top-level BaseNode.run(). I've attached a screenshot of our traces in logfire that illustrates this case. Unfortunately I can't share a link to the trace here.

Apologies for not having a MRE at hand and of course happy to work on providing one if there is no obvious bug that you already are aware of.

Python, Pydantic AI & LLM client version

Python: 3.13.5
Pydantic: 0.7.5
LLM Client: OpenRouter

[samuelcolvin]

Thanks for reporting. We might need to somehow prevent concurrent code execution.

We managed to narrow the issue down a bit. There seems to be an problem with a subsequent GET /mcp request which does not terminate. This problem also appears for non-concurrent requests - the request was just less likely to run into the 60s timeout if less agents consume the inference capacity.
The issue would be actually solved for us, if the run-mcp-python server would support a stateless mode, enabling less complex request handling for simpler use cases. I opened a PR adding this mode: #15