SDKs and other middleware SHOULD allow these timeouts to be configured on a per-request basis.

[grll]

Describe the bug
According to the MCP specs:

"SDKs and other middleware SHOULD allow these timeouts to be configured on a per-request basis."

But looking at the code the timeouts are set at the session level and not easily configured on a per-request basis as the specs recommend:

async def send_request(
 self,
 request: SendRequestT,
 result_type: type[ReceiveResultT],
) -> ReceiveResultT:
 ...
 try:
 with anyio.fail_after(
 None
 if self._read_timeout_seconds is None
 else self._read_timeout_seconds.total_seconds()
 ):
 response_or_error = await response_stream_reader.receive()
 except TimeoutError:
 raise McpError(
 ErrorData(
 code=httpx.codes.REQUEST_TIMEOUT,
 message=(
 f"Timed out while waiting for response to "
 f"{request.__class__.__name__}. Waited "
 f"{self._read_timeout_seconds} seconds."
 ),
 )
 )

see

Suggestion

Add an optional argument request_read_timeout_seconds and rename current _read_timeout_seconds into session_read_timeout_seconds if request_read_timeout_seconds is set it would override the session one.

I will publish a small PR in that sense.

[grll]

also maybe on another note but I find calling the argument read_timeout_seconds and using a timedelta a bit odd, I would expect an int to be passed for "seconds"

[njbrake]

Hi @grll I'm here too because we are having a similar problem in any-agent 😆 : mozilla-ai/any-agent#422

In our case, we want to have a higher timeout for the initialization, since it may involve pulling a docker image which may take longer than the timeout that we would want to use.

Maybe as a hack, we could set _session_read_timeout_seconds to be what we want when the initialization happens, and then re-set the value back to it's normal value for everything after the initialization, but it seems to defeat the purpose of there being the request_read_timeout_seconds parameter in send_request.

[grll]

@njbrake maybe not ideal but you could use a high _session_read_timeout_seconds and low request_read_timeout_seconds on every request afterward?

[maxisbey]

Thanks for the report. This has been available for a while now, including in the current release (see #601). Closing this as part of a wider backlog cleanup following the v2 launch. If you still run into this on v2, feel free to reopen.

_{AI Disclaimer}