[Bug]: MCP reconnect remains broken after transient HTTP error

Is there an existing issue for the same bug?

• I have searched existing issues and this is not a duplicate.

Bug Description

When a streamable HTTP MCP tool call receives a transient HTTP error, FastMCP terminates its session task but leaves the nesting counter nonzero. The SDK's next automatic reconnect then fails permanently instead of opening a fresh session.

Expected Behavior

The failed tool call should report the HTTP error, and the next tool call should reconnect and succeed when the server is healthy again.

Actual Behavior

On current main (e26683288ab4dd69518810016b74682de2a8c4e4), run the real HTTP regression with uv run pytest -q tests/sdk/mcp/test_create_mcp_tool.py -k reconnects_after_http_error.

The first call correctly reports 504 Gateway Timeout. The second call fails with MCP Connection Failure, caused by:

RuntimeError: Internal error: nesting counter should be 0 when starting new session, got 1

Steps to Reproduce

1. Start a FastMCP streamable HTTP server.
2. Return HTTP 504 for the first tools/call request.
3. Call the same MCP tool again through the SDK client.
4. Observe that automatic reconnect fails before sending the second tool call.

Acceptance Criteria

• After an HTTP error terminates the FastMCP session task, the next MCP tool call reconnects and succeeds.
• Existing MCP client tests continue to pass.

Installation Method

uv sync from the repository checkout.

SDK Version

Current main at e26683288ab4dd69518810016b74682de2a8c4e4.

Version Confirmation

• I have confirmed this bug exists on the LATEST version of OpenHands SDK

Python Version

3.13.7

Operating System

Linux

Logs and Error Messages

First call: 504 Gateway Timeout
Second call: MCP Connection Failure
Cause: RuntimeError: Internal error: nesting counter should be 0 when starting new session, got 1

Minimal Code Sample

The linked PR includes an integration test that starts a local FastMCP HTTP app, injects one 504 response, and makes two calls through the real SDK tool executor.

Screenshots and Additional Context

Draft PR #3444 identified the same FastMCP stale-counter state on an older SDK architecture. Current main now has automatic reconnect in the tool executor; this report covers that current path and uses a real HTTP failure rather than mocked session state.

The failure reproduces with the repository's locked FastMCP 3.2.0 and also with 3.4.7. It does not reproduce with FastMCP 4.0.2, whose session implementation changed, but adopting a breaking major version is separate from preserving reconnect behavior for the currently supported FastMCP 3.x dependency.

Start by running uv run pytest -q tests/sdk/mcp/test_create_mcp_tool.py -k reconnects_after_http_error and read the MCP tool executor's automatic reconnect path. Trace how the FastMCP session task handles the first HTTP 504 and its nesting counter. Done means the first call reports the HTTP error, the next call reconnects and succeeds, and existing MCP client tests pass.