| Filename | Latest commit message | Latest commit date |
|---|---|---|
e72d4307f3* feat(cli): lift config-file headers/timeouts/OAuth into serverSettings (#1482) The CLI resolved file-sourced servers via resolveServerConfigs(), which returns bare MCPServerConfig and dropped disk-level headers, timeouts, and OAuth — CLI connections from a --catalog/--config file silently ignored them. The TUI already lifted these via mcpConfigToServerEntries(). Extract the TUI's catalog/config -> per-server-settings resolution into a shared core module (core/mcp/node/servers.ts: loadServerEntries + selectServerEntry) and route both CLI and TUI through it, so the two share one file->settings path. --header still overrides the file's headers for the run while preserving the file's timeouts/OAuth. - core: add loadServerEntries/selectServerEntry/headersToServerSettings - tui: tui-servers.ts re-exports the shared core helpers (no logic dup) - cli: resolve via loadServerEntries + selectServerEntry; drop the CLI-only conflict check and bare-config path - tests: core servers.test.ts (settings lifting, header merge/override, stdio overrides, seed/error/conflict, selection); CLI integration tests asserting a config header is sent over HTTP and --header overrides it - docs: CLI README note on file settings being applied Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * refactor(core): address #1500 review — dedup overrides, drop dead wrapper, clearer error, spec refresh - Remove the now-unused resolveLaunchServerConfigs() wrapper (both CLI and TUI route through loadServerEntries now); migrate its default-catalog launch tests to compose withDefaultCatalogPath + resolveServerConfigs. - Deduplicate applyStdioOverrides against config.ts applyOverrides: export the latter (now trims cwd) and reuse it in servers.ts. - selectServerEntry's unknown-name error is source-agnostic ("not found" not "not found in config file") since entries may be a single ad-hoc default, where "config file" would mislead. - Refresh specification/ docs (v2_cli_tui_launcher.md, v2_catalog_launch_config.md): CLI/TUI resolution now via loadServerEntries/selectServerEntry; mark gap G1 resolved (#1482); withDefaultConfigPath → withDefaultCatalogPath. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(cli): extend smoke:cli to cover #1482 lift→serverSettings Adds end-to-end smoke coverage for the config-file headers/timeouts/OAuth lift introduced in #1482: - unknown --server now errors source-agnostically ("not found") - multi-server catalog selection via --server (and the omit-it error) - --header merge does not break the stdio connect path - HTTP transport: a config-file `headers` object is lifted onto the wire, and a CLI --header overrides it (verified against an in-process test server's recorded requests via a non-blocking spawn) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
| .. | ||
| screenshots | ||
| README.md | ||
| v1_problems.md | ||
| v2_catalog_launch_config.md | ||
| v2_cli_tui_launcher.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
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