add config parsing for SSE and streamable HTTP transports

[al1y]

Motivation and Context

Currently, the inspector won't parse and load details from an SSE or Streamable HTTP config.

For example, running node client/bin/start.js --config "C:\path\to\mcp.json" --server my-server where mcp.json is

{
    "mcpServers": {
        "my-server": {
            "type": "sse",
            "url": "http://localhost:60157/sse"
        }
    }
}

will yield

Starting MCP inspector...
⚙️ Proxy server listening on port 6277
🔍 MCP Inspector is up and running at http://127.0.0.1:6274 🚀

NOTE - it defaults to stdio and does not respect the provided config

SSE

After these changes, running node client/bin/start.js --config "C:\path\to\mcp.json" --server my-server will yield

Loaded configuration for 'my-server' from 'C:\path\to\test-mcp.json'
Starting MCP inspector...
Using sse transport with URL: http://localhost:60157/sse
⚙️ Proxy server listening on port 6277
� MCP Inspector is up and running at http://127.0.0.1:6274 �

Streamable HTTP

Similarly, running node client/bin/start.js --config "C:\path\to\mcp.json" --server my-server where mcp.json is

{
    "mcpServers": {
        "my-server": {
            "type": "streamable-http",
            "url": "http://localhost:3000/mcp"
        }
    }
}

will now yield

Loaded configuration for 'my-server' from 'C:\path\to\test-mcp.json'
Starting MCP inspector...
Using streamable-http transport with URL: http://localhost:3000/mcp
⚙️ Proxy server listening on port 6277
� MCP Inspector is up and running at http://127.0.0.1:6274 �

How Has This Been Tested?

Manually with local stdio, sse and streamable-http servers, ensuring stdio env vars propagate appropriately.
Extended related automated tests for client using loaded config values in the connect call.
Better test representation would be in client start and proxy but there's currently no existing framework for either.

Breaking Changes

No expected 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

First contribution, apologies for any errors in process or intent

[olaservo]

Thanks for the PR and sorry for the wait. I had some minor comments and questions mainly to clarify the logic.

[olaservo]

I'm a little confused by this comment and how it relates to the checking here, could you be more explicit about the intent of this check?

Also I think it could help to add more explanation in general about the config precedence logic in the code as comments.

[al1y]

Thanks for the review! I've added some comments around config precedence as suggested