Fix for Url Elicitation issue 1768

[gopitk]

Fix for #1768

Motivation and Context

Change is needed because UrlElicitationRequiredError was not being propagated as an exception

How Has This Been Tested?

Tested with the examples/snippets indicated in the original issue. Also added a unit test for this case.

Breaking Changes

N/A

Types of changes

• [X ] Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• [ x] I have read the MCP Documentation
• [x ] My code follows the repository's style guidelines
• [x ] New and existing tests pass locally
• [ x] I have added appropriate error handling
• I have added or updated documentation as needed

[felixweinberger]

Thanks for submitting this! LGTM.

[felixweinberger]

Feels slightly awkward to have this feature specific exception at such a generic level - but can't think of a better way to achieve the intended design of 1036 right now (and also matches what TS SDK does).

[felixweinberger]

Created an issue to potentially find a better way to raise this error, but don't want to block on this: #1788

[gopitk]

Thanks @felixweinberger . I considered raising it as McpError (with the specific url elicitation error code info) but thought that could break existing clients.

[felixweinberger]

Yeah that wouldn't be the right approach - I was thinking more something along the lines of having a propagate_error: bool on McpError for example and then have some gating inside that on whether to raise or pass, but that's definitely overengineering for one exception case imo.