inspector/specification
Repository files (latest commit first)
Filename Latest commit message Latest commit date
cliffhall 1149288ea6 Refactor ServerCard stack to use id-based callbacks
Distinguishes server `id` (the unique map key in MCPConfig.mcpServers)
from `name` (display label) so containers can dispatch by id without
relying on display strings. ServerCard, ConnectionToggle, ServerListScreen,
and supporting stories all updated.

- ServerCard: add `id` prop; all action callbacks now `(id: string) => void`
- ConnectionToggle: collapse `onConnect`/`onDisconnect` into single `onToggle`
- ServerListScreen: lift `activeServer` to a prop; combine `onSetActive` +
  `onToggleConnection` into a single `onToggleConnection(id)` callback
- Stories: use UUIDs for server ids so callbacks visibly carry ids, not names

Removes the "Direct"/"Via Proxy" connection mode concept, which is no
longer planned. ServerSettingsForm drops the section, ServerCard drops
the badge, InspectorServerSettings drops the field.

Removes the "Test Client Features" dropdown from ServerCard along with
its four handlers; that surface will live elsewhere.

TransportBadge now collapses `sse` and `streamable-http` into a single
"HTTP" label; ServerCard adds a grey transport descriptor next to the
badge ("Standard I/O", "SSE (Server Sent Events) [deprecated]",
"Streamable HTTP"). The version badge moves from the header row to sit
beside the transport badge.

ServerCard header no longer wraps; long server names truncate with
ellipsis.

Specification docs (`v2_scope.md`, `v2_screenshots.md`,
`v2_ux_interfaces.md`, `v2_ux_storybook.md`) updated to match.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-25 18:33:38 -04:00
..
screenshots Redesign Resources screen: template panel, subscriptions, hover states, and callback architecture 2026-03-29 20:04:25 -04:00
README.md * Refactored menu on spec pages 2026-03-10 10:22:12 -04:00
v1_problems.md * Refactored menu on spec pages 2026-03-10 10:22:12 -04:00
v2_scope.md Refactor ServerCard stack to use id-based callbacks 2026-04-25 18:33:38 -04:00
v2_screenshots.md Refactor ServerCard stack to use id-based callbacks 2026-04-25 18:33:38 -04:00
v2_server.md * Refactored menu on spec pages 2026-03-10 10:22:12 -04:00
v2_storage.md * Refactored menu on spec pages 2026-03-10 10:22:12 -04:00
v2_ux.md Add v2 UX component interfaces planning document 2026-04-04 19:42:58 -04:00
v2_ux_components.md Add v2 UX component interfaces planning document 2026-04-04 19:42:58 -04:00
v2_ux_features.md Add v2 UX component interfaces planning document 2026-04-04 19:42:58 -04:00
v2_ux_handlers.md Add v2 UX component interfaces planning document 2026-04-04 19:42:58 -04:00
v2_ux_interfaces.md Refactor ServerCard stack to use id-based callbacks 2026-04-25 18:33:38 -04:00
v2_ux_interfaces_phase_0_4_inventory.md Phase 0 foundations for component interfaces refactor 2026-04-15 16:06:23 -04:00
v2_ux_interfaces_plan.md Add Phase 0.3 vetting pass for likely-hedge claims in interfaces doc 2026-04-11 11:34:57 -04:00
v2_ux_storybook.md Refactor ServerCard stack to use id-based callbacks 2026-04-25 18:33:38 -04:00
v2_web_client.md * Refactored menu on spec pages 2026-03-10 10:22:12 -04: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