| Filename | Latest commit message | Latest commit date |
|---|---|---|
2ef257dab5
The interfaces doc was produced by parallel research subagents that were instructed to prefix uncertain hook names with (likely) rather than fail to fill in a section. The result is 52 instances of "likely" in v2_ux_interfaces.md, almost all attached to hook names that were never cross-checked against v1.5/main. Several are actively wrong: - useTools / usePrompts / useResources do not exist in v1.5; the actual hooks are useManagedTools / useManagedPrompts / useManagedResources. - useTasks does not exist; v1.5 has useManagedRequestorTasks (and Task itself is a raw SDK 1.x type, not an Inspector wrapper). - useMcpClient does not exist; v1.5 has useInspectorClient. - useLogs conflates three v1.5 hooks: useMessageLog, useStderrLog, useFetchRequestLog. - useHistory does not exist; v1.5 uses useMessageLog as the history. - useElicitation / useSampling / useRoots do not exist as discrete React hooks in v1.5; those flows are handled inside InspectorClient via SDK request handlers. - useServerCapabilities is not a separate hook; capabilities live on useInspectorClient's result. - Appendix A's "v1.5 bundles primitive logic in App.tsx" claim is wrong about v1.5 in this repo; that's true of upstream modelcontextprotocol/inspector v1.x mainline, not v1.5/main here, which has the full core/react/* split. Adds Phase 0.3 to walk every (likely) instance and either resolve it against v1.5 source or strike it, with a confirmed rename table and explicit definition-of-done (zero "likely" matches in v2_ux_interfaces.md after the pass). Adds Risk #11 capturing the underlying rule: hedging words next to type/hook/file claims must be vetted before a planning doc ships. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
||
| .. | ||
| screenshots | ||
| README.md | ||
| v1_problems.md | ||
| v2_scope.md | ||
| v2_screenshots.md | ||
| v2_server.md | ||
| v2_storage.md | ||
| v2_ux.md | ||
| v2_ux_components.md | ||
| v2_ux_features.md | ||
| v2_ux_handlers.md | ||
| v2_ux_interfaces.md | ||
| v2_ux_interfaces_plan.md | ||
| v2_ux_storybook.md | ||
| v2_web_client.md | ||
Inspector V2 Brief
Brief | V1 Problems | V2 Scope | V2 Tech Stack | V2 UX
Table of Contents
- Motivation and Context
- Track Protocol Conformance
- Improve Maintainability
- Provide Extensibility
- Proper Documentation
Motivation and Context
The existing Inspector is hard to maintain for a number of reasons. We decided to create a more maintainable Inspector from the ground up, that retains the deterministic boundary of operation, but exposes a plugin architecture.
Track Protocol Conformance
- Identify any gaps in V1 inspector
- Track which features are covered
- Implement to parity and fill gaps
- Provide conformance testing in CI
Improve Maintainability
- Clearer separation of concerns
- Smaller, reusable components
Provide Extensibility
- Plugin SDK / API
- Third parties cand develop/maintain their own plugins for features such as
- LLM usage
- Evals
- Multiple server connections
- Apps playground
- Testing of registry configuration
- Interface with registry
Proper Documentation
- One big README won't cut it anymore
- Published documentation in MDX should
- Render in style of spec
- Kept up to date
- Cover all features
- Discuss troubleshooting strategies
- Provide detailed contribution guidance that explains architecture and expected idioms