- In auth.ts
- in InspectorOAuthClientProvider constructor
- add optional scope param
- set instance var this.scope to scope param
- in clientMetadata getter
- add scope param set to this.scope or ""
- in useConnection.ts
- in handleAuthError handler
- move instantiation of serverAuthProvider until after scope has been determined
- pass scope to InspectorOAuthClientProvider constructor
- In oauth-state-machine.ts
- in token_request transition
- ensure resource is URL type, not string
- this fixes Quick flow which was sending string, while guided was using proper URL type and working
- Add shared discoverScopes function in auth.ts with resource metadata preference
- Update automatic flow (handleAuthError) to use dynamic scope discovery
- Update manual flow (OAuth state machine) to use shared scope discovery logic
- Add comprehensive test suite for discoverScopes function (11 test cases)
- Fix empty array handling to return undefined instead of empty string
- Maintain backward compatibility with existing oauthScope parameter
- All quality gates pass: TypeScript, linting, formatting, and tests
Resolves OAuth scope discovery inconsistency where automatic flow used static
scopes while manual flow used metadata scopes. Both flows now use identical
shared logic with proper resource metadata preference.
* In useConnection.ts
- During initialization, if there is an error immediately following the client sending 'logging/setLevel', pops up a toast with the message `Server declares logging capability but doesn't implement method "logging/setLevel"`
* In useConnection.ts
- During initialization, if there is an error immediately following the client sending 'logging/setLevel', pops up a toast with the message `Server declares logging capability but doesn't implement method "logging/setLevel"`
- 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
- Test that transport and serverUrl parameters are correctly passed via URL
- Verify SSE and streamable-http transport types are handled
- Test default STDIO behavior
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.
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.
