- Add state for connectionType
- Fetch connectionType from localstorage if present
* In Sidebar.tsx
- Add dropdown for connectionType, only visible if transport type is not stdio
* In Sidebar.test.tsx
- set connectionType to "proxy"
* In useConnection.ts
- add connectionType param, defaulting to "proxy"
- add state for mcpSessionId
- Only check proxy health if the connection type is proxy
- create a serverUrl variable which will either be the proxy url OR the server url depending upon the connection type
- added captureResponseHeaders function to extract the protocol-related headers from a response.
- when creating transport options and connectionType is "direct" and transportType is not "stdio",
- add the appropriate `Accept` and `Content-Type` headers
- capture the protocol related response headers and store them in the custom fetch handler
- set serverUrl to be the server url, not the proxy url
- if connection type is proxy set serverUrl to the mcpProxyUrl
- use serverUrl instead of mcpProxyUrl for the transport instantiation
* In useConnection.test.tsx
- replaced test "sends X-MCP-Proxy-Auth header when proxy auth token is configured" with two tests:
- "sends X-MCP-Proxy-Auth header when proxy auth token is configured for 'proxy' connectionType"
- "does NOT send X-MCP-Proxy-Auth header when proxy auth token is configured for 'direct' connectionType"
- added Connection URL Verification section with 2 tests
- uses server URL directly when connectionType is 'direct'"
- "uses proxy server URL when connectionType is 'proxy'"
- Introduced CustomHeaders component for managing custom headers.
- Updated Sidebar to include CustomHeaders component.
- Enhanced useConnection hook to handle custom headers and legacy auth migration.
- Added tests for custom headers functionality.
- Updated package.json and package-lock.json for new dependencies.
- set TS SDK to 1.17.5, which has the automatic log level handling
* In useConnection.ts
- push the logging/setLevel message onto the message history stack so it is clear in the Inspector that it has been sent.
Make both clients use name from package.json for consistency and protocol clarity
- web client changes `mcp-inspector` -> `inspector-client` (package.json)
- cli client remains `inspector-cli` (package.json)
The STDIO and SSE transports use SSE between the client and the proxy
server. SSE requires the client to initiate the MCP conversation
(event-stream) at the endpoint provided by the server. The endpoint
provided by the server must obey where the client sees the server,
rather than being assumed to be server-root `/message`.
The Streamable HTTP endpoint does not need the full proxy address
because the response is an event-stream directly, and does not use SSE.
* Inspect the stderr output of STDIO servers and attempt to assign an appropriate RFC 5424 Syslog Protocol level before sending a leveled logging message to the client
- 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
- 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"`
This commit adds a `context` argument to the completion handlers in `PromptsTab`, `ResourcesTab`, `useCompletionState`, and `useConnection`.
The context argument allows passing additional information to the completion engine, which can be used to improve the quality of the completions. The context is passed as a dictionary of key-value pairs.
The `ResourcesTab` component was also updated to pass `templateValues` as the `context` to the completion handler.
The `useConnection` hook was updated to include the context in the completion request sent to the server.
Changed proxy authentication to use a custom header (X-MCP-Proxy-Auth) instead of the standard Authorization header. This prevents conflicts when the proxy needs to forward the client's Authorization header to upstream MCP servers.
- Updated client to send proxy auth token in X-MCP-Proxy-Auth header
- Updated server auth middleware to check X-MCP-Proxy-Auth header
- Applies to all transport types (SSE, stdio, streamable-http)
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add MCP_PROXY_AUTH_TOKEN configuration field to store session token
- Update useConnection hook to include proxy auth token in all requests
- Add separate proxy auth headers to avoid conflicts with MCP server auth
- Add specific error handling for proxy authentication failures
- Show helpful toast message directing users to Configuration settings
- Update README with instructions for configuring token in UI
The client now properly authenticates with the proxy server using the
session token displayed in the proxy console.
* In server/src/index.ts
- add delete handler for /mcp endpoint
- gets the server transport for the sessionId
- calls terminateSession on it
- removes the webapp and server transports for the sessionId from the maps
- returns status 200 to the client.
* In client/src/lib/hooks/useConnection.ts
- import Transport
- add useState for clientTransport, type Transport or null initialized to null
- in connect() function
- move creation of client transport down a ways, just before calling client.connect with it
- immendiately efter calling client.connect, call setClientTransport with the connected transport (has to happen after, so that what's saved has the abort controller, etc. otherwise it doesn't work to save it prior.
- in disconnect() function
- immediately call clientTransport.terminateSession if transportType is "streamable-http"
- setClientTransport to null