Consider extensible pattern for protocol flow-control exceptions

[felixweinberger]

PR #1780 adds specific except UrlElicitationRequiredError: raise blocks in tool handlers to prevent this exception from being wrapped as a tool error.

Per SEP-1036, UrlElicitationRequiredError is not a regular error—it's a protocol-level flow control mechanism equivalent to elicitation/create. It needs to propagate as a JSON-RPC error response.

If more continuation-style exceptions are added in the future, consider an attribute-based pattern:

class McpError(Exception):
    propagate_through_tool_handlers: bool = False

class UrlElicitationRequiredError(McpError):
    propagate_through_tool_handlers = True

For now, YAGNI applies—we only have one such case.

[woshiyixinke]

Hi Felix, trying to help out here. Before proceeding, I'd like to clarify a couple of design points:

1. It seems that mcp/server/lowlevel/server.py is the central exception handling point. wanna double confirm it's the only point where all tool-raised exceptions are caught and wrapped.

2. Given this is tagged v2, is the expectation that we should use the extensible pattern immediately on the main branch, or should we continue with the specific except UrlElicitationRequiredError: raise from Fix for Url Elicitation issue 1768 #1780 for the current v1.x branch and reserve this refactoring for a dedicated v2 development branch?