OTel client span stays Unset when the tool result has isError: true #3810

Activity

1. claude

   added

   bugSomething isn't workingSomething isn't working

   v2Affects the v2 line (2.x on main)Affects the v2 line (2.x on main)

   on Nov 3, 2026
2. Aryan130103 commented on Nov 3, 2026

   

   Aryan130103

   on Nov 3, 2026

   More actions

   Hi! I'd be interested in contributing to this issue.

   I went through the reproduction steps and the suggested fix involving setting the client span's error status when a parsed CallToolResult has isError=true.

   I'd like to help investigate the dispatcher behavior and add regression coverage to ensure the client and server spans report consistent error statuses.

   Is anyone already working on the implementation? If not, would it be okay for me to take this up and submit a PR?

   Thanks!
3. media-ctrl commented on Nov 5, 2026

   

   media-ctrl

   on Nov 5, 2026

   More actions

   Confirmed on main, and the asymmetry is visible in two specific places rather than being an omission in the dispatcher's design.

   Client side, src/mcp/shared/jsonrpc_dispatcher.py only reaches the error attributes inside the isinstance(outcome, ErrorData) branch:

   if isinstance(outcome, ErrorData) and outcome is not _CLOSED_OUTCOME:
       code = str(outcome.code)
       span.set_attributes({"error.type": code, "rpc.response.status_code": code})
       span.set_status(StatusCode.ERROR, outcome.message)

   So a response object whose payload reports a tool failure never enters that branch: the outcome decodes fine, the span ends UNSET, and the call looks successful at the client end of the trace.

   Server side there is an explicit block for it in src/mcp/server/_otel.py, gated on the method:

   if ctx.method == "tools/call":
       match result:
           case CallToolResult(is_error=True) | {"isError": True}:
               span.set_attribute("error.type", "tool_error")
               span.set_status(StatusCode.ERROR)

   Two things in that server block are worth copying rather than paraphrasing, because a client fix that reads naturally will miss them.

   The first is the dual match. is_error is dropped by the alias-only wire validation, so a raw dict result arrives as isError. A client change that only tests the model attribute leaves the raw-dict shape disagreeing exactly as it does today. Mirroring the alternation is the whole point.

   The second is that this runs after the outcome is parsed and before the value is returned, which is also where the client would have to sit. Setting the attribute on the span after return result is not available to you, and setting it in the caller of the dispatcher means the span has already been closed.

   For the test, the interesting assertion is agreement, not the attribute in isolation: same trace, one tool error and one protocol error, assert both spans carry error.type and both are ERROR, and assert a successful call leaves the client span UNSET. That last one is what catches an over-eager fix that marks every tools/call span.

   We run an MCP server in front of a few dozen upstream business APIs, and a client-side blind spot on tool errors is expensive in a way that is easy to underestimate: in client dashboards the failed calls present as slow successes, so the retry and timeout logic keys on the wrong signal and the actual error text never surfaces.

   Direction is right. If you open the PR, the dual match plus the three-case test is the part I would review first.