docs: re-align the H2 2026 roadmap with the published MCP roadmap and official extensions

[cliffhall]

Closes #2400

The roadmap's first draft (#1980) was written when the MCP roadmap could not be read, so its Track A was built from the 2026-03-05 page. This revises it against the published roadmap (last updated 2026-08-22) and the official extensions list.

What changed

• §1: new sourcing note, plus a table of what has shipped since the first draft (argument editor workstream, Last-Event-ID, server.json, strict validation, connection fixes, EMA, Skills) and what was closed as not planned.
• §3 Track A now follows the roadmap's five priority areas one to one:
  • Agentic messaging: Tasks-into-core moved to Beyond; a new in-flight work lane feeds the composition review.
  • HTTP transport: session-lifecycle work replaced by state handles (SEP-2567/2575 are Final); cache hints from SEP-2549 are 🟢; HTTP over stdio and ETags are on watch.
  • Agent identity: DPoP moves from 🔴 to 🟡; adds WIF, token exchange, and OAuth Client Credentials. Audit and OTLP move to Track B.
  • Improved primitives: result-shape redesign, progressive discovery, a possible annotation deprecation, and a content/structuredContent consistency check.
  • SDK DX: the extension contract and a declaration view.
• §3.7 records efforts the roadmap no longer lists (Server Cards, Interceptors, grouping, streamed results, file pickers, gateways). They are now watch-only.
• §4 Official extensions (new): per-client support table, the one gap (OAuth Client Credentials), the out-of-date upstream client matrix, and an extension-watch sweep so new extensions get issues automatically.
• §5 Track B: renumbered. OTLP is now §5.7; grouping and performance are merged into §5.10.
• §6–§8: sequencing re-phased with Phase 1 shipped items marked; not-doing list and open questions updated.

Docs-only. npm run format and npm run local:gate both pass.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Factual and scope inconsistencies in protocol semantics, client support, and shipped/deferred status should be corrected before approval.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

This docs-only PR realigns the H2 2026 roadmap with the published MCP roadmap and official extensions.

Changes:

• Updates Track A around five MCP priority areas.
• Adds shipped-work history and extension support tracking.
• Rephases Track B, sequencing, and open questions.

File summaries

File	Summary
docs/inspector-roadmap-2026-h2.md	Revised roadmap, extension matrix, watch process, and planning phases.

Review details

Suppressed comments (8)

docs/inspector-roadmap-2026-h2.md:318

• The CLI is not wholly unsupported for MCP Apps: it ships --app-info and collectAppInfo to inspect a tool's UI resource URI, CSP, permissions, and domain. Marking the CLI as — and attributing the absence to rendering makes this per-client table misleading; distinguish Web rendering from the CLI's metadata-probe support (for example, mark it partial and explain the probe).

| MCP Apps                         | `io.modelcontextprotocol/ui`                               | ✅  | —   | —   | ❌ not listed            | Apps tab. Rendering an app needs a browser, so CLI/TUI absence is by design.                            |

docs/inspector-roadmap-2026-h2.md:559

• This rule conflicts with the plan's own §4 and Phase 2: approved official extensions are explicitly treated as spec-following work even though the roadmap does not list extensions, and OAuth Client Credentials is scheduled at line 513. As written, the not-doing rule would prohibit that deliverable; scope it to unlisted WG efforts or explicitly exempt §4.

- **Not scheduling build work outside the published priority areas** (§3.7). A WG effort that
  the roadmap does not list gets a liaison, not milestones.

docs/inspector-roadmap-2026-h2.md:91

• Issue #1944 is not closed as not_planned: GitHub currently marks it completed and links the *.localhost fix PR (#2282). Listing it in this deferred-work sentence misstates the shipped/not-planned split; move it into the connection-fixes row in §1 (or remove it from this sentence).

