Test 30 now expects an error when multiple servers exist, even with
"default-server" present, aligning with the simplified logic that only
auto-selects when there's exactly one server.
Only auto-select when there's exactly one server in the config file.
Removes special handling for "default-server" naming convention.
Addresses review feedback from @ochafik on PR #661
- Add --transport option to command line parser
- Support --transport stdio/sse/http flags
- Convert 'http' to 'streamable-http' internally
- Fix transport type conversion for CLI mode
- Add --transport and --server-url support to client/bin/start.js
- Pass transport configuration through server to client via /config endpoint
- Update client App.tsx to use defaultTransport and defaultServerUrl from server
- Ensure SSE and HTTP transport configs work properly from CLI
- Pass URL as command for SSE/HTTP configs instead of empty string
- Update runCli to pass transport type flag when needed
- Update tests to expect connection errors for non-existent SSE/HTTP servers
- Add examples for stdio, sse, and streamable-http transport types
- Document automatic server selection behavior
- Show how to use default-server in config files
- Auto-select server when --config is used without --server
- Use 'default-server' if it exists in config
- Use single server if only one is defined
- Show helpful error if multiple servers exist without default
- Add tests for all default-server scenarios
- Test that transport and serverUrl parameters are correctly passed via URL
- Verify SSE and streamable-http transport types are handled
- Test default STDIO behavior
- Remove web client launch tests from CLI test suite
- Add CLI-mode tests for SSE and streamable-http configs
- Keep only tests that use --cli flag as intended
Move transport configuration parsing to cli.js as suggested in PR review. The CLI entry point (cli.js) should handle config file parsing and pass parameters to start.js.
- Add tests for config files with different transport types (stdio, sse, streamable-http)
- Add test for backward compatibility with configs missing type field
- Verify transport and serverUrl options are correctly parsed from config files
- All 36 tests pass
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.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
This fixes the regression introduced in dc5fa6a where empty strings
were passed as arguments when no command or args were provided,
causing parseArgs to fail with "Unexpected argument ''" error.
The spread operator approach is more idiomatic and avoids creating
empty strings that need to be filtered out.
The server was invoked as:
`server/build/index.js --command comm --args arg1 arg2 arg3`
(`arg1 arg2 arg3` is a string in ARGV; the single value of `--args`.)
`util:parseArgs()` cannot handle an argument value with a leading dash
with this usage.
e.g.,
`server/build/index.js --command npm --args --silent --prefix path/to/servers/src/everything run start`
The above will throw, and indicate correct usage:
```
TypeError [ERR_PARSE_ARGS_INVALID_OPTION_VALUE]: Option '--args' argument is ambiguous.
Did you forget to specify the option argument for '--args'?
To specify an option argument starting with a dash use '--args=-XYZ'.
```
However, since users do not control the invocation of the server, they
cannot adjust the notation for their use-case.
`arguments`, and `command`, are unknown user input, so adjust the
argument form to the more lenient and robust notation. Although a
`command` beginning with `-` seems unlikely, consistent handling of both
improves code clarity and simplicity.
Running the server directly (e.g., on the command line in development)
may continue to use: `--args arg1 arg2 arg3` if desired, so this is a
non-breaking change.
