Watch

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

1.7 KiB

Raw Blame History

Inspector V2 Brief

Brief | V1 Problems | V2 Scope | V2 Tech Stack

UX: Overview | Features | Handlers | Screenshots

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

1.7 KiB Raw Blame History