modelcontextprotocol/inspector
Watch
1
0
Fork
You've already forked inspector
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2
inspector/specification/v1_problems.md
olaservo 9d5110f8f4 docs(spec): Restructure UX docs and add visual reference 
Break up v2_ux.md (1400+ lines) into smaller, focused documents:
- v2_ux.md - Core UX (overview, server list, modals)
- v2_ux_features.md - Feature screens (Tools, Resources, etc.)
- v2_ux_handlers.md - Client handlers, form generation, errors
- v2_screenshots.md - Visual reference with Shadcn prototype screenshots

Add screenshots from Shadcn prototype to specification/screenshots/.
Update navigation headers across all spec files.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-17 09:06:08 -07:00

2.6 KiB
Raw Blame History

Inspector V1 Problems

Brief | V1 Problems | V2 Scope | V2 Tech Stack

UX: Overview | Features | Handlers | Screenshots

Table of Contents

Monolithic components

  • Hard to read and maintain
  • Deeply custom:
    • Divs all the way down,
    • Strewn with hundreds of css classes

Solution

  • Make a kit of small, reusable components that are already styled for use anywhere in the app
    • Easier to reason about than inline-customized primitives
    • Minimize css for inline customization
    • Only pass state
  • Define functions to use as handlers rather than writing inline in code
    • Makes component instantiation markup smaller and easier to understand
    • Separates code from markup

Monolithic hooks

  • E.g., useConnection is nearly 1k lines long

Solution

  • Extract inline logic out to function libraries / classes that are easier to reason about and test in isolation

Environment variable explosion

  • We have a configuration file but it is for servers, not things like request timeouts, etc
  • The addition of a new environment variable for everything someone wants to configure is problematic.
    • It’s easy to misspell the variable name and the names
    • Often not named in the best way
    • Lots of touch points to update for a new variable

Solution

  • A JSON configuration file would be a better approach.
    • Hierarchical groups of settings could be used
    • Different files for different configurations
    • Expanding the format to include other settings
    • A configuration file could be validated, so misspelled keys would be caught at startup

Disparate OAuth flows

  • We often have deviations of behavior between basic flow, quick flow, and guided flow
  • Each flow has independent code paths that can break or behave differently from the others

Solution

  • Use a single auth flow mechanism that operates in all three states while supporting different configurations

CLI version combined with UI version

  • Both projects are not kept in parity and do not share significant overlap as to belong in the same repo

Solution

  • Refactor/extract the CLI Inspector to a separate repo for ongoing development