BUG-HUNT: [error-handling] Broad exception in MCPToolAdapter.invoke #1322

New issue

Open

opened 2026-04-02 16:49:21 +00:00 by freemo · 0 comments

freemo commented

2026-04-02 16:49:21 +00:00

Owner

Bug Report: Error Handling — Broad exception in MCPToolAdapter.invoke

Severity Assessment

Impact: Similar to the disconnect method, catching a broad Exception can mask underlying issues with the transport layer, making debugging difficult.
Likelihood: Medium, as this code is executed every time a tool is invoked.
Priority: Medium

Location

File: src/cleveragents/mcp/adapter.py
Function/Class: MCPToolAdapter.invoke
Lines: 456-462

Description

The invoke method in MCPToolAdapter catches a generic Exception when calling the transport layer. This can hide important details about what went wrong, such as whether the error was a network timeout, a serialization error, or a problem with the MCP server itself. Returning a generic error message makes it harder for callers to handle the error gracefully or for developers to diagnose the root cause.

Evidence

            except Exception as exc:
                elapsed = (time.monotonic() - start) * 1000
                return MCPToolResult(
                    success=False,
                    error=f"MCP server error invoking '{tool_name}': {exc}",
                    duration_ms=elapsed,
                )

Expected Behavior

The exception handling should be more specific. It should catch specific, expected exceptions (e.g., TimeoutError, ConnectionError, IOError) and handle them appropriately. Unexpected exceptions should be allowed to propagate or be handled by a more generic, higher-level error handler.

Suggested Fix

Replace the generic except Exception: with more specific exception handlers. For example:

            except TimeoutError as exc:
                elapsed = (time.monotonic() - start) * 1000
                return MCPToolResult(
                    success=False,
                    error=f"Tool '{tool_name}' timeout: {exc}",
                    duration_ms=elapsed,
                )
            except ConnectionError as exc:
                elapsed = (time.monotonic() - start) * 1000
                return MCPToolResult(
                    success=False,
                    error=f"Connection error invoking '{tool_name}': {exc}",
                    duration_ms=elapsed,
                )
            except Exception as exc:
                elapsed = (time.monotonic() - start) * 1000
                # Log the full traceback for unexpected errors
                logger.error("Unexpected error invoking tool '%s'", tool_name, exc_info=True)
                return MCPToolResult(
                    success=False,
                    error=f"An unexpected error occurred invoking '{tool_name}': {exc}",
                    duration_ms=elapsed,
                )

Category

error-handling

## Bug Report: Error Handling — Broad exception in MCPToolAdapter.invoke ### Severity Assessment - **Impact**: Similar to the `disconnect` method, catching a broad `Exception` can mask underlying issues with the transport layer, making debugging difficult. - **Likelihood**: Medium, as this code is executed every time a tool is invoked. - **Priority**: Medium ### Location - **File**: `src/cleveragents/mcp/adapter.py` - **Function/Class**: `MCPToolAdapter.invoke` - **Lines**: 456-462 ### Description The `invoke` method in `MCPToolAdapter` catches a generic `Exception` when calling the transport layer. This can hide important details about what went wrong, such as whether the error was a network timeout, a serialization error, or a problem with the MCP server itself. Returning a generic error message makes it harder for callers to handle the error gracefully or for developers to diagnose the root cause. ### Evidence ```python except Exception as exc: elapsed = (time.monotonic() - start) * 1000 return MCPToolResult( success=False, error=f"MCP server error invoking '{tool_name}': {exc}", duration_ms=elapsed, ) ``` ### Expected Behavior The exception handling should be more specific. It should catch specific, expected exceptions (e.g., `TimeoutError`, `ConnectionError`, `IOError`) and handle them appropriately. Unexpected exceptions should be allowed to propagate or be handled by a more generic, higher-level error handler. ### Suggested Fix Replace the generic `except Exception:` with more specific exception handlers. For example: ```python except TimeoutError as exc: elapsed = (time.monotonic() - start) * 1000 return MCPToolResult( success=False, error=f"Tool '{tool_name}' timeout: {exc}", duration_ms=elapsed, ) except ConnectionError as exc: elapsed = (time.monotonic() - start) * 1000 return MCPToolResult( success=False, error=f"Connection error invoking '{tool_name}': {exc}", duration_ms=elapsed, ) except Exception as exc: elapsed = (time.monotonic() - start) * 1000 # Log the full traceback for unexpected errors logger.error("Unexpected error invoking tool '%s'", tool_name, exc_info=True) return MCPToolResult( success=False, error=f"An unexpected error occurred invoking '{tool_name}': {exc}", duration_ms=elapsed, ) ``` ### Category error-handling

Rows
Columns