Problem
Through v1 the Inspector was a follow-along project: the spec moved, we chased it, and whatever planning capacity remained went to keeping up rather than to the tool's own design.
That constraint has lifted. v2 meets the 2026-07-28 spec across Web, CLI, and TUI, on SDK v2, with a shared core/, the ≥90% per-file coverage gate, and a smoke/e2e apparatus. For the first time we can spend planned effort on what the Inspector should be, not only on what the spec just became — but we have no written plan that says so, and no shared list of what we expect the MCP roadmap to demand of us over the next two quarters.
Without one, two things keep happening: spec work arrives as a surprise and gets a bespoke panel, and UX work never gets scheduled because it never competes for a milestone.
Proposal
Add docs/inspector-roadmap-2026-h2.md covering 2026-08-11 → 2027-02-11 (~26 weekly milestones, v2.2.0 → ~v2.27.0), split into two explicitly-budgeted tracks:
Track A — spec-following. Predicted Inspector features per MCP roadmap theme and WG charter, each tagged 🟢 build now / 🟡 design now, build on signal / 🔴 watch:
- Transport evolution and scalability (session lifecycle lane,
Last-Event-ID resumption, proxy/intermediary harness, stateless verification, custom transports)
- Server Cards, SEP-2127 (inspect-before-connect preview; card-vs-reality diff)
- Agent communication / Tasks (retry + expiry semantics, extension→core migration, tasks as timeline spans)
- Enterprise readiness (OTLP export, structured audit transcript, ID-JAG/Cross-App Access, gateway mode)
- Triggers and events (⚠️ makes the Inspector a server — needs a reachable callback endpoint)
- Result type improvements, interceptors (SEP-1763), file uploads (SEP-2356), skills (SEP-2640), primitive grouping, tool annotations
- Conformance and validation
Track B — experience work we choose, headlined by the zoomable protocol/network timeline: lanes, spans rather than points, zoom/pan, brush-to-filter, MRTR and task grouping, a pinned mini-timeline. Then session record/replay/share, a shared diff primitive, ⌘K palette, saved-call collections → CI assertions, the argument-editor workstream, Connection Doctor, workspace/layout, plugin architecture.
Plus a four-phase sequencing section, a "deliberately not doing" section, and open questions for the WG.
Why it is shaped this way
The scheduling argument is that several Track B items are force multipliers for Track A — each new protocol feature arrives with a rendering problem, and one general timeline plus one general diff is cheaper than one bespoke panel per SEP. So the general surfaces are sequenced first.
Two consolidations the survey surfaced, both worth acting on regardless of this doc:
Notes
- The roadmap circulated as a Google Doc requires authentication and could not be read. The doc is built from the published roadmap at
modelcontextprotocol.io/development/roadmap (last updated 2026-03-05) plus the nine WG and six IG charters, and carries a sourcing note saying so. If the private doc holds themes or timelines the public page omits, Track A should be revised against it before adoption.
- The Interceptors WG lists "CLI client for interceptor invocation and testing" as Ideating and unowned. It describes our CLI, and @olaservo co-leads both groups. Raised as an open question rather than assumed.
- Status is Draft for WG review — merging the file starts the discussion, it does not settle it.
Also updates the root README.md guide list and the docs/ entry in the AGENTS.md project tree, per the documentation maintenance rules.
Problem
Through v1 the Inspector was a follow-along project: the spec moved, we chased it, and whatever planning capacity remained went to keeping up rather than to the tool's own design.
That constraint has lifted. v2 meets the 2026-07-28 spec across Web, CLI, and TUI, on SDK v2, with a shared
core/, the ≥90% per-file coverage gate, and a smoke/e2e apparatus. For the first time we can spend planned effort on what the Inspector should be, not only on what the spec just became — but we have no written plan that says so, and no shared list of what we expect the MCP roadmap to demand of us over the next two quarters.Without one, two things keep happening: spec work arrives as a surprise and gets a bespoke panel, and UX work never gets scheduled because it never competes for a milestone.
Proposal
Add
docs/inspector-roadmap-2026-h2.mdcovering 2026-08-11 → 2027-02-11 (~26 weekly milestones,v2.2.0→ ~v2.27.0), split into two explicitly-budgeted tracks:Track A — spec-following. Predicted Inspector features per MCP roadmap theme and WG charter, each tagged 🟢 build now / 🟡 design now, build on signal / 🔴 watch:
Last-Event-IDresumption, proxy/intermediary harness, stateless verification, custom transports)Track B — experience work we choose, headlined by the zoomable protocol/network timeline: lanes, spans rather than points, zoom/pan, brush-to-filter, MRTR and task grouping, a pinned mini-timeline. Then session record/replay/share, a shared diff primitive, ⌘K palette, saved-call collections → CI assertions, the argument-editor workstream, Connection Doctor, workspace/layout, plugin architecture.
Plus a four-phase sequencing section, a "deliberately not doing" section, and open questions for the WG.
Why it is shaped this way
The scheduling argument is that several Track B items are force multipliers for Track A — each new protocol feature arrives with a rendering problem, and one general timeline plus one general diff is cheaper than one bespoke panel per SEP. So the general surfaces are sequenced first.
Two consolidations the survey surfaced, both worth acting on regardless of this doc:
*.localhostdomains #1944, Bug: Failed manual connection leaves un-modifiable ghost server entry #1914) are one missing feature: an ordered diagnostic that says which step failed.Notes
modelcontextprotocol.io/development/roadmap(last updated 2026-03-05) plus the nine WG and six IG charters, and carries a sourcing note saying so. If the private doc holds themes or timelines the public page omits, Track A should be revised against it before adoption.Also updates the root
README.mdguide list and thedocs/entry in theAGENTS.mdproject tree, per the documentation maintenance rules.