Elicitation Timeout

Describe the bug
Timeout occurs if elicitation request isn't responded to in a second.
Inspector shows the elicitation request, but when used in AI Agent, the agent does not even show elicitation and directly gets the error.

To Reproduce
Steps to reproduce the behavior:

Implement elicitation for any tool, with multiple inputs
Test the tool in inspector
See the elicitation request in Elicitation tab
respond for 1 request, then see the error when not responded for next requests in a second or two.

error: MCP error -32001: Request timed out

Expected behavior

The elicitation error should be thrown to console
The elicitation should not timeout so quick
Need a timeout parameter for elicitInput function

Logs
MCP error -32001: Request timed out
error thrown at the tool response for unmet elicitation timeout

@pkrc267 Which version are you using? The LATEST version of the SDK has an options parameter that can be used to pass in a timeout num

@pkrc267 Which version are you using? The LATEST version of the SDK has an options parameter that can be used to pass in a timeout num

I'm on 1.17.0
Could you share an example of how to pass that? I'm not able to find how the SDK handles the parameter passed to elicit function.

I see that in the general request method checks for a timeout in the options parameter. If nothing is provided then it goes with default 60 seconds.

typescript-sdk/src/shared/protocol.ts

Line 624 in 3dd074f

const timeout = options?.timeout ?? DEFAULT_REQUEST_TIMEOUT_MSEC;

However this further affirms the bug. Even with the default 60 seconds, the subsequent elicitation requests times-out within 2 or 3 seconds. Which should not be the case.

The same is happening to me. Even overriding this timeout option closes my connection within 2 or 3 seconds

@yadav-prakhar are you running a stateless server? What I am understanding from reading a lot of discussion and code is that for sampling and elicitation you need a stateful server with session management. Otherwise it will timeout

@NafisAli that's a useful insight. I have been working on stdio based server without explicitly handling any session.
Also I don't maintain any state in any small db like sqlite.

But given the nature of stdio connections which are one-to-one dedicated connection, could this still happen?

I also have timeout with sampling and it seem it is exactly the timeout mentioned by @NafisAli
Thank your for that hint about stateless vs stateful - it absolutely makes sense, because you need a session to send the llm response.

My issue happens only with transpoort http-streamable (stateless-server) and in stdio it works - added this bug entry in inspector:
modelcontextprotocol/inspector#809

Update: My issue was solved when I switched to stateful server config.

Hi @yadav-prakhar , thanks for filing this!

Looks like the following setup (w/ inspector vs. everything server) works:

npx -y @modelcontextprotocol/inspector npx -y --silent @modelcontextprotocol/server-everything

Closing but happy to reopen if you can provide instructions to repro / confirm a bug here ✌️