OTel client span stays Unset when the tool result has isError: true
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 79/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- python
- Domain
- backend-api-design, observability
Research direction
Start in shared/jsonrpc_dispatcher.py and read the existing handling for JSON-RPC error responses, then compare it with the tool-error handling in server/_otel.py and the guidance in docs/gen-ai/mcp.md. Exercise a successful response containing a CallToolResult with isError set; done means the client span reports error.type=tool_error and ERROR status, with a test covering the behavior.
Written by the indexing model from the issue text.
Description
With mcp==2.3.0, the client span created in shared/jsonrpc_dispatcher.py sets ERROR status and error.type for a JSON-RPC error response (the #3174 fix), but not for a successful response whose CallToolResult.isError is true. The server span for the same call does set error.type=tool_error (server/_otel.py), so the two ends of one call disagree.
The OTel GenAI semantic conventions for MCP (docs/gen-ai/mcp.md, note on error.type) say instrumentation SHOULD set error.type to tool_error when the tool result reports an error.
Reproduction (Python client and server, Streamable HTTP, default OTel setup):
git clone https://github.com/mkwitko/mcp-reliability && cd mcp-reliability
examples/python-sdk-streamable-http/run.sh # needs docker, uv, go
go run ./cmd/mcp-reliability doctor testdata/python-sdk-default.jsonl
Output includes:
[WARN] MCP-ERR-003: client and server spans for "tools/call fail" disagree on failure: the client span lacks error.type
Captured trace and write-up: https://github.com/mkwitko/mcp-reliability/blob/v0.1.0/docs/research/python-sdk-v2-validation.md
Suggested change: after the response is parsed in the dispatcher, if the result is a CallToolResult with isError, set error.type="tool_error" and status ERROR on the client span, matching server/_otel.py. Happy to send a PR if you agree with the direction.
- Dominant language
- Python
- Stars
- 24.7k
- Forks
- 4.1k
- Avg merge
- 18h 27m
- Merged PRs (30d)
- 15
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelcontextprotocol/python-sdk
-
bug v2
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
modelcontextprotocol/python-sdk#3811 ·
Maintainers usually reply within 1 day
-
bug v1 v2
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
modelcontextprotocol/python-sdk#3781 · 2 comments ·
Maintainers usually reply within 1 day
-
[Bug]: Inconsistent structured output wrapping and opt-out for typing.Dict and typing sequence generics in func_metadataMay be free again A pull request for this issue was closed without being merged. Openbug v1 v2
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
modelcontextprotocol/python-sdk#3771 · 3 comments ·
Maintainers usually reply within 1 day
-
bug v2
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
modelcontextprotocol/python-sdk#3769 · 2 comments ·
Maintainers usually reply within 1 day
-
2026 Streamable HTTP rejects whitespace-padded Mcp-Name valuesMay be free again A pull request for this issue was closed without being merged. Openbug spec-2026-07-28 v2
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
modelcontextprotocol/python-sdk#3763 · 4 comments ·
Maintainers usually reply within 1 day
All issues in modelcontextprotocol/python-sdk
Similar issues
-
DBFS append mode silently overwrites existing filesPossibly taken @IlyaKhalafi claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
fsspec/filesystem_spec#2429 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
volcengine/OpenViking#7014 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
fedora-copr/copr#4600 ·
Maintainers usually reply within 2 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ansys/pydpf-core#3620 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day