inspector/specification
Repository files (latest commit first)
Filename Latest commit message Latest commit date
olaservo b66b674430 docs: revise v2 specs based on PR feedback
Address reviewer feedback from cliffhall, pcarleton, KKonstantinov, mattzcarey:

v2_ux.md changes:
- Add Server Settings Modal for per-server config (headers, metadata, timeouts, OAuth)
- Add Clone button to Server Card Actions
- Add OAuth Debugger section for debugging auth flows
- Change Resources Screen from resizable panes to accordion pattern
- Update Logging Screen to all 8 RFC 5424 levels with distinct colors
- Clarify Browse button as local file picker
- Expand JSON-RPC Tester to support all methods with custom headers
- Add multi-select support for anyOf/oneOf enums in Form Generation

v2_tech_stack.md changes:
- Select Hono over Express based on community consensus
- Add Hono Rationale section with comparison table

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

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-07 21:06:20 -07:00
..
README.md Add v2_ux.md specification with detailed UX patterns 2025-11-29 21:29:46 -07:00
v1_problems.md Add v2_ux.md specification with detailed UX patterns 2025-11-29 21:29:46 -07:00
v2_scope.md Add v2_ux.md specification with detailed UX patterns 2025-11-29 21:29:46 -07:00
v2_tech_stack.md docs: revise v2 specs based on PR feedback 2025-12-07 21:06:20 -07:00
v2_ux.md docs: revise v2 specs based on PR feedback 2025-12-07 21:06:20 -07:00

Inspector V2 Brief

Brief | V1 Problems | V2 Scope | V2 Tech Stack | V2 UX

Table of Contents

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