Increase MaxReconnectionAttempts default from 2 to 5

[Copilot]

The default MaxReconnectionAttempts of 2 is too low for the MCP spec's intended reconnection behavior, where the retry field—not a count cap—is the intended throttling mechanism. Under CI load, two consecutive transient failures exhaust the budget immediately, causing the sse-retry conformance test to flake.

Changes

• HttpClientTransportOptions.MaxReconnectionAttempts: Default increased from 2 → 5
• XML docs: Updated <value> tag and <remarks> to reflect the new default and clarify that the counter resets to zero on each successful stream read (i.e., only consecutive hard failures count toward the limit)

Original prompt

Problem

The MaxReconnectionAttempts property in HttpClientTransportOptions defaults to 2, which is too low and conflicts with the MCP specification's intended reconnection behavior.

What the MCP spec says

The MCP Streamable HTTP transport spec and SEP-1699 state:

"the client will interpret the disconnection the same as a network failure, and will attempt to reconnect. In order to prevent clients from reconnecting / polling excessively, the server SHOULD send an SSE event with a retry field indicating how long the client should wait before reconnecting. Clients MUST respect the retry field."

The spec does not prescribe a maximum number of reconnection attempts. The intent is that the client keeps reconnecting at the server-specified retry interval. The retry field is the throttling mechanism — not a retry count cap.

The current default of 2 is too low

The value 2 was introduced as part of the resumability/polling feature (issue #1020, SEP-1699) with no documented rationale. It appears to have been an arbitrary conservative default. However, in practice:

1. It conflicts with spec intent: The spec expects the client to keep reconnecting as long as it has a valid Last-Event-ID. Two attempts is far too few for the polling/resumability use case that SEP-1699 specifically designed.

2. It causes real failures under load: In SendGetSseRequestWithRetriesAsync, attempt is incremented on transient HTTP errors (HttpRequestException or server errors ≥ 500). Under CI load — or any real-world scenario with transient network issues — two consecutive failures exhaust the budget immediately, causing the client to give up on retrieving a response that the server has stored and is ready to serve.

3. It causes the sse-retry conformance test to flake: The conformance test (ClientConformanceTests.RunConformanceTest(scenario: "sse-retry")) intermittently fails with delays like 9509ms instead of the expected 500ms. This happens because the client exhausts its 2 reconnection attempts under heavy CI load, falls out of the fast GET reconnection path, and only eventually reconnects through a much slower fallback. PR Fix flaky sse-retry conformance test due to CI timing overhead #1336 added tolerance for minor CI timing jitter (up to 10× the retry value), but 9509ms (19×) is not jitter — it's the symptom of the client giving up too early.

What to change

Increase the default MaxReconnectionAttempts from 2 to a more reasonable value. Note that the retry loop in SendGetSseRequestWithRetriesAsync already resets attempt = 0 on each successful stream read (clean stream close with a LastEventId), so MaxReconnectionAttempts only governs consecutive hard failures (network errors, 5xx responses). A value like 5 provides meaningful resilience against transient failures while still bounding runaway retries on persistent errors.

Files to change

• src/ModelContextProtocol.Core/Client/HttpClientTransportOptions.cs: Change the default value of MaxReconnectionAttempts from 2 to 5, and update the XML doc <value> tag accordingly.

How to validate

• All existing tests should continue to pass.
• The sse-retry conformance test should become significantly more reliable under CI load, since the client will survive transient failures during GET reconnection instead of giving up after just 2 attempts.

This pull request was created from Copilot chat.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[stephentoub]

This is another attempt to fix the sse-retry conformance test failures that continue to plague us in CI.