mcp: retry input-required results that carry only requestState

[SergeevDmitry]

A result with only requestState is a valid InputRequiredResult under SEP-2322 (servers "MUST include at least one of inputRequests or requestState"), and the TypeScript SDK server sends one from inputRequired({ requestState }). The Go SDK handled it on neither side:

• Client: clientMultiRoundTripMiddleware returned early when InputRequests was nil, so such a result reached the caller as the final one (NeedsInput() true, no content), although the client docs say the middleware retries while NeedsInput() is true.
• Server: annotateResultType and the rest of the server's result handling checked only InputRequests, so a handler returning only a RequestState sent a complete result, and a resources/read handler doing so failed with "read handler returned nil information".

This uses one check, inputRequests() != nil || requestState() != "", for the server's result type, the content validation, the empty content/messages fill, the resources/read early return and the legacy shim. For clients before 2026-07-28 the shim calls the handler again with the state echoed. The client retries these results with the state echoed and counts them as rounds (maxMultiRoundTripRetries), not as load shedding, the same as the shim. An empty inputRequests map is still load shedding, and a result with neither field still fails after the load-shedding limit. Content together with a requestState is now rejected like content with inputRequests. The server docs are updated and docs/server.md is regenerated.

New tests, all failing on main:

• Client: TestMultiRoundTrip_AutoRetry_RequestStateOnly, TestMultiRoundTrip_AutoRetry_InputRequiredWithoutFields, TestMultiRoundTrip_RequestStateOnly_MaxRetries.
• Server: TestMultiRoundTrip_ServerRequestStateOnly (tools/call, prompts/get, resources/read), TestMultiRoundTrip_ServerMiddleware_RequestStateOnly, TestMultiRoundTrip_ContentWithRequestState, and three requestState-only cases in TestServerSessionHandle_SetsResultTypeWhenMiddlewareShortCircuits.

go test -race ./..., go vet ./... and both conformance scripts pass locally (server 40/40, client 239/239).

Fixes #1364

AI assistance: I used Claude Code to help write this fix and the tests.

[guglielmo-san]

@SergeevDmitry what do you think about fixing this on server side too?
Currently annotateResultType only sets the resultType if inputRequests is different from nil.

case multiRoundTripResponse:
		// These results are complete or input_required, so label them by
		// whether the handler asked for more client input.
		if r.inputRequests() != nil {
			r.setResultType(resultTypeInputRequired)
		} else {
			r.setResultType(resultTypeComplete)
		}

[SergeevDmitry]

Agreed, the server should be able to send a requestState-only result too. I'll add it to this PR.

inputRequests != nil decides this in a few more places on the server, so I'd switch them together to one check (inputRequests() != nil || requestState() != ""):

• annotateResultType: label the result input_required.
• validateMultiRoundTripResult: also reject content together with a requestState. Today that goes out as a complete result with a stray requestState.
• CallTool / GetPrompt: don't fill in an empty content / messages for such a result.
• ReadResource: a requestState-only result currently fails with "read handler returned nil information".

One question about the legacy shim: for a client before 2026-07-28, should a requestState-only round call the handler again with the state echoed, counted against maxMultiRoundTripRetries, or return the same "busy" error as an empty inputRequests map? I'd call the handler again, since the server is asking to continue rather than shedding load. The TypeScript shim does the same (it paces those rounds and counts them in the round cap).

[guglielmo-san]

Yes I would call the handler again

[SergeevDmitry]

Pushed the server side.

• asksForInput (inputRequests or requestState) now drives annotateResultType, validateMultiRoundTripResult, the empty content/messages fill in CallTool/GetPrompt, the early return in ReadResource and the legacy shim.
• Legacy shim: a requestState-only round calls the handler again with the state echoed and no responses, counted against maxMultiRoundTripRetries.
• Client: one change from the first commit. A requestState-only result now counts as a round instead of load shedding, so the client and the shim treat it the same way (10 rounds, not 3). An empty inputRequests map is still load shedding.
• Server docs are updated. New tests cover all three methods, the legacy shim, the round limit, and content together with a requestState. I updated the PR description to match.

[guglielmo-san]

this comment now is placed in the wrong place

[guglielmo-san]

Suggested change

	if reqMap != nil && len(reqMap) == 0 {
	return nil, fmt.Errorf("the server is busy, retry later")
	}
	if len(reqMap) == 0 && mrtrResult.requestState() == "" {
	return nil, fmt.Errorf("the server is busy, retry later")
	}

[guglielmo-san]

Suggested change

	loadSheddingFailures++
	if len(reqMap) == 0 && mrtrResult.requestState() == "" {
	loadSheddingFailures++
	}

[SergeevDmitry]

Thanks. I applied both suggestions and moved the comment back.

• The client now counts a round as load shedding only when the result has neither input requests nor a requestState. The legacy server path returns "busy" under the same condition. So an empty inputRequests map with a requestState now continues, like a requestState-only result.
• That changes one existing case. TestMultiRoundTrip_MaxRetries "load shedding" returned {} together with RequestState: "loop-state". I dropped the state from that case and added "empty requests with state", which now runs to maxMultiRoundTripRetries.
• TestMultiRoundTrip_ServerMiddleware_RequestStateOnly now covers a nil and an empty map, each with a state.
• The new TestMultiRoundTrip_ServerMiddleware_Busy pins the busy error for an empty map without a state.

go test -race ./... and both conformance scripts pass (server 40/40, client 239/239).