feat - incorporated mcp server request configs for cli mode

[Kavyapriya-1804]

This PR implements the feature requested by #330

Motivation and Context

When using the Inspector in CLI mode, there's currently no way to configure Inspector-specific settings like MCP_SERVER_REQUEST_TIMEOUT. This limitation forces users to work with default timeout values, which may not be suitable for all use cases, especially when dealing with slower MCP servers or long-running operations. This PR adds support to accept the mcp server request's configs to be set from CLI in form of flags and values.

The below configs have been added

Setting	Description	Default
MCP_SERVER_REQUEST_TIMEOUT	Timeout for requests to the MCP server (ms)	10000
MCP_REQUEST_TIMEOUT_RESET_ON_PROGRESS	Reset timeout on progress notifications	true
MCP_REQUEST_MAX_TOTAL_TIMEOUT	Maximum total timeout for requests sent to the MCP server (ms) (Use with progress notifications)	60000

Sample usage for a remote everything-server:

mcp-inspector-cli --cli http://localhost:3001/sse --method tools/list --request-timeout 1 --reset-timeout-on-progress true --max-total-timeout 5000

How Has This Been Tested?

• I have tested the MCP_SERVER_REQUEST_TIMEOUT with listing tools as below. Successfully passes or fails according to the timeout duration given.

mcp-inspector-cli --cli http://localhost:3001/sse --method tools/list --request-timeout 1 --reset-timeout-on-progress true --max-total-timeout 5000

• Tested MCP_REQUEST_MAX_TOTAL_TIMEOUT with calling a tool (longRunningOperation) from everything-server as below. But not able to test the failure case for this.

mcp-inspector-cli \  --cli http://localhost:3001 \
  --method tools/call \
  --tool-name longRunningOperation \
  --tool-arg duration=10 \
  --tool-arg steps=10 \
  --request-timeout 1000 \
  --reset-timeout-on-progress true \
  --max-total-timeout 1

• MCP_REQUEST_TIMEOUT_RESET_ON_PROGRESS has been implemented the same way but not able to test the failure scenarios

Breaking Changes

This PR does not introduce any breaking changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

The implementation of passing the 3 server configurations has been done like how its done for the mcp web mode. Checked the implementation of connect (class Protocol) and request (class Client) methods in typescript-sdk repo of mcp as well. In both cases RequestOptions are accepted the same way.

Could you please suggest further ways to test MCP_REQUEST_MAX_TOTAL_TIMEOUT and MCP_REQUEST_TIMEOUT_RESET_ON_PROGRESS ?

[Kavyapriya-1804]

synced the PR @olaservo @cliffhall @pulkitsharma07

[olaservo]

Hi @Kavyapriya-1804 I think one way we can run tests on these changes is to add a script similar to this one: cli\scripts\cli-tests.js

If you look at the package.json for the cli folder, the test script is running that script. It runs specific testing scenarios through the CLI using the Everything server as a test server, which is one we use a lot for validation.

I created an example here. The only issue I had with this example is that I can't get the Test 5: Reset timeout on progress disabled - should fail with timeout scenario to fail as expected, but that could be an issue with the test script and not the implementation. Hopefully it gives you an idea of how to test this though.

I was running the above example script by adding it to the package.json in the cli folder, eg "test:timeouts": "node scripts/timeout-tests.js",

[Kavyapriya-1804]

Hi @olaservo,
Thanks for the test cases !

I was able to run them successfully. But wasn't able to get 2/ 9 test cases right (Test 4: Reset timeout on progress enabled - should complete successfully and Max total timeout exceeded (should fail)).
I guess this is because we are not able to capture the progress notifications from the CLI. When I looked into the CLI implementation of tools/call too, I wasn't able to find any code related to capturing notifications of a progress.

Kindly suggest further..

[cliffhall]

Hi @olaservo, Thanks for the test cases !

