feat(mcp-instrumentation): Add error type to MCP errors.

[fali007]

• I have added tests that cover my changes.
• If adding a new instrumentation or changing an existing one, I've added screenshots from some observability platform showing the change.
• PR name follows conventional commits format: feat(instrumentation): ... or fix(instrumentation): ....
• (If applicable) I have updated the documentation accordingly.

This PR aims to add error types and correct error messages to MCP errors propagated from MCP server to MCP client.

---

Important

Adds error type handling to MCP errors and updates tests for stream reader/writer classes.

• Behavior:
  • Adds error type handling to MCP errors in traced_method in instrumentation.py.
  • Introduces get_error_type() to extract HTTP error types from messages.
• Instrumentation:
  • Updates traced_method to set ERROR_TYPE attribute for errors.
  • Modifies InstrumentedStreamWriter.send() to handle error attributes.
• Tests:
  • Adds tests for serialize() and stream reader/writer classes in test_mcp_instrumentation.py.
  • Tests InstrumentedStreamReader and InstrumentedStreamWriter for correct span attribute setting.

^{This description was created by for c9cf00b. You can customize this summary. It will automatically update as commits are pushed.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ fali007
❌ felix

---

felix seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to c9cf00b in 2 minutes and 6 seconds. Click for details.

• Reviewed 280 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. packages/opentelemetry-instrumentation-mcp/opentelemetry/instrumentation/mcp/instrumentation.py:180

• Draft comment:
  Before accessing result.content[0].text, ensure that 'result.content' exists and is a non-empty list to avoid potential IndexError.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This appears to be a reasonable defensive programming suggestion. The code assumes result.content exists and has at least one element when result.isError is true, but this may not always be guaranteed. An IndexError could occur if the error response has an unexpected structure. However, without seeing the full type definitions and API contract for the error responses, I can't be 100% certain this check is necessary. I don't have visibility into the API contract or type definitions that would tell me if result.content is guaranteed to exist and be non-empty when isError is true. The error handling may be following an established pattern. While defensive programming is good practice, without clear evidence that this check is necessary, I should err on the side of assuming the original author understood the API contract. Since I don't have strong evidence that this is a real issue rather than speculative, and understanding whether this check is needed would require more context about the API contract, I should remove this comment.

2. packages/opentelemetry-instrumentation-mcp/tests/test_mcp_instrumentation.py:149

• Draft comment:
  No tests appear to cover error scenarios (e.g. when isError is true). Consider adding tests to validate that ERROR_TYPE and error statuses are correctly set in error cases.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_bwM8qaHTZpPAtOq9

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[fali007]

Closing this PR because of CLA username issue.