feat: Auto-detect transport type from config files

[felixweinberger]

Motivation and Context

When launching the inspector with --config, automatically set the transport
dropdown and server URL based on the config file contents. This eliminates
the need to manually switch between stdio/sse/streamable-http in the UI.

• Use discriminated union for ServerConfig to properly type different transports
• Detect transport type and URL from config, pass via query params
• Maintain backwards compatibility for configs without explicit type field
• Add comprehensive tests for the new functionality

Improves UX by making the config file the single source of truth for
server settings.

How Has This Been Tested?

Tested manually with different configs:

E.g. with a stdio based config:

// mcp_dev_config.json
{
    "mcpServers": {
        "default-server": {
            "command": "uv",
            "args": [
                "run",
                "--with",
                "mcp[cli]",
                "mcp",
                "run",
                "/Users/fweinberger/path/to/my/code/stdio-test/main.py"
            ]
        }
    }
}

E.g. with a streamable-http based config:

// mcp_dev_config.json
{
    "mcpServers": {
        "default-server": {
            "type": "streamable-http",
            "url": "http://localhost:8000/mcp",
            "note": "For Streamable HTTP connections, add this URL directly in your MCP Client"
        }
    }
}

Breaking Changes

No.

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

[github-actions]

🎭 Playwright E2E Test Results

✅  15 passed

Details

15 tests across 2 suites
 22.3 seconds
 50b96a0
ℹ️  Test Environment: Ubuntu Latest, Node.js v22.17.1
Browsers: Chromium, Firefox

📊 View Detailed HTML Report (download artifacts)

[cliffhall]

Hey @felixweinberger, thanks for this!

1. There is a stalled PR that is working toward this. I'm mentioning it here so it can be closed if this one is merged. It is trying to modify client/bin/start.js though.

2. I'm testing this locally, and I realized start.js is not going to be the right place but cli.js is, since it's the entrypoint for the inspector package via npx. And placing this hook in cli.js, the common launching script, this should work with the CLI inspector as well, though I'm not certain that's the case. I saw you added tests in cli-tests and that gave me the impression it would be the case, but...

3. CLI tests are failing. Turns out the CLI tests are launching the web client. Those tests are meant to test the CLI client. they should just run and be done, without having to interact with the browser. Tests of launching the web client would be more appropriate in client/e2e where the Playwright tests happen and can run in CI.

4. I notice in your example mcp_dev_config.json you provide a default-server, so I tried that and found that you cannot launch with --config and fail to specify a server name. It feels like this should be possible if there is a default-server configured. Maybe the if not present on the command line, the script can grep the file for 'default-server' and if present in the file, use it as the server arg.

5. Verified that I could launch if I added a --server argument

[richardkmichael]

@cliffhall @felixweinberger

In #643 there is a setup for Playwright testing of the command line arguments using tag @cli and different web command: .. for startup.

I created that setup to write tests to catch the CLI options bug #649 . PR #664 fixes that bug.

Note the Playwright CLI tests PR is currently on top of the bug fix so that I could verify the tests caught the bug, but passed after the fix.

I think all of this should be ready for review, if it's helpful here.

I thought a full end-to-end test of entry-point CLI arguments to UI would be helpful as a catch-all since the Inspector is several components. (I had experience with Playwright from #582 to test more of the UI.). Tighter tests around just the CLI would be helpful too.

(I also noticed the other new "CLI tests" are not same CLI. 😂 )