I was able to run them successfully. But wasn't able to get 2/ 9 test cases right (Test 4: Reset timeout on progress enabled - should complete successfully and Max total timeout exceeded (should fail)). I guess this is because we are not able to capture the progress notifications from the CLI. When I looked into the CLI implementation of tools/call too, I wasn't able to find any code related to capturing notifications of a progress.

Kindly suggest further..

@Kavyapriya-1804 Maybe this suggests we need to add those features to the CLI? What would that look like?

[Kavyapriya-1804]

Hi @cliffhall , @olaservo, @pulkitsharma07
I don't see any implementation in cli that captures and logs notifications when using CLI mode in terminal.
Though I could see server notifications being listened and shown in UI in inspector web as below.

Implementing this feature could be helpful to receive updates likes messages and progress on long running tool calls.

Would you like to have them implemented as part of this PR ?
What are your thoughts on this ?

[cliffhall]

Hi @cliffhall , @olaservo, @pulkitsharma07 I don't see any implementation in cli that captures and logs notifications when using CLI mode in terminal.
...
Would you like to have them implemented as part of this PR ? What are your thoughts on this ?

I think the CLI should handle logs and notifications in some way, but I'm not sure how. Presumably they would be well identifiable and parsable from the STDOUT/STDERR of the CLI, so that tests can verify that they appear there and are correct. Play with what they might look like in the output and make a proposal here for that. Let us see some mockups of an output stream with these notifications mixed in.

[Kavyapriya-1804]

Sure @cliffhall.
Will analyze and extend the proposal for including notification in the output stream

cc: @olaservo

[olaservo]

Hi @Kavyapriya-1804 , just wanted to mention I think we can leave out the notifications piece and just focus on the supported features + configs for now since it probably made these changes a lot bigger. What do you think?

[Kavyapriya-1804]

Hi @olaservo, yeah sure. Would work on the notifications part in a separate issue.
For now, the code is good with passing 7/9 test cases you gave. Quoting the below detail from our previous conversation ..

I was able to run them successfully. But wasn't able to get 2/ 9 test cases right (Test 4: Reset timeout on progress enabled - should complete successfully and Max total timeout exceeded (should fail)).
I guess this is because we are not able to capture the progress notifications from the CLI. When I looked into the CLI implementation of tools/call too, I wasn't able to find any code related to capturing notifications of a progress.

Please merge if it looks good to you. Thanks !

[Kavyapriya-1804]

Hi @olaservo @cliffhall
The PR is now in sync with the main branch. Please review and merge this.

[cliffhall]

@Kavyapriya-1804 With the everything server running in SSE mode, the command you included, I get the following:

Could you please give a clear and complete set of instructions for testing against server-everything ? I.e., setup and test cases for stdio, streamableHttp, and sse, with the various settings and whether failure or success is expected? I don't want to have to guess about this. It would be good if you included screenshots of the results of each test on your system, so that we can compare our results to yours in each case.

[olaservo]

@cliffhall here's the original suggestion I made for testing that we were referencing for this PR:

I think one way we can run tests on these changes is to add a script similar to this one: cli\scripts\cli-tests.js

If you look at the package.json for the cli folder, the test script is running that script. It runs specific testing scenarios through the CLI using the Everything server as a test server, which is one we use a lot for validation.

I created an example here. The only issue I had with this example is that I can't get the Test 5: Reset timeout on progress disabled - should fail with timeout scenario to fail as expected, but that could be an issue with the test script and not the implementation. Hopefully it gives you an idea of how to test this though.

I was running the above example script by adding it to the package.json in the cli folder, eg "test:timeouts": "node scripts/timeout-tests.js",

As long as we're OK with waiting on the timeout support for progress notifications, I think we could add a modified version of this ^^ script to the repo and/or modify the existing to include these cases?

[cliffhall]

@Kavyapriya-1804 could you look at incorporating the script @olaservo mentioned above into the existing tests?

[Kavyapriya-1804]

Sure, will add @cliffhall