| Filename | Latest commit message | Latest commit date |
|---|---|---|
55878297d9
Review caught that v2_auth_ema.md contradicted itself. Its "TypeScript SDK (implemented)" section claimed Inspector depends on `@modelcontextprotocol/sdk` v1.x only (`^1.29.0`) and that there is "no `@modelcontextprotocol/client` v2 dependency in the tree today" — while the subsection immediately below it documents which v2 client helpers the EMA legs have adopted. Checked rather than assumed: every module the section's table names imports the v2 client (emaFlow, idpOidc, resourceContext, tokenEndpoint, transportProvider, wire, and providers.ts), and there are zero v1 SDK imports in first-party code. The v1 SDK is present in the tree only as a peer pulled in by ext-apps, which AGENTS.md already states must never become a direct dependency. Rewrote the paragraph to say what is true and name the version, so it stays consistent with the two auth specs corrected in the previous commit. The per-row "v1 SDK" attributions in the table below it are wrong for the same reason, but correcting each one means auditing which SDK symbol each leg calls today — a real audit, not a version-string refresh, and out of scope for a dependency bump. Left for a follow-up rather than guessed at here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HDdo1rNRVQnVRRdsqSrvG3 Signed-off-by: cliffhall <cliff@futurescale.com> |
||
| .. | ||
| diagrams | ||
| screenshots | ||
| README.md | ||
| v1_problems.md | ||
| v2_auth.md | ||
| v2_auth_ema.md | ||
| v2_auth_hardening.md | ||
| v2_auth_mid_session.md | ||
| v2_auth_sdk_consolidation.md | ||
| v2_auth_smoke_testing.md | ||
| v2_catalog_launch_config.md | ||
| v2_cli_tui_launcher.md | ||
| v2_new_spec_impact.md | ||
| v2_scope.md | ||
| v2_screenshots.md | ||
| v2_server.md | ||
| v2_servers_file.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_phase_0_4_inventory.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 | V2 Auth | V2 New Spec Impact
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