5 of 6 standards met
This draft PR introduces a shared code architecture that enables code reuse across the MCP Inspector's CLI, TUI, and web client interfaces. This addresses the feature drift and maintenance burden caused by the CLI and web client maintaining separate implementations, with immediate code sharing across the CLI and TUI, and planned support for the web client (v2). What's Included 1. TUI Integration Integrated the TUI from as a first-class workspace TUI is accessible via flag Currently experimental; feature gaps include OAuth, completions, elicitation, and sampling 2. Shared Package () Created internal workspace package for shared MCP client code Includes - a comprehensive wrapper around the MCP SDK that manages: Client and transport lifecycle Message tracking and stderr logging Server data management (tools, resources, prompts) Event-driven updates via (cross-platform compatible) High-level MCP method wrappers with automatic parameter conversion 3. CLI Migration Migrated CLI to use from shared package Consolidated CLI helper functions into methods Removed duplicate code (CLI transport implementation, directory, etc) All CLI tests passing 4. Shared React Code hook for reactive state management Works in both TUI and v2 web client (future) Subscribes to events and provides reactive React state Architecture The shared package includes: MCP client/server interaction (, transport creation, config loading) Shared React code (hooks, components, etc.) JSON utilities for parameter conversion Test fixtures and harness servers Both CLI and TUI now use the same implementation, ensuring consistent behavior and eliminating code duplication (both apps are now thin UX-only implementations). Next Steps Phase 4: TUI Feature Gap Implementation (Planned) Address TUI feature gaps (OAuth, completions, elicitation, sampling) by extending This dual-purpose approach: brings TUI to feature parity while preparing for v2 web client integration When complete, will be very close to ready for full v2 web client support Phase 5: v2 Web Client Integration (Planned) Integrate with the v2 web client once Phase 4 is complete and v2 web client is ready Update and other shared code as required to support v2 while maintaining CLI and TUI compatability Documentation See (included in this PR) for: Complete architecture overview capabilities and API Integration history and current usage patterns Detailed web client integration plan Testing All CLI tests passing TUI tested with test harness servers TypeScript Project References ensure correct build ordering CI workflow updated to build shared package first This is a draft PR for review. Feedback welcome on the architecture and integration approach.
The MCP Inspector should utilize the refresh_token to properly validate the token refresh flow. Steps to Reproduce: Use a short-lived access token Log in and wait for the token to expire Send a request (e.g., list/tools) Expected Behavior: The token should be automatically refreshed when expired. Actual Behavior: The request fails with the following error: Additional Issues: Clicking "reconnect" also fails to use the refresh_token A code search confirms that refresh_token is not implemented anywhere in the codebase Impact: This prevents proper evaluation of the Authorization specification, as the refresh token flow cannot be tested.
Repository: modelcontextprotocol/inspector. Description: Visual testing tool for MCP servers Stars: 8910, Forks: 1198. Primary language: TypeScript. Languages: TypeScript (91.1%), JavaScript (7.7%), HTML (0.8%), CSS (0.3%), Dockerfile (0.1%). Homepage: https://modelcontextprotocol.io Latest release: 0.21.1 (6d ago). Open PRs: 60, open issues: 129. Last activity: 3d ago. Community health: 87%. Top contributors: olaservo, cliffhall, jspahrsummers, ashwin-ant, richardkmichael, msabramo, felixweinberger, jerome3o-anthropic, pulkitsharma07, dsp-ant and others.
TypeScript
Last 12 weeks · 110 commits
Inspector Version 0.17.2 Describe the bug I'm currently developing a MCP server that requires OAuth2 authentication. My Authorization Server supports DCR. When I try to connect to my MCP server with MCP Inspector, It sometimes begin authorization code flow with wrong client_id. For example, MCP Inspector created OAuth Client with "http://localhost:6274/oauth/callback/debug", and begins authorization code flow with URL below: https://my-mcp.bryan-test-4324.com/oauth2/authorize?response_type=code&client_id=KpMjPEzpPMSCz085Z_EpKOVqh6lA8HKRIQlg4vO064U&code_challenge=nGiruUmF-q3Ni7iYZZ8FK8tcNMXDS7Sdaqy1iGxMCoE&code_challenge_method=S256&redirect_uri=http%3A%2F%2Flocalhost%3A6274%2Foauth%2Fcallback&state=13a5669e6bb6326968ca68468369bf955958a78260a9a30022f2df26a9e9c0d1&resource=http%3A%2F%2Flocalhost%3A8080%2Fmcp2 as you can see, it requests with redirect_uri "http://localhost:6274/oauth/callback", which is different from what it created. I guess it's MCP Inspector's bug. Could you please check this out? To Reproduce 1. prepare a MCP server that requires OAuth2 authentication 2. prepare a OAuth2 Authorization Server related to the mcp server. 3. make the Authorization Server to support DCR 4. start MCP Inspector 5. click "Open OAuth Settings" button 6. follow the steps 7. on "Request Authorization and acquire authorization code" step, see if this bug happens. It didn't occur everytime I tried, sometimes it did. So I guess it's kind of tricky to reproduce. Expected behavior Start authorization code flow with redirect_uri that MCP Inspector request during DCR. Screenshots If applicable, add screenshots to help explain your problem. Environment (please complete the following information): OS: macOS Sequoia 15.6.1 Browser chrome Additional context Add any other context about the problem here. Version Consideration Inspector V2 is under development to address architectural and UX improvements. See CONTRIBUTING.md for information about V2 development.
Summary Add request-to-response duration display (e.g., "245ms", "2.4s", "1m 30s") as blue badge next to method names Show timestamps for requests and server notifications in collapsed view Display full timing details (requested/responded timestamps with duration) in expanded view Add wrapper for server notifications with receive timestamps Add type with timing fields for request history Note on V2 This feature aligns with V2's existing design - the type in already includes a field, and the V2 UX spec shows timing display. However, V2's timing capture isn't wired up yet. This PR provides the functionality for V1 users in the interim. Test plan [x] passes [x] passes [x] All 459 unit tests pass [x] E2E tests pass (Chromium) [x] Manual testing: connect to MCP server, make requests, verify duration badges appear [x] Manual testing: expand history items and verify full timing details show [x] Manual testing: verify notification timestamps appear correctly 🤖 Generated with Claude Code
Summary Adds support for URL mode elicitation. Updates advertised compatibility, adds some UI functionality, and tests for the changes. NOTE: looks like there's another attempt at this: https://github.com/modelcontextprotocol/inspector/pull/1108 Maintainers, LMK if effort is best spent working with the other PR or what. Note: Inspector V2 is under development to address architectural and UX improvements. During this time, V1 contributions should focus on bug fixes and MCP spec compliance**. See CONTRIBUTING.md for more details. Type of Change [ ] Bug fix (non-breaking change that fixes an issue) [x] New feature (non-breaking change that adds functionality) [ ] Documentation update [ ] Refactoring (no functional changes) [x] Test updates [ ] Build/CI improvements Changes Made Updates the MCP client's advertised compatibility to include the newer object structure that indicates url mode elicitation support. Adds detection of URL mode elicitation 'errors' and raises them to the user. Adds support for accept, deny, and cancel responses. Adds URL mode Elicitation UI to present the URL to the user with buttons to open in a new tab in addition to accept, deny, and cancel responses. Spec Conformance Review Based on the MCP Elicitation Specification (2025-11-25). Conformant 1. Capabilities declaration - Declares elicitation: { form: {}, url: {} } during initialization 2. elicitation/create handling - The onElicitationRequest handler extracts mode, message, requestedSchema, url, and elicitationId from the request. Defaults mode to "form" when omitted, satisfying the backwards compatibility. 3. Response actions - All 3 actions (accept, decline, cancel) implemented 4. Form mode validation - Schema validation via AJV, required field checks, and email format validation are present. 5. URL HTTPS enforcement - Only HTTPS URLs are permitted. 6. URL shown to user before navigation - The full URL is displayed to the user before any navigation occurs. 7. URL not opened without consent 8. URL opened securely - Uses window.open(url, "_blank", "noopener,noreferrer") 9. Domain highlighted 10. Completion notification - ElicitationCompleteNotificationSchema is registered as a notification handler. 11. URLElicitationRequiredError (-32042) - extracts the data.elicitations array and presents URL mode elicitation UI to the user. 12. Type safety for URL mode fields - ElicitationRequestData type is a discriminated union: url and elicitationId are required when mode: "url", and requestedSchema is only available when mode: "form". 13. Clear target server identification - The UI clearly labels requests as "URL Elicitation Request" with the server's message, target domain, full URL, and elicitation ID. 14. Decline and cancel options - Both form and URL mode provide explicit Decline and Cancel buttons. Not Implemented 1. Punycode/suspicious URI warnings (SHOULD) - No detection or warning for ambiguous URIs containing Punycode or homograph attacks. 2. URLElicitationRequiredError retry mechanism - When a -32042 error is caught, the elicitation is displayed to the user but there is no mechanism to automatically or manually retry the original tools/call after the elicitation completes. The spec's flow diagram shows this as optional ("Retry tools/call (optional)"), and the resolve callback on error-originated elicitations is a no-op. The normal elicitation/create flow (server-initiated) works correctly end-to-end. 3. Rate limiting (SHOULD) - No rate limiting on elicitation requests from servers. Related Issues Testing Tested manually with a custom MCP server that supports URL mode Elicitation. Also ran jest and playwright tests. [x] Tested in UI mode [ ] Tested in CLI mode [ ] Tested with STDIO transport [ ] Tested with SSE transport [x] Tested with Streamable HTTP transport [x] Added/updated automated tests [ ] Manual testing performed Test Results and/or Instructions Testing with an MCP server that supports URL mode Elicitation is a challenge, not many support it, let alone advertise support for it. I was testing with a private MCP server that does. Checklist [x] Code follows the style guidelines (ran ) [x] Self-review completed [ ] Code is commented where necessary [ ] Documentation updated (README, comments, etc.) Breaking Changes MCP Servers not built to handle the new compatibility structure changing from to could have unforeseen issues, but perhaps that's unlikely to cause an issue. Additional Context I think it would be nice to add an option to change how this client advertises it's capabilities for testing purposes, to switch between different stages of the spec and manually turn them on and off. That's not included here.
Summary Adds the "form: {}" to the client capabilities. (see https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation#capabilities ) Type of Change [x] Bug fix (non-breaking change that fixes an issue) [ ] New feature (non-breaking change that adds functionality) [ ] Documentation update [ ] Refactoring (no functional changes) [ ] Test updates [ ] Build/CI improvements Changes Made Just added the "form: {}" missing in the client capabilities Testing [x] Tested in UI mode [ ] Tested in CLI mode [x] Tested with STDIO transport [x] Tested with SSE transport [x] Tested with Streamable HTTP transport [ ] Added/updated automated tests [x] Manual testing performed Test Results and/or Instructions A spec compliant server should not have sent elicit requests to the client. Checklist [x] Code follows the style guidelines (ran ) [x] Self-review completed [x] Code is commented where necessary [ ] Documentation updated (README, comments, etc.)