fix(mcp): add support for error_type in mcp instrumentation

[fali007]

This PR intends to add error.type open telemetry attribute to MCP errors.

• 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.

Above screenshot shows error.type with error type and cleaned error message

---

Important

Adds error.type attribute support to MCP instrumentation for enhanced error reporting.

• Behavior:
  • Adds error.type attribute to MCP errors in traced_method in instrumentation.py.
  • Uses get_error_type() to extract error type from error messages.
  • Sets error.type for both caught exceptions and error results.
• Functions:
  • Adds get_error_type() to determine HTTP error type from message strings.
• Misc:
  • Imports re and HTTPStatus for error type extraction.

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

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 2aa0fe3 in 3 minutes and 5 seconds. Click for details.

• Reviewed 83 lines of code in 1 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:
  Inconsistent error checks: one branch checks with hasattr(result, 'isError') while another uses dictionary membership ('isError' in request.result). Ensure error responses are handled uniformly.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% Looking at the code, these two sections appear to be handling different types of objects. Line 180 is handling a result object directly, while line 325 is handling request.result which appears to be a dictionary. The different approaches make sense given the different data structures. Using getattr() wouldn't be appropriate for the dictionary case. I could be wrong about the object types - without seeing the actual objects at runtime, I can't be 100% certain these are different data structures requiring different handling. However, the fact that they access different fields (result.content vs result['content']) strongly suggests these are indeed different types requiring different handling. The code appears intentionally structured this way. The comment should be deleted as it appears to be incorrectly suggesting unifying two intentionally different approaches that are correctly handling different data structures.

2. packages/opentelemetry-instrumentation-mcp/opentelemetry/instrumentation/mcp/instrumentation.py:202

• Draft comment:
  The regex pattern '\b(4\d{2}|5\d{2})\b' may capture unintended numbers if the error message contains other 3-digit values. Refine the pattern if the error format is known.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The regex pattern uses word boundaries (\b) which helps prevent partial matches. The code also has explicit validation of the number range. The function returns None for any non-matching cases. This is a well-designed function that already handles edge cases appropriately. The comment raises a valid concern about pattern matching, but doesn't consider the additional validation that's already in place. The code is already robust - it uses word boundaries in the regex and explicitly validates the number range to ensure only valid HTTP status codes are processed. Delete the comment because the code already handles the edge cases appropriately through word boundaries and explicit range validation.

Workflow ID: wflow_7Doa03ntXvKmYU9Z

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

[ellipsis-dev]

Consider precompiling the regex pattern used in get_error_type to avoid recompilation on each call.

[nirga]

Thanks, left a couple of comments. Can you also add tests?

[nirga]

careful, setting None as a span attribute (this is what you do with the result of this method) will throw an exception

[fali007]

Ive added checks for making sure it doesn't return None before adding error type attribute to spans.