feat: MCP tool error isolation — individual tool failures should not abort entire agent run

[tcconnally]

Problem

When an AutoGen agent uses MCP tools (via mcp-tools integration) and a single tool fails, the error propagates up and aborts the entire agent run. This is problematic because:

1. One bad tool kills the session: If the agent calls 5 tools and the 3rd fails (e.g., MCP server timeout, tool-specific error), the remaining 2 tool calls are lost
2. No per-tool error reporting: The agent receives a generic "MCP tool call failed" error, not structured error information about which tool failed and why
3. No retry/fallback: There's no mechanism for the agent to retry the failed tool or use an alternative

In production multi-agent scenarios, individual tool failures should be surfaced as tool-level errors that the agent can reason about and recover from, not as fatal exceptions.

Expected Behavior

1. MCP tool errors should be caught and returned as structured ToolResult with is_error=True rather than raising exceptions
2. The agent should see: "Tool search_docs failed: Connection timeout (MCP server at localhost:9000)"
3. The agent run should continue with remaining tool calls
4. Optional: configurable retry policy per tool/MCP server

Current Workaround

Users must wrap every MCP tool call in try/except in their agent logic, which defeats the purpose of declarative tool registration.

Related

• AutoGen's MCP tool integration: autogen-ext[mcp]
• MCP Python SDK transport error handling: Race condition in StreamableHTTP: zero-buffer memory streams cause deadlock with concurrent SSE responses modelcontextprotocol/python-sdk#1764

[Shlok148Dev]

I've opened a pull request to resolve this issue: #7887
It implements MCP tool error isolation (converting caught transport/timeout exceptions and MCP-reported tool execution errors into structured ToolResult shapes instead of crashing the run). I've also added configurable retry options (max_retries and retry_delay) for transient errors, and a raise_on_error parameter to support opt-in backward compatibility. All formatting, type-safety, and new/modified test scenarios are verified and passing.

[tcconnally]

Closing this — I went back through the current code and the error isolation I asked for already exists:

• McpWorkbench.call_tool wraps execution in try/except and returns ToolResult(..., is_error=True) instead of raising, so a failing MCP tool surfaces as structured error data.
• AssistantAgent._execute_tool_call converts any tool exception into FunctionExecutionResult(is_error=True, ...), and _execute_tool_calls dispatches calls via asyncio.gather, so one tool failing doesn't abort the others or the run.

The only path that still raises is the legacy McpToolAdapter._run, but that exception is caught at the agent layer and surfaced as a structured error too. So the "a single tool failure aborts the entire agent run" premise doesn't hold for the current McpWorkbench path.

Apologies for the noise. (An optional per-tool retry/fallback policy could still be a nice enhancement, but that's separate from error isolation and not a bug.)

[Shlok148Dev]

Hi @tcconnally, no worries at all!

Since I've already implemented a robust per-tool retry policy (with configurable max_retries and retry_delay) for transient transport/timeout failures, as well as adapter-level normalization for McpToolAdapter (which keeps the adapter's return contract clean rather than relying on the agent/workbench catching exceptions), I'd love to pivot this PR to be a feature enhancement.

It's fully backward-compatible (via raise_on_error: bool = False) and comes with comprehensive tests. Let me know if you'd be open to reviewing it as a feature update!