Specify transport type on startup

[aaronpowell]

Is your feature request related to a problem? Please describe.
When you first run the inspector it defaults to stdio as the transport, unless previously specified. So if you run: npx -y @modelcontextprotocol/inspector http://localhost:1234/sse it will default to stdio and upon changing the dropdown, set it to the default of http:''localhost:3001/sse, removing your default value.

Describe the solution you'd like
When running inspector you should be able to specify the transport type to use, or it should be inferred from the server provided (eg: if it's http(s) prefixed, using SSE, otherwise use stdio).

Describe alternatives you've considered
I can't find any way in the code that this can be set.

Additional context
N/A

[cliffhall]

When running inspector you should be able to specify the transport type to use, or it should be inferred from the server provided (eg: if it's http(s) prefixed, using SSE, otherwise use stdio).

Hey @aaronpowell. This seems reasonable. Would you like to add a PR?

[aaronpowell]

I think there would be a level of intersection with #258 - maybe when the config endpoint is called it does some processing of the argument to send back that will determine the transport type, rather than having to add another arg to the CLI

[cliffhall]

Could we not rectify the situation in the client app, so that if you have supplied an http(s) url it switches the type to SSE?

[aaronpowell]

Since the client app gets its info on what to put in the transport drop down + input fields by calling the /config endpoint on the server, it'd make sense for the server (proxy) to provide that initial info, and then you can change it as desired.

Like I suggested, expanding on the solution in #258

[olaservo]

@claude is this functionality still needed in the latest version of MCP Inspector, or does it now auto-detect the transport being used?

[claude]

Claude finished @olaservo's task —— View job

---

Analysis of Transport Type Auto-Detection ✅

Investigating whether the requested transport auto-detection functionality has been implemented in the current version:

• Review current CLI interface and argument parsing
• Examine transport type handling in server code
• Check /config endpoint implementation
• Analyze client-side transport selection logic
• Test current behavior with HTTP URLs
• Provide recommendation on whether feature is still needed

Analysis Summary

After examining the current codebase (version 0.16.4), here's what I found:

Current State:

1. ✅ The CLI already has a --transport option that can be specified explicitly
2. ✅ The /config endpoint supports returning defaultTransport and defaultServerUrl
3. ✅ Client-side transport selection respects query parameters and localStorage
4. ⚠️ Partial implementation - Auto-detection exists but only in CLI-only mode

Key Finding: Auto-Detection Already Exists (But Not Where Expected)

The auto-detection functionality IS implemented in cli/src/index.ts:66-77:

} else if (isUrl) {
  const url = new URL(command);
  if (url.pathname.endsWith("/mcp")) {
    transportType = "http";
  } else if (url.pathname.endsWith("/sse")) {
    transportType = "sse";
  } else {
    transportType = "sse"; // default for URLs
  }
}

However, this logic only works for the CLI-only mode (--cli flag), not for the main web interface launcher.

The Issue

When you run:

npx -y @modelcontextprotocol/inspector http://localhost:1234/sse

It uses cli/src/cli.ts (web launcher) which lacks auto-detection, rather than cli/src/index.ts (CLI-only mode) which has it.

Recommendation

The functionality is still needed for the web interface launcher. The auto-detection logic should be ported from cli/src/index.ts to cli/src/cli.ts in the parseArgs() function around line 315-322.

The solution would be to add URL pattern detection when no --transport is explicitly provided, inferring:

• URLs ending in /sse → "sse" transport
• URLs ending in /mcp → "streamable-http" transport
• Other HTTP(S) URLs → "sse" (default)
• Commands → "stdio" (current behavior)

---

[aaronpowell]

Closing as #641 solves this with the config file