Closed as **not planned**, so not carried forward: custom transports ([#1741](https://github.com/modelcontextprotocol/inspector/issues/1741)), the configurable-proxy base ([#1684](https://github.com/modelcontextprotocol/inspector/issues/1684)), the readiness summary ([#1916](https://github.com/modelcontextprotocol/inspector/issues/1916)), full panel collapse ([#928](https://github.com/modelcontextprotocol/inspector/issues/928)), `*.localhost` domains ([#1944](https://github.com/modelcontextprotocol/inspector/issues/1944)), and the trusted-local-host OAuth HTTP exception ([#1911](https://github.com/modelcontextprotocol/inspector/issues/1911)).

docs/inspector-roadmap-2026-h2.md:190

• SEP-2549 defines TTL as a freshness hint, not a guarantee: clients may re-fetch while a response is fresh and servers may change data before expiry. These checks would therefore flag compliant behavior as an error. Reframe them as diagnostics/observations, or limit validation to the normative envelope and notification rules.

| **Cache behavior checks** — flag a re-fetch the hints said was unnecessary, and a list that changed inside its declared TTL                          | 🟢         | Inspector-shaped: nobody else observes both the hint and the reality.                                                   |

docs/inspector-roadmap-2026-h2.md:318

• CLI/TUI are not actually absent at the protocol-negotiation layer: the shared InspectorClient applies buildClientExtensions's default io.modelcontextprotocol/ui advertisement, and neither constructor overrides it. That can cause servers to offer Apps to clients that cannot render them. Either stop advertising the extension in non-browser clients or qualify this table as UI rendering support rather than calling the absence intentional.

| MCP Apps                         | `io.modelcontextprotocol/ui`                               | ✅  | —   | —   | ❌ not listed            | Apps tab. Rendering an app needs a browser, so CLI/TUI absence is by design.                            |

docs/inspector-roadmap-2026-h2.md:191

• SEP-2567 deliberately does not define a protocol-level handle: from the wire's perspective the value is ordinary application data, and nothing identifies it to the client. A generic Inspector therefore cannot surface “SEP-2567 state handles” as first-class values without server/schema-specific inference. Please reframe this as a stateful-tool workflow investigation (or defer it) rather than a 🟢 protocol UI item.

| **State handle view** — surface SEP-2567 state handles as first-class values, not opaque fields                                                   | 🟢         | Replaces the first draft's "session lifecycle lane".                                                                    |

docs/inspector-roadmap-2026-h2.md:134

• The confidence legend defines only 🟢, 🟡, and 🔴, but the conformance table uses ✅ for shipped validation. Readers cannot tell whether ✅ is a fourth confidence state or an accidental marker; define ✅ Shipped in the legend so the table's status is unambiguous.

- 🟢 **Build now** — the shape is known (the SEP is Final, or the work is ours alone); blocked only on our own capacity.
- 🟡 **Design now, build on signal** — enough detail to design against; wait for a Draft SEP or a Tier-1 SDK impl before building.
- 🔴 **Watch** — too early to predict a UI; keep a tracking issue and a WG liaison.

docs/inspector-roadmap-2026-h2.md:319

• The CLI cell is marked ✅ for Tasks, but the shipped mcp-inspector --cli explicitly rejects tasks/*: ONE_SHOT_METHODS omits every task method, and the CLI README lists only tools, resources, and prompts. The task branches in runMethod are for an experimental/shared dispatcher, not the public CLI. Please mark this cell unsupported (or label it experimental) so the per-client support table is accurate.

| Tasks                            | `io.modelcontextprotocol/tasks`                            | ✅  | ✅  | ❌  | No column in the matrix  | Raw-wire channel; stays for the horizon (§3.1). No TUI Tasks pane yet.                                                        |

• Files reviewed: 1/1 changed files
• Comments generated: 2
• Review effort level: Lite (auto)

Note

Copilot is running an experiment and ran this review at Lite.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[cliffhall]

Copilot review (5228959370), addressed in 298cce3. Inline replies are on both threads. Each claim below was checked against the code, issue state, or spec before acting.

Inline (2)

• ttlMs "only in tests": fixed. The runtime already honors the hints through the SDK list cache; the gap is now described as display.
• content/structuredContent check: fixed. Scoped to both-present-and-disagree, or missing when an outputSchema requires it.

Suppressed (8)

1. CLI — for MCP Apps: fixed. The CLI cell is now 🟡 for the --app-info metadata probe, and the columns are labelled as rendering support.
2. Not-doing rule conflicts with §4: fixed. Approved official extensions are explicitly exempt.
3. Add support for *.localhost domains #1944 is completed: declined. GitHub reports Add support for *.localhost domains #1944 as CLOSED / NOT_PLANNED, so it stays in the not-planned sentence.
4. TTL checks flag compliant behavior: fixed. Per the caching utility's note ("a freshness hint, not a guarantee"), these are now observations reported as diagnostics, not errors.
5. CLI/TUI advertise io.modelcontextprotocol/ui: qualified in the doc. Verified that the registry entry defaults to advertised and neither CLI nor TUI overrides it. The table now says so rather than calling the absence "by design". Whether the non-browser clients should stop advertising it is a code question outside this docs PR.
6. SEP-2567 handles aren't protocol-level: fixed. The spec's Stateful Tools note confirms "the protocol has no concept of a state handle". The item is now a 🟡 stateful-tool workflow investigation, here and in §6.
7. ✅ missing from the legend: fixed. ✅ Shipped is added.
8. CLI Tasks ✅: fixed. Now ❌; ONE_SHOT_METHODS omits tasks/*, and the one-shot CLI rejects them.

Prettier also re-aligned the file's tables (it was not previously formatted), which widens the diff.

[Copilot]

🔵 Needs a closer look

Two moderate roadmap-policy inconsistencies and related documentation nits remain unresolved.

Review details

Suppressed comments (5)

docs/inspector-roadmap-2026-h2.md:245

• The missing-structuredContent case is already implemented by validateToolOutput for non-error results and covered by toolOutputValidation.test.ts; it is not part of the proposed new work. Please keep this roadmap item focused on comparing content and structuredContent when both are present, and describe the output-schema validation as shipped so the plan does not re-schedule completed functionality.

| **`content` / `structuredContent` consistency check** — flag results where both are present and disagree, or where a declared `outputSchema` requires `structuredContent` and it is missing | 🟢         | Useful today, and implementation evidence for the Core Primitives WG.                                                    |

docs/inspector-roadmap-2026-h2.md:104

• Section 4 and Phase 2 classify approved official extensions as Track A work, but this trigger never admits them: an approved extension such as OAuth Client Credentials has no SEP Draft/Final gate and would be excluded by this rule despite being scheduled in Phase 2. Add approved official extensions (or an equivalent readiness condition) to the trigger so the policy and sequencing agree.

| **Trigger to start**        | A SEP reaches Draft with a Tier-1 SDK reference impl, or is Final | Whenever we have capacity                   |

docs/inspector-roadmap-2026-h2.md:323

• The upstream client matrix does list an MCP Inspector row; its MCP Apps cell is simply blank. ❌ not listed therefore misstates the source and makes this support table inaccurate. Please use blank/not marked here and keep the action focused on filling that cell.

| MCP Apps                         | `io.modelcontextprotocol/ui`                               | ✅  | 🟡  | —   | ❌ not listed           | Apps tab. Columns are rendering support: rendering needs a browser, so the CLI has only the `--app-info` metadata probe and the TUI nothing. The shared client still advertises the extension from CLI and TUI. |

docs/inspector-roadmap-2026-h2.md:326

• The upstream client matrix does list an MCP Inspector row; its Enterprise Auth cell is simply blank. ❌ not listed therefore misstates the source and makes this support table inaccurate. Please use blank/not marked here and keep the action focused on filling that cell.

| Enterprise-Managed Authorization | `io.modelcontextprotocol/enterprise-managed-authorization` | ✅  | ✅  | ✅  | ❌ not listed           | [#1509](https://github.com/modelcontextprotocol/inspector/issues/1509).                                                                                                                                         |

docs/inspector-roadmap-2026-h2.md:342

• This sweep is described as modeled on scripts/sdk-watch.mjs, but milestoned at triage conflicts with this repo's issue workflow: v2 issues created by automation get the current milestone when filed, and only the no-open-milestone case is left unmilestoned for Incoming (AGENTS.md:370, scripts/sdk-watch.mjs:841-850). As written, an official-extension issue would be treated as awaiting approval rather than like the other scheduled watches. Please state that the sweep assigns the current milestone when it files, with the documented no-milestone exception.

- **Official extension** → a `v2` + `enhancement` issue to implement it, milestoned at triage.

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite (auto)

Note

Copilot is running an experiment and ran this review at Lite.

[cliffhall]

Copilot review round 2 (5229513225): fixed in 3961bd1. This round had no inline comments, so every finding is answered here. I checked each one against the code or upstream source before changing anything.

Suppressed (5)

1. content/structuredContent item repeats shipped work: fixed. core/mcp/toolOutputValidation.ts (validateToolOutput) already flags an outputSchema with no structuredContent on a non-error result. The roadmap item now covers only results where both are present and disagree, and notes that the missing-field case has shipped.
2. Track A start trigger excludes approved extensions: fixed. The trigger now reads "…or an extension is approved as official (§4)", which matches the Phase 2 scheduling of OAuth Client Credentials.
3. Apps "not listed" misstates the matrix: fixed. The matrix does have an MCP Inspector row; its Apps cell is blank. The table now says "Inspector row, cell blank".
4. EMA "not listed": fixed. Same change as 3. I also reworded the §4 action to fill in the blank Apps and Enterprise Auth cells and update the Skills cell.
5. Extension-watch "milestoned at triage": fixed. sdk-watch.mjs calls currentMilestone() when it files an issue and leaves it unmilestoned only when no dated milestone is open. §4 now says the extension sweep works the same way.

npm run format and npm run local:gate both pass.

[Copilot]

🔵 Needs a closer look

The proposed content/structuredContent validation item needs a defined contract before approval.

Review details

Suppressed comments (3)

Previously missed (1) — in code that hasn't changed since the last review.

docs/inspector-roadmap-2026-h2.md:13

• Could this worklist be committed under docs/ or linked from a stable public page instead of only from claude.ai/artifact/...? Standard Claude artifact links require a Claude account and can be unpublished or changed, so readers cannot reliably inspect the list behind this public roadmap and the “no external blockers” section loses its source.

docs/inspector-roadmap-2026-h2.md:245

• content is the unstructured result and structuredContent is a separate optional JSON value; the current ToolResultPanel even documents that content blocks often summarize the structured output. A compliant response can therefore have both fields with intentionally different values, so a generic “both present and disagree” check would report false bugs. Please restrict this to an explicitly defined serialization/canonical case (or make that contract a prerequisite) before treating it as a 🟢 validation item.

| **`content` / `structuredContent` consistency check** — flag results where both are present and disagree | 🟢         | Useful today, and implementation evidence for the Core Primitives WG. A missing `structuredContent` under a declared `outputSchema` is already flagged by `validateToolOutput` (shipped).                                                    |

docs/inspector-roadmap-2026-h2.md:330

• The proposed upstream matrix update cannot represent the support table above as written: the matrix has one combined “MCP Inspector” row, while this document says Web fully renders Apps, CLI only exposes metadata probing, and TUI does not render Apps. Filling that single Apps cell with a check would overstate support for the non-Web clients. Please request split Web/CLI/TUI rows, or an explicit partial-support notation, before filling the Apps cell.

**Actions:** implement OAuth Client Credentials; and, with maintainer sign-off, open a PR on
`modelcontextprotocol/modelcontextprotocol` to fill in the Inspector row's blank Apps and Enterprise Auth cells and update its Skills cell in the client matrix.

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite (auto)

Note

Copilot is running an experiment and ran this review at Lite.

[cliffhall]

Copilot review round 3 (5229573720): addressed in 9741759. This round had no inline comments, so all three findings are answered here.

Suppressed (3)

1. The unblocked-work list is linked only as a claude.ai artifact: declined. The artifact is published publicly, and the maintainer chose the link on purpose. The list is a working catalog that changes as issues are filed, so it lives on that page. The roadmap sections it summarizes stay in this doc.
2. A generic "both present and disagree" check would report false bugs: fixed. Agreed: a text block that differs from the structured output can be a legitimate summary. The 2026-07-28 spec defines one relationship between the two fields ("a tool that returns structured content SHOULD also return the serialized JSON in a TextContent block"). The item is now scoped to that relationship only. It reports a diagnostic, never an error, and does not compare other text. I narrowed the §3.4 paragraph and the §6 bullet to match.
3. One upstream matrix row can't show per-client support: fixed. The §4 action now proposes marking Apps and Skills as partial, with a link explaining the split, or proposing separate Web/CLI/TUI rows. Enterprise Auth stays a plain check.

npm run format and npm run local:gate both pass.

[Copilot]

🔵 Needs a closer look

Two moderate findings and six factual or wording corrections remain unresolved.

Review details

Suppressed comments (8)

Previously missed (1) — in code that hasn't changed since the last review.

docs/inspector-roadmap-2026-h2.md:328

• The cited upstream matrix does not mark OAuth Client Credentials as unsupported: the MCP Inspector row's OAuth cell is blank, just like its Apps and Enterprise Auth cells. Because this table uses ❌ for the Inspector's unsupported clients and separately reports the upstream matrix, this cell currently misstates the cited source; use Inspector row, cell blank here.

docs/inspector-roadmap-2026-h2.md:88

• Please call this the shipped tool-schema portability lint, not strict JSON Schema validation. The implementation in core/json/schemaLint.ts explicitly is not a JSON Schema validator, and --strict reports schema_unportable findings for schemas that are valid JSON Schema but unsupported by some clients. The current label overstates what #1005/#1015 delivered.

| Strict JSON Schema validation                                                               | [#1005](https://github.com/modelcontextprotocol/inspector/issues/1005), [#1015](https://github.com/modelcontextprotocol/inspector/issues/1015)                                                                                                                                                                                                                                                                                                 |

docs/inspector-roadmap-2026-h2.md:238

• The published roadmap mentions “results that stream” in the Agentic Messaging framing, even though streaming is not one of that section’s “This roadmap period” deliverables. Calling the first draft’s streamed results “not on the published roadmap” overstates the change; narrow this to not being prioritized for this period (reference results can remain watch-only).

in richer annotation rendering now. The first draft's §3.6 (streamed and reference results)
and §3.8 (the SEP-2356 file picker) are **not on the published roadmap** and move to watch.

docs/inspector-roadmap-2026-h2.md:85

• The 2026-07-28 protocol removed SSE resumability and event IDs; Inspector retains Last-Event-ID only for the legacy Streamable HTTP path (core/mcp/types.ts:939-953, specification/v2_new_spec_impact.md:260). Please label this shipped item as legacy-only, and apply the same qualifier to the repeated Phase 1 entry, so this 2026 roadmap does not imply that modern transport still has this feature.

| `Last-Event-ID` resumption                                                                  | [#920](https://github.com/modelcontextprotocol/inspector/issues/920)                                                                                                                                                                                                                                                                                                                                                                           |

docs/inspector-roadmap-2026-h2.md:164

• Tasks is not part of the base 2026-07-28 protocol; the published documentation describes it separately as the io.modelcontextprotocol/tasks extension. Since §4 explicitly distinguishes official extensions from the base roadmap, saying all three already exist in the spec is misleading. Qualify this as the protocol/extension set and identify Tasks as the extension.

| **In-flight work lane** — tasks, open `subscriptions/listen` streams and progress-reporting requests as spans on one timeline lane (§5.1)          | 🟢         | All three already exist in the 2026-07-28 spec. Makes composition gaps (mismatched cancellation, divergent errors) visible, which the WG can use. |

docs/inspector-roadmap-2026-h2.md:344

• compare with a committed list and This table is the record are incompatible with the stated files issues, never PRs: after the first issue is filed, neither the list nor table is changed by the sweep, so the same extension remains “new” and will be filed again on every run unless issue markers are the real source of truth. Please define the idempotency/update path or make the list/table explicitly maintainer-maintained.

- **An extension-watch sweep**, modelled on `scripts/sdk-watch.mjs`: on a schedule, list the
  org's `ext-*` and `experimental-ext-*` repositories and the extension identifiers on
  `/extensions/overview`, compare with a committed list of the ones we have assessed, and file
  one issue per new entry. It **files issues, never PRs**, and trusts only markers the
  automation wrote, exactly as the SDK watch does.

docs/inspector-roadmap-2026-h2.md:303

• This row says payload truncation covers the large-result case today, but §5.10 describes truncation as future Track B work and the current result views still render full payloads. That makes a watch-only item sound already handled; describe the truncation as planned rather than current.

| **Streamed and reference results**                    | Incremental rendering, reference handles                     | 🔴 Watch. Payload truncation in §5.10 covers the large-result case today.                                                          |

docs/inspector-roadmap-2026-h2.md:186

• SEP-2575/2567 remove sessions from the modern 2026-07-28 era, but this repository remains a dual-era client whose default negotiation is legacy; legacy Streamable HTTP still uses initialize and session-scoped state. Calling the session lifecycle lane obsolete without carving out legacy removes a useful planned/debugging surface for a supported mode. Scope this conclusion to modern connections and retain or explicitly defer the legacy lane.

**Read:** The first draft's §3.1 (stateless Streamable HTTP, session creation / resumption /
migration) is **largely obsolete**: SEP-2575 (stateless) and SEP-2567 (sessionless, explicit
state handles) are Final and already shipped. A "session lifecycle lane" describes a model the
spec has left behind; what remains to show is **state handles**. Caching, on the other hand, is
Final and we already parse the fields — we just do not render them, and a client that shows

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite (auto)

Note

Copilot is running an experiment and ran this review at Lite.

[cliffhall]

Copilot review round 4 (5236911488): all 8 fixed in a9453bd. This round had no inline comments, so every finding is answered here.

Suppressed (8)

1. OAuth Client Credentials matrix cell: fixed. The upstream cell is blank, not marked unsupported, so it now reads "Inspector row, cell blank".
2. "Strict JSON Schema validation" overstates what shipped: fixed. core/json/schemaLint.ts says it is deliberately not a validator. It is now called a tool-schema portability lint (--strict).
3. Streamed results "not on the roadmap": fixed. Now reads "not prioritized deliverables for this period", noting the roadmap mentions "results that stream" only in its framing.
4. Last-Event-ID is legacy-only: fixed in the §1 table and in Phase 1.
5. Tasks is not base spec: fixed. The in-flight work lane now says subscriptions/listen and progress are spec features and Tasks is the official extension.
6. Extension sweep idempotency: fixed. As in sdk-watch, issue markers on automation-authored issues are the source of truth. Nothing is committed back, and the §4 table is maintained by maintainers.
7. Truncation described as current: fixed. Now described as planned; result views render full payloads today.
8. Session lifecycle lane dropped for a supported era: fixed. The obsolescence is scoped to modern connections. A legacy-era session lane is kept as a deferred timeline follow-up.

npm run format and npm run local:gate both pass.

[Copilot]

🔵 Needs a closer look

Unresolved documentation accuracy, sourcing, and extension-sweep idempotency issues should be corrected before approval.

Review details

Suppressed comments (10)

docs/inspector-roadmap-2026-h2.md:348

• Like the existing scripts/sdk-watch.mjs:176-219 guard, this idempotency rule should require both the automation author and the labels owned by the sweep before trusting a marker. The official/experimental paths below use v2 plus enhancement/question; require that expected label pair for the entry as well, otherwise the marker-authentication invariant is underspecified.

  are the source of truth** for idempotency: an entry whose marker is on an existing issue (open or
  closed) authored by the automation is skipped, so nothing needs committing back. It **files
  issues, never PRs**, and trusts only markers the automation wrote.

docs/inspector-roadmap-2026-h2.md:511

• Phase 1 is described as being annotated with shipped work, but this list omits the strict schema validation and server-configuration work explicitly recorded as shipped in §1 (and strict validation is also marked ✅ in §3.6). Add those items or state that the list is selective; otherwise the sequence can make completed work look unscheduled.

- ✅ `Last-Event-ID` resumption, legacy only (#920); discover checkmarks (#1887); `server.json` (#922)
- ✅ Argument editor workstream (six issues); connection fixes (§1)
- ✅ Skills over MCP (#2234, #2248); Enterprise-Managed Authorization (#1509)

docs/inspector-roadmap-2026-h2.md:316

• This comma joins two independent clauses. Use a semicolon or add a conjunction so the new sourcing paragraph is grammatically correct.

[`/extensions/overview`](https://modelcontextprotocol.io/extensions/overview), implementations

docs/inspector-roadmap-2026-h2.md:292

• core/json/schemaLint.ts explicitly says this feature is deliberately not a JSON Schema validator; it reports only a narrower set of portability findings. Marking “Strict schema validation” as shipped therefore claims a broader capability than the implementation provides. Please rename this row to the shipped portability lint, or keep full schema validation unscheduled.

| **Strict schema validation with actionable errors**                                               | ✅         | Shipped — [#1005](https://github.com/modelcontextprotocol/inspector/issues/1005), [#1015](https://github.com/modelcontextprotocol/inspector/issues/1015). |

docs/inspector-roadmap-2026-h2.md:314

• The published roadmap does mention Tasks/SEP-2663 in the Agentic Messaging section, including its “Beyond” placement, so saying it “does not list extensions” is too broad. Please clarify that it lacks a complete official-extension inventory; that preserves the rationale for §4 without contradicting §3.1.

The MCP roadmap does not list extensions, but **approved extensions are spec-following work** —

docs/inspector-roadmap-2026-h2.md:611

• Transports WG is named as the upstream owner in both §3.1 and §3.2, and its published charter exists, but the new Sources list omits it. Add that charter link so the transport-specific claims in this revised roadmap remain directly verifiable.

- WG charters: [Inspector V2](https://modelcontextprotocol.io/community/working-groups/inspector-v2) · [Triggers & Events](https://modelcontextprotocol.io/community/working-groups/triggers-events) · [Agents](https://modelcontextprotocol.io/community/working-groups/agents) · [File Uploads](https://modelcontextprotocol.io/community/working-groups/file-uploads) · [SDK](https://modelcontextprotocol.io/community/working-groups/sdk)

docs/inspector-roadmap-2026-h2.md:92

• The section is explicitly “shipped since the first draft”, but #1509 was completed on 2026-06-25 while #1980 (the first draft) was created on 2026-08-11. Only #1937 is a post-draft delivery here; split the row or label the EMA entry as pre-existing so the history is not wrong.

| Enterprise-Managed Authorization; IdP OIDC option                                           | [#1509](https://github.com/modelcontextprotocol/inspector/issues/1509), [#1937](https://github.com/modelcontextprotocol/inspector/issues/1937)                                                                                                                                                                                                                                                                                                 |

docs/inspector-roadmap-2026-h2.md:249

• This reintroduces the overly broad consistency rule: structuredContent is optional unless an outputSchema requires it, and the serialized-text guidance is a SHOULD. As written, it would flag compliant results with no matching text block and would miss a present-but-different serialized block. Scope the diagnostic to both forms being present but disagreeing, or to missing structuredContent under a declared output schema, and keep it advisory.

| **Serialized-JSON check for `structuredContent`** — when a result carries `structuredContent`, flag the absence of a `TextContent` block holding its serialized JSON, the one relationship the spec defines (a SHOULD, "for backwards compatibility"). Reported as a diagnostic, never an error; any other text is a legitimate summary and is not compared | 🟢 | Useful today, and implementation evidence for the Core Primitives WG. A missing `structuredContent` under a declared `outputSchema` is already flagged by `validateToolOutput` (shipped). |

docs/inspector-roadmap-2026-h2.md:90

• #1936 did not make self-signed HTTPS connections work by default: it was closed after documenting NODE_EXTRA_CA_CERTS / NODE_TLS_REJECT_UNAUTHORIZED workarounds, and the current environment guide still says a self-signed https://localhost server fails without explicit trust configuration. Calling this a shipped connection fix overstates the result; label this part as connection guidance/documentation.

| Connection fixes (version-negotiation DX, `https://localhost`, dev containers, ghost entry) | [#962](https://github.com/modelcontextprotocol/inspector/issues/962), [#1936](https://github.com/modelcontextprotocol/inspector/issues/1936), [#1951](https://github.com/modelcontextprotocol/inspector/issues/1951), [#1914](https://github.com/modelcontextprotocol/inspector/issues/1914)                                                                                                                                                   |

docs/inspector-roadmap-2026-h2.md:348

• The marker-only idempotency scheme is not safe on its first run: the already-shipped Skills work is tracked by #2234/#2248 and EMA by #1509, but those existing issues have no automation marker. The sweep would therefore file duplicate official-extension issues even though the table says those extensions are supported. Bootstrap markers for existing issues or match existing version-specific issues before applying the marker check; choose and document one of those policies.

  `/extensions/overview`, and file one issue per entry it has not filed before. As in the SDK watch, the **issue markers
  are the source of truth** for idempotency: an entry whose marker is on an existing issue (open or
  closed) authored by the automation is skipped, so nothing needs committing back. It **files
  issues, never PRs**, and trusts only markers the automation wrote.

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite (auto)

Note

Copilot is running an experiment and ran this review at Lite.

[cliffhall]

Copilot review round 10 (5238424470): all 6 fixed in 1a6df14, plus one new issue. This round had no inline comments, so every finding is answered here.

Suppressed (6)

1. [Blocked upstream] Tasks requests over Streamable HTTP omit the required Mcp-Name header (SEP-2663) #1917 is not a web-only limitation: fixed. The shared InspectorClient issues the tasks/* requests, so all three clients are marked partial. The CLI/TUI lack of a task surface is now stated separately.
2. EMA ✅ overstates CLI/TUI: fixed. Now 🟡 for both, since they work only from hand-edited client.json/mcp.json and have terminal follow-ups outstanding (specification/v2_auth_ema.md).
3. Blanket "nothing waits" claim in Track B: fixed. Now reads: nothing waits on an outside project to start, while some later parts depend on each other or on Track A.
4. Modern skills/get must carry cache fields: fixed, and filed Modern skills/get results must carry ttlMs and cacheScope (ext-skills stable spec) #2404. Verified in ext-skills specification/stable/skills.mdx: "GetSkillResult extends CacheableResult, so ttlMs and cacheScope are REQUIRED". core/mcp/skillsSchemas.ts still treats them as optional, which is a real conformance gap, so it is filed as Modern skills/get results must carry ttlMs and cacheScope (ext-skills stable spec) #2404 (v2.8.0). The cache row now includes modern skills/get and links Modern skills/get results must carry ttlMs and cacheScope (ext-skills stable spec) #2404.
5. SEP-1932/1933 not linked: fixed. Both link to their proposals.
6. Capping history would lose data from the session file: fixed. Restored spill-to-disk, so evicted entries still reach the §5.2 session file.

npm run format and npm run local:gate both pass.

[Copilot]

🔵 Needs a closer look

A moderate extension-tracking gap and several documentation accuracy issues remain unresolved.

Review details

Suppressed comments (7)

docs/inspector-roadmap-2026-h2.md:331

• client.json and mcp.json are not necessarily hand-edited: the Web Client/Server Settings flows write these settings, and CLI/TUI consume the resulting files and keychain state. The actual limitation is that CLI/TUI have no in-client Client Settings surface; please narrow this wording so it does not misdescribe the supported cross-client workflow.

| Enterprise-Managed Authorization | `io.modelcontextprotocol/enterprise-managed-authorization` | ✅  | 🟡  | 🟡  | Inspector row, cell blank | [#1509](https://github.com/modelcontextprotocol/inspector/issues/1509). CLI and TUI work only from hand-edited `client.json` / `mcp.json`: there is no Client Settings surface, and terminal EMA follow-ups remain (`specification/v2_auth_ema.md`).                                                                                                                                         |

docs/inspector-roadmap-2026-h2.md:329

• The Mcp-Name requirement is transport-specific: SEP-2663 requires it for these task methods when sent over Streamable HTTP, while stdio has no HTTP header. Since this row summarizes support across transports, add that scope here; otherwise it reads as though every modern tasks/* request is invalid and every strict server rejects it.

| Tasks                            | `io.modelcontextprotocol/tasks`                            | 🟡  | 🟡  | 🟡  | No column in the matrix | Raw-wire channel; stays for the horizon (§3.1). All three clients are partial until #1917 ships: the shared `InspectorClient` issues modern `tasks/*` requests without the required `Mcp-Name` header, so strict servers reject them. Separately, CLI and TUI advertise the extension and the shared core supports it, but neither exposes a user-facing task surface: the CLI's one-shot mode rejects `tasks/*`, and the TUI has no Tasks pane.                                                                                               |

docs/inspector-roadmap-2026-h2.md:352

• #1225 is also the hand-filed issue for the OAuth Client Credentials extension, which this table identifies as the remaining gap, but it is omitted from the bootstrap list. Because that issue is closed on the frozen v1 line, the sweep needs an explicit rule to create or migrate a v2 tracking issue; otherwise this process can either file an unexplained duplicate or suppress the only planned v2 work.

  already tracked by hand-filed issues (Apps #1740, Tasks #1887, Skills #2234, EMA #1509), so that it does not file duplicates.

docs/inspector-roadmap-2026-h2.md:13

• This new section makes a Claude artifact the only source for the unblocked-work inventory. The artifact is neither committed nor versioned with the roadmap, so its contents can disappear or change outside review and readers cannot rely on having access to it; please inline the list or keep it in a committed docs/ file.

[Inspector Unblocked Work](https://claude.ai/artifact/MTFGsTVbKCqMchA1JYHo83) lists the roadmap items that depend on nothing outside this repo.

docs/inspector-roadmap-2026-h2.md:329

• #1917 only addresses the shared modern-header defect; it does not give CLI or TUI a task UI (the remainder of this sentence says the CLI rejects tasks/* and TUI has no Tasks pane). As written, “all three clients are partial until #1917 ships” implies they become complete afterward. Please say that all three are currently partial and distinguish the web header blocker from the CLI/TUI surface gaps.

| Tasks                            | `io.modelcontextprotocol/tasks`                            | 🟡  | 🟡  | 🟡  | No column in the matrix | Raw-wire channel; stays for the horizon (§3.1). All three clients are partial until #1917 ships: the shared `InspectorClient` issues modern `tasks/*` requests without the required `Mcp-Name` header, so strict servers reject them. Separately, CLI and TUI advertise the extension and the shared core supports it, but neither exposes a user-facing task surface: the CLI's one-shot mode rejects `tasks/*`, and the TUI has no Tasks pane.                                                                                               |

docs/inspector-roadmap-2026-h2.md:329

• The CLI does not reject all tasks/* methods: runMethod handles tasks/list, tasks/get, tasks/cancel, and tasks/result (see clients/cli/src/handlers/run-method.ts:294-317), and the CLI README lists them as supported. Please describe the CLI's limited one-shot support and missing task monitor/tasks/update rather than stating that it rejects tasks/*.

| Tasks                            | `io.modelcontextprotocol/tasks`                            | 🟡  | 🟡  | 🟡  | No column in the matrix | Raw-wire channel; stays for the horizon (§3.1). All three clients are partial until #1917 ships: the shared `InspectorClient` issues modern `tasks/*` requests without the required `Mcp-Name` header, so strict servers reject them. Separately, CLI and TUI advertise the extension and the shared core supports it, but neither exposes a user-facing task surface: the CLI's one-shot mode rejects `tasks/*`, and the TUI has no Tasks pane.                                                                                               |

docs/inspector-roadmap-2026-h2.md:615

• SEP-414 is cited in §5.7 as the basis for the OTLP trace-context fields, but it is missing from the Final SEPs cited source list. Please add it so the new observability item remains traceable from the document's sources.

- Final SEPs cited: [SEP-2549 (TTL for list results)](https://modelcontextprotocol.io/seps/2549-TTL-for-list-results) · [SEP-2567 (sessionless)](https://modelcontextprotocol.io/seps/2567-sessionless-mcp) · [SEP-2575 (stateless)](https://modelcontextprotocol.io/seps/2575-stateless-mcp) · [SEP-2663 (Tasks extension)](https://modelcontextprotocol.io/seps/2663-tasks-extension) · [SEP-2640 (Skills extension)](https://modelcontextprotocol.io/seps/2640-skills-extension) · [SEP-2484 (conformance tests)](https://modelcontextprotocol.io/seps/2484-conformance-tests-required-for-final-seps)

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite (auto)

Note

Copilot is running an experiment and ran this review at Lite.

[cliffhall]

Copilot review round 11 (5238614603): 5 fixed and 2 declined, in 8be1cd6. This round had no inline comments, so all 7 are answered here.

Suppressed (7)

1. "Hand-edited" misdescribes EMA config: fixed. The limitation is now stated as no in-client Client Settings surface; CLI/TUI consume the files and keychain state the web settings flows write.
2. Mcp-Name is Streamable-HTTP-only: fixed. The row now scopes the requirement to Streamable HTTP and says stdio is unaffected.
3. Support OAuth 2.0 client_credentials grant type #1225 missing from the bootstrap: fixed. OAuth Client Credentials is now named as the exception. Its only issue is closed on v1, so a new v2 issue is filed deliberately, cross-referencing Support OAuth 2.0 client_credentials grant type #1225.
4. Artifact is the only source for the unblocked list: declined. Same finding as round 3. The link is public, and the maintainer chose it on purpose.
5. "Partial until [Blocked upstream] Tasks requests over Streamable HTTP omit the required Mcp-Name header (SEP-2663) #1917 ships" implies CLI/TUI become complete: fixed. The row now gives two separate reasons for partial support: the header gap [Blocked upstream] Tasks requests over Streamable HTTP omit the required Mcp-Name header (SEP-2663) #1917 fixes, and the CLI/TUI surface gap it does not.
6. The CLI does not reject tasks/*: declined, the code shows otherwise. clients/cli/src/cli.ts:1000 rejects any method for which isOneShotMethod is false. ONE_SHOT_METHODS (clients/cli/src/handlers/method-types.ts:128) does not include tasks/*, and its doc comment says they "are rejected so the CLI never hangs waiting for SIGINT". The tasks/* branches in runMethod are reachable only from the session dispatcher, not from mcp-inspector --cli, which is what round 1 found. The row now names ONE_SHOT_METHODS as the source.
7. SEP-414 missing from Sources: fixed.

npm run format and npm run local:gate both pass.

[Copilot]

🟡 Changes recommended

Unresolved documentation navigation and accuracy issues must be addressed before approval.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (5)

docs/inspector-roadmap-2026-h2.md:13

• The new top-level “Work we can start now, no external blockers” section is absent from the manually maintained Table of Contents, so the document's navigation omits this new content. Add it to the ToC.

## Work we can start now, no external blockers

[Inspector Unblocked Work](https://claude.ai/artifact/MTFGsTVbKCqMchA1JYHo83) lists the roadmap items that depend on nothing outside this repo.

docs/inspector-roadmap-2026-h2.md:337

• The table correctly notes that the upstream matrix has no Tasks column, but this action only proposes updating Apps, Skills, and Enterprise Auth. Since Tasks is also an official extension, updating just the Inspector row will leave the matrix unable to represent one of the five extensions; please include adding a Tasks column (or explicitly explain why it is excluded) in the proposed update.

**Actions:** implement OAuth Client Credentials; and, with maintainer sign-off, open a PR on
`modelcontextprotocol/modelcontextprotocol` to update the Inspector row. That matrix has one row per product,
so it cannot represent the Inspector's separate Web, CLI and TUI clients: mark Apps as partial with a link explaining the split (Apps renders in
Web only; the CLI has a metadata probe), or propose separate Web/CLI/TUI rows. Skills and Enterprise Auth can be plain checks.

docs/inspector-roadmap-2026-h2.md:313

• This revision adds a substantial standalone roadmap section, but the root README's Documentation table (README.md:68-83) still does not link docs/inspector-roadmap-2026-h2.md; the other docs plans are indexed there. Please add the roadmap to that index so the revised planning document remains discoverable under the repository's documentation convention.

## 4. Official extensions

docs/inspector-roadmap-2026-h2.md:119

• SEP-2484 does not require conformance tests for every Standards Track SEP: its requirement applies to SEPs that change observable protocol behavior (with process/informational exceptions). This sentence is broader than the cited policy; please add that qualifier.

against, and SEP-2484 (Final) requires conformance tests for Standards Track SEPs to reach

docs/inspector-roadmap-2026-h2.md:305

• SEP-1763 is the older Interceptors motivation issue; the current submitted proposal and experimental implementation are tracked as SEP-2624. Listing only SEP-1763 makes this watch item point at the stale proposal identifier; please include the current ID (and retain the original as context if useful).

| **Interceptors** (SEP-1763)                           | Test bench, audit mode, CLI invocation in Phase 4            | 🔴 Watch. The WG's unowned "CLI client for interceptor invocation" is still worth raising (§8).                                    |

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite (auto)

Note

Copilot is running an experiment and ran this review at Lite.

[cliffhall]

Copilot review round 12 (5238775831): all 6 fixed in b4efb47.

Inline (1)

• "Fixed by [Blocked upstream] Tasks requests over Streamable HTTP omit the required Mcp-Name header (SEP-2663) #1917" contradicts the unreleased status: fixed. Replied in the thread.

Suppressed (5)

1. ToC missing the unblocked-work section: fixed.
2. Matrix proposal ignores Tasks: fixed. The same upstream PR should propose a Tasks column.
3. Roadmap not indexed in the README: fixed. Confirmed it was absent from the Documentation table and added a row.
4. SEP-2484 scope overstated: fixed. Now scoped to Standards Track SEPs that change observable protocol behavior, per its Specification section.
5. Interceptors cites a stale SEP: fixed. Confirmed SEP-2624 ("Interceptors for the Model Context Protocol", open) is the current proposal; the row cites it and keeps SEP-1763 as the original.

npm run format and npm run local:gate both pass.

[Copilot]

🔵 Needs a closer look

Unresolved roadmap consistency and extension-coverage corrections remain.

Review details

Suppressed comments (4)

Previously missed (1) — in code that hasn't changed since the last review.

docs/inspector-roadmap-2026-h2.md:59

• Once §4 is read, this “one known exception” is no longer accurate: the same revision records #2403 as an open compatibility bug and #2404 as an open modern skills/get conformance gap. Either scope this sentence to the base protocol or acknowledge the extension gaps so the overview does not contradict itself.

docs/inspector-roadmap-2026-h2.md:456

• §1 also explicitly lists #1944 (*.localhost) and #1911 (trusted-local-host OAuth) as closed not planned, so “individual connection bugs have been fixed” overstates what shipped. Narrow this to the fixes listed as shipped (or say addressed/closed as not planned) before describing the remaining opaque error.

The individual connection bugs have been fixed (§1), but a failure is still reported as a

docs/inspector-roadmap-2026-h2.md:348

• The candidate set here is limited to ext-*/experimental-ext-* repositories, but the official overview currently lists MCP Tasks as an official extension without an ext-* repository (it links directly to the Tasks documentation). The sweep would therefore discover Tasks only through the one-time bootstrap and would miss any future official extension represented only in the overview, so it cannot provide the promised automatic coverage. Make the overview the authoritative official candidate set and use repository enumeration only to enrich it and discover experimental entries.

- **An extension-watch sweep**, modelled on `scripts/sdk-watch.mjs`: on a schedule, list the
  org's `ext-*` and `experimental-ext-*` repositories, use `/extensions/overview` for official
  membership and read each extension's identifier from its own specification or repository (the
  overview lists names and links, not identifiers), and file one issue per entry it has not filed before. As in the SDK watch, the **issue markers

docs/inspector-roadmap-2026-h2.md:91

• #1944 is included here as evidence for the shipped connection fixes, but the same issue is listed below as closed not planned (and its requested *.localhost behavior is not the version-negotiation, dev-container, ghost-entry, or self-signed-cert work named in this row). This makes the shipped inventory internally contradictory; please remove #1944 from this row or split out and explicitly name only the subset that actually shipped.

| Connection fixes (version-negotiation DX, dev containers, ghost entry) and self-signed `https://localhost` guidance (documented trust configuration, not a code fix) | [#962](https://github.com/modelcontextprotocol/inspector/issues/962), [#1936](https://github.com/modelcontextprotocol/inspector/issues/1936), [#1951](https://github.com/modelcontextprotocol/inspector/issues/1951), [#1914](https://github.com/modelcontextprotocol/inspector/issues/1914)                                                                                                                                                   |

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite (auto)

Note

Copilot is running an experiment and ran this review at Lite.

[cliffhall]

Copilot review round 13 (5238966809): 3 fixed and 1 declined, in 4bc4643. This round had no inline comments, so every finding is answered here.

Suppressed (4)

1. "One known exception" contradicts CLI and TUI advertise io.modelcontextprotocol/ui although they cannot render MCP Apps #2403/Modern skills/get results must carry ttlMs and cacheScope (ext-skills stable spec) #2404: fixed. The sentence now reads "one known base-protocol exception" and points to §4 for the open extension gaps.
2. "Individual connection bugs have been fixed" overstates: fixed. It now names only the §1 fixes that shipped and notes that Add support for *.localhost domains #1944 and Opt-in OAuth HTTP exception for trusted local development hosts #1911 were closed as not planned.
3. The sweep would miss official extensions without an ext-* repo: fixed. /extensions/overview is now the authoritative official set, since Tasks has no ext-* repo. experimental-ext-* repositories are enumerated to discover experimental entries, and ext-* repositories only to add detail to official ones.
4. Add support for *.localhost domains #1944 appears in the shipped connection-fixes row: declined, it does not. That row cites Improve DX for protocol version negotiation errors #962, inspector v2 fails to connect to MCP server at https://localhost #1936, Not working in dev containers #1951 and Bug: a failed server-list refresh after adding a server closes the modal with no error #1914. Add support for *.localhost domains #1944 appears only in the not-planned sentence, matching its NOT_PLANNED state.

npm run format and npm run local:gate both pass.

[Copilot]

🟡 Changes recommended

Documentation inconsistencies in extension classification, support criteria, source auditability, result handling, and revision-date alignment remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (5)

docs/inspector-roadmap-2026-h2.md:329

• This row says the Web/CLI/TUI columns measure rendering support, but marks the CLI as partial solely because it has the --app-info metadata probe, which does not render an App. That makes the table's criterion ambiguous; either define the columns as overall extension support (and define 🟡) or mark the CLI unsupported for rendering while retaining the probe in the note.

| MCP Apps                         | `io.modelcontextprotocol/ui`                               | ✅  | 🟡  | —   | Inspector row, cell blank | Apps tab. Columns are rendering support: rendering needs a browser, so the CLI has only the `--app-info` metadata probe and the TUI nothing. The shared client still advertises the extension from CLI and TUI, which is a compatibility bug tracked in [#2403](https://github.com/modelcontextprotocol/inspector/issues/2403). |

docs/inspector-roadmap-2026-h2.md:13

• This new section delegates its entire “unblocked work” list to a Claude.ai artifact rather than a versioned file in this repository. The artifact can be unavailable or change without a PR, so readers cannot audit what “no external blockers” means from the roadmap commit. Please copy the list into a tracked docs/ section or file (the link can remain as an optional supplement).

[Inspector Unblocked Work](https://claude.ai/artifact/MTFGsTVbKCqMchA1JYHo83) lists the roadmap items that depend on nothing outside this repo.

docs/inspector-roadmap-2026-h2.md:197

• “Legacy results carry none” is stronger than the protocol and implementation support: the modern requirement is era-specific, while the legacy Skills schemas are permissive and can retain ttlMs/cacheScope when a server sends them. Assuming none would omit valid hints; please say legacy results do not require these fields and display them when present.

| **Cache hint display** — `ttlMs` / `cacheScope` on the SEP-2549 surfaces (`tools/list`, `prompts/list`, `resources/list`, `resources/templates/list`, `resources/read`), plus modern (2026-07-28+) `skills/list` and `skills/get`, which the stable ext-skills spec requires to carry both fields (our `skills/get` validation still treats them as optional: [#2404](https://github.com/modelcontextprotocol/inspector/issues/2404)); legacy results carry none, with freshness countdown and "stale" marking                                 | 🟢         | SEP-2549 is Final. The runtime parses the hints everywhere and honors them through the SDK cache for the four `*/list` methods; `resources/read`, `skills/list` and `skills/get` go through plain requests that validate but do not honor them, so this item includes that plumbing as well as the display.                                                                 |

docs/inspector-roadmap-2026-h2.md:331

• The all-✅ Skills row overstates what this client family implements. core/mcp/skills.ts:24-27 explicitly says the Inspector is not a host and omits activation, per-skill consent, and content-bound approval; the official matrix cited here also marks MCP Inspector “Partial.” Please mark these cells partial, or define the checkmark as inspection-only and call out the missing host behavior.

| Skills over MCP                  | `io.modelcontextprotocol/skills`                           | ✅  | ✅  | ✅  | "Partial" (CLI README)  | [#2234](https://github.com/modelcontextprotocol/inspector/issues/2234), [#2248](https://github.com/modelcontextprotocol/inspector/issues/2248).                                                                 |

docs/inspector-roadmap-2026-h2.md:9

• The header says this was revised on 2026-09-16, but the new support table is explicitly "as of 2026-09-17" and cites #2404, which was opened on 2026-09-17. Please update the revision date (or align the support snapshot) so the document's source snapshot is unambiguous.

**Status:** Draft for WG review — **revised 2026-09-16** against the published MCP roadmap of 2026-08-22 (#2400)

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite (auto)

Note

Copilot is running an experiment and ran this review at Lite.

[cliffhall]

Copilot review round 14 (5239129138): 5 fixed and 1 declined, in 85f4ecc.

Inline (1)

• [Blocked upstream] Tasks requests over Streamable HTTP omit the required Mcp-Name header (SEP-2663) #1917 is an extension gap, not a base-protocol one: fixed. Replied in the thread.

Suppressed (5)

1. Apps CLI 🟡 conflicts with the rendering criterion: fixed. CLI is now — like the TUI, and the --app-info probe is mentioned in the note.
2. Unblocked list lives only in an artifact: declined. Same finding as rounds 3 and 11; the maintainer chose to keep the public link.
3. "Legacy results carry none" is too strong: fixed. Legacy results do not require the fields, but hints are shown when a server sends them.
4. Skills all-✅ overstates host behavior: fixed by defining the checkmark. Confirmed core/mcp/skills.ts explains that the Inspector is not a host and omits activation, consent and approval by design. The note now defines ✅ as full inspection support, which also explains the upstream "Partial", and the matrix proposal keeps Skills as "Partial".
5. Revision date predates the snapshot: fixed. The revision date is now 2026-09-17.

npm run format and npm run local:gate both pass.

[Copilot]

🔵 Needs a closer look

The roadmap has four unresolved documentation corrections identified in review.

Review details

Suppressed comments (4)

Previously missed (1) — in code that hasn't changed since the last review.

docs/inspector-roadmap-2026-h2.md:13

• This newly added top-level roadmap link points to a Claude Artifact, whose contents are gated by Claude login/sharing and are not versioned with the repository. Because the section contains no inline list, readers without access cannot determine which work is actually unblocked, and the roadmap can lose this dependency if the artifact changes or expires. Please inline the list or link a committed Markdown document instead.

docs/inspector-roadmap-2026-h2.md:331

• The ✅ status is inconsistent with the document's own #2404 note: the current modern skills/get path accepts responses missing the stable extension's required ttlMs and cacheScope, so the Inspector does not yet provide full conformance inspection for Skills. Please mark this row partial, or explicitly qualify the checkmark as basic list/get/digest support while exposing the validation gap in the table.

| Skills over MCP                  | `io.modelcontextprotocol/skills`                           | ✅  | ✅  | ✅  | "Partial" (CLI README)  | [#2234](https://github.com/modelcontextprotocol/inspector/issues/2234), [#2248](https://github.com/modelcontextprotocol/inspector/issues/2248). Checks mean full **inspection** support (list, get, digest verification). Host behaviors (activation, per-skill consent, content-bound approval) are out of scope by design, since the Inspector is not a host (`core/mcp/skills.ts`); that is also why the upstream matrix says "Partial".                                                                 |

docs/inspector-roadmap-2026-h2.md:251

• This wording reintroduces the earlier false-positive check: it would flag every result that includes structuredContent but omits the optional backwards-compatibility TextContent block. Please scope the diagnostic to disagreement when both representations are present, or to missing structuredContent when a declared outputSchema requires it; otherwise compliant no-schema results will be reported as problematic.

| **Serialized-JSON check for `structuredContent`** — when a result carries `structuredContent`, flag the absence of a `TextContent` block holding its serialized JSON, the one relationship the spec defines (a SHOULD, "for backwards compatibility"). Reported as a diagnostic, never an error; any other text is a legitimate summary and is not compared | 🟢 | Useful today, and implementation evidence for the Core Primitives WG. A missing `structuredContent` under a declared `outputSchema` is already flagged by `validateToolOutput` (shipped). |

docs/inspector-roadmap-2026-h2.md:282

• This restates SEP-2484 as applying to every Standards Track SEP, but the SEP only requires a conformance scenario for Standards Track SEPs that change observable protocol behavior; Process, Informational, and non-observable SEPs are exempt. The broader wording here contradicts the qualified description in §2 and can make the conformance scope look mandatory for the wrong proposals.

(Final), which requires conformance tests for Standards Track SEPs to reach Final. §3.5 makes

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite (auto)

Note

Copilot is running an experiment and ran this review at Lite.

[cliffhall]

Copilot review round 15 (5239326738): 2 fixed and 2 declined as repeats, in d7c1f9f.

Suppressed (4)

1. Unblocked list lives only in an artifact: declined (4th time — rounds 3, 11, 14). The link is public and the maintainer chose it deliberately.
2. Skills ✅ conflicts with the Modern skills/get results must carry ttlMs and cacheScope (ext-skills stable spec) #2404 note: fixed. The row now says the inspection surface is complete with one open validation gap, naming Modern skills/get results must carry ttlMs and cacheScope (ext-skills stable spec) #2404.
3. structuredContent check scope: declined (4th time — rounds 5, 9, 11). Round 3 asked for exactly the current scoping, and the review has since asked to reverse it three times. The row follows the single relationship the spec defines, as an advisory diagnostic.
4. §3.6 restates SEP-2484 too broadly: fixed. Now scoped to Standards Track SEPs that change observable protocol behavior, matching §2.

---

On the review loop. Findings per round: 2, 10, 8, 3, 10, 5, 4, 6, 8, 6, 7, 6, 4, 6, 4. Fifteen rounds in, each new round is mostly re-raising findings already answered with evidence, and the remaining items are wording preferences on a planning document rather than defects. Every substantive finding has been fixed or answered, and two real code gaps it surfaced are filed as #2403 and #2404. Unless a reviewer asks for another pass, this is the last round I will request.