Parallel MCP tool calls cause Runtime Error

[tradeqvest]

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

What happens?

Firing two or more MCP tools concurrently through the same MCPServerSSE/MCPServerStreamableHTTP (or MCPServerStdio) instance reliably crashes with:

RuntimeError: Attempted to exit cancel scope in a different task than it was entered in

This propagates as an ExceptionGroup that aborts the whole agent run.

---

Expected Behaviour

Parallel tool calls should finish successfully; the underlying SSE/stdio connection is reference-counted and should close cleanly when the last task exits.

---

Suspected Root Cause

Suspected Issue Location in Code:

pydantic-ai/pydantic_ai_slim/pydantic_ai/mcp.py

Lines 225 to 230 in 8f20f9b

	async def __aexit__(self, *args: Any) -> bool | None:
	async with self._enter_lock:
	self._running_count -= 1
	if self._running_count == 0 and self._exit_stack is not None:
	await self._exit_stack.aclose()
	self._exit_stack = None

1. MCPServer.__aenter__() opens the transport client once and keeps an AsyncExitStack in self._exit_stack. It also increments _running_count.
2. Every concurrent tool call re-enters the same server, re-using the connection and incrementing _running_count.
3. The last task to finish runs __aexit__() with _running_count → 0 and tries to await self._exit_stack.aclose().
4. Inside aclose() AnyIO unwinds a TaskGroup that was created in the first task, therefore it leads to an error if the last task to finish is not the initial first task to enter:

RuntimeError: Attempted to exit cancel scope in a different task than it was entered in

---

Potential solutions

• Run tool calls serially (await them one after another).
• Instantiate one MCPServer per task, avoiding shared connection pools.

---

Workaround

Wrap the exit-stack shutdown in __aexit__:

try:
    await self._exit_stack.aclose()
except RuntimeError as exc:
    if "exit cancel scope" not in str(exc):
        raise
    warnings.warn(
        "MCPServer exit stack closed from a different task; "
        "safe to ignore but indicates concurrent tool calls.",
        RuntimeWarning,
    )
finally:
    self._exit_stack = None

Example Code

Python, Pydantic AI & LLM client version

Python >= 3.13
pydantic-ai >= 0.4.6

[ivo-1]

Another potential solution is to avoid the task creation entirely and instead use coroutines to run everything in the same task context. We can then use asyncio.as_completed() to yield the FunctionToolResultEvent as they come in from the completed coroutines.

This seems to do the trick:

# Create coroutines that include their index
async def indexed_call(i, call):
    r = await _call_function_tool(tool_manager, call)
    return i, r

# Process coroutines as they complete
for coro in asyncio.as_completed([indexed_call(i, call) for i, call in enumerate(calls_to_run)]):
    index, (tool_result_part, extra_parts) = await coro
    yield _messages.FunctionToolResultEvent(tool_result_part)
    parts_by_index[index] = [tool_result_part, *extra_parts]

Edit: This doesn't work.

[DouweM]

@tradeqvest @ivo-1 Thanks for the reports, I'm getting more frustrated with asyncio by the day... https://sailor.li/asyncio does a good job of laying out how broken it's cancellation handling is.

In any case, here's a test that clearly shows this issue:

def test_parallel_mcp_calls():
    try:
        from pydantic_ai.mcp import MCPServerStdio
    except ImportError:  # pragma: lax no cover
        pytest.skip('mcp is not installed')

    async def call_tools_parallel(messages: list[ModelMessage], info: AgentInfo) -> ModelResponse:
        if len(messages) == 1:
            return ModelResponse(
                parts=[
                    ToolCallPart(tool_name='get_none'),
                    ToolCallPart(tool_name='get_multiple_items'),
                ]
            )
        else:
            return ModelResponse(parts=[TextPart('finished')])

    server = MCPServerStdio('python', ['-m', 'tests.mcp_server'])
    agent = Agent(FunctionModel(call_tools_parallel), toolsets=[server])
    result = agent.run_sync()
    assert result.output == snapshot('finished')

One way to fix it is to add async with agent: around agent.run{_sync}(), so that neither of the parallel tools with actually end up closing the connection.

As it happens, #2361 was just created to always do that automatically, so that should fix this as well. I'll get a test added there and mark that to fix this issue.

[tradeqvest]

One way to fix it is to add async with agent: around agent.run{_sync}(), so that neither of the parallel tools with actually end up closing the connection.

We have this exact setup causing the issue at the moment, so this is definitely not a fix for us unfortunately.

[DouweM]

@tradeqvest Hmm, it fixed that failing test when I added it, and it seems to make sense as a solution, as the running_count will predictably go down to 0 only once the async with agent: is exited, and not when one of the tool calls completes. Can you share example code that still fails?

[DouweM]

@tradeqvest I closed this issue with the merge of that PR as it includes the test I posted yesterday which now passes, so at least the exact problem described in the description doesn't exist anymore, but if you can get me a new test that fails on main we can reopen this issue or create a new one!

[tradeqvest]

Thanks @DouweM, we'll test if the new version will fix it once it is released. If not, we'll investigate further!

[NikunjChamaria]

Even i am trying to make an agent with parallel tool calls but still getting the issue, is this issue fixed and if yes in which version will i not get this error

[ivo-1]

@NikunjChamaria the fix is in 0.4.10.