Inspector V2 Working Group Meeting - Aug 12, 2026

Agenda

• Milestone planning
• 2.2.0 Release
• Servers repo maintenance

Attendees

• Cliff Hall
• Bob Dickinson
• Ola Hungerford

Discussion

A wide-ranging session: Windows triage, the 2.2.0 release contents, and then a long stretch on the servers repo — what it should still hold, why the file system server needs a new owner, and where the composable test server actually belongs. Closed on two forward-looking protocol threads, triggers/events and interceptors.

Nobody has a Windows machine, and that is now a stated position. The meeting opened on the fact that the group tests on Linux and Mac, with @olaservo as the de facto — her words — "sacrificial Windows person." @cliffhall has VMware but no Windows instance on this laptop (the old VM images, back to Windows 98, never got copied over), and is considering Parallels instead since VMware is retreating from Apple hardware. Both he and @BobDickinson described the same basement-archaeology approach to old laptops: wipe Windows, install Ubuntu, keep the drives.

The practical outcome was triage. The open Windows items — the TUI coverage-gate flake under V8, verify:typecheck-coverage, and the other build/test failures — were moved to medium priority: "we're not really that concerned about people who are checking out the code on Windows and running into build or testing problems at the moment," since they are not stopping users from doing things. @olaservo raised the one real counter-case, thinking out loud: even with drive-by PRs off, someone who reported a bug may want to pull latest and verify the fix without waiting for a release. Medium, not dismissed — @cliffhall: "I don't mean to completely dismiss the entire category of people."

The SDK gates most of the roadmap. The missing Mcp-* param header on tasks turned out to be an SDK problem with a PR already open (Konstantin pinged, no reply yet), which prompted @olaservo's broader observation from reading the roadmap drafts: "a lot of times it's really the SDK that has to implement a new thing first." The split both landed on: an extension that doesn't need core support (the Skills-over-MCP model) the Inspector can pick up immediately; anything else waits. Tasks is expected to be rolled into the TypeScript SDK itself rather than shipped as an independent extension package — ext-apps remains the one standalone example so far.

That raises a maintenance surface @olaservo flagged as coming: the extension/SDK version matrix. The apps extension currently isn't on the latest TypeScript SDK, and "there's going to be more and more of that." Consolation prize — the expertise required is at least confined to TypeScript, not every language. @cliffhall's dependency cleanup hit exactly this: two copies of the v1 SDK (1.29 and 1.30) in the tree, pulled in through the apps SDK, when v2 doesn't need the v1 SDK anywhere at all.

2.2.0 shipped today — two urgent fixes and a packaging guard. The two urgent items were the Windows fixes and the missing apps sandbox proxy file, which left MCP Apps completely non-functional in the published package while working fine in the repo. That is the second time a "works locally, broken once published" failure has landed (the other time back in the V1 era), so the release adds a pack:verify script that installs the real tarball and asserts everything that must be in it is. Also in: float input in tool forms, structured-content rendering (results now show a structured section when one is returned), duplicate tool names no longer breaking the list display, a Firefox hang, the TypeScript SDK 2.0.0 upgrade (freshly released, so a good moment), the ink bundling fix, a v1→v2 migration guide, and a Docker fix.

One incidental find: the TUI's "you have not competed yet" message is a typo in upstream ink, not in Inspector code. @cliffhall opened an issue on their repo and patched it locally via a plugin over the ink components. @olaservo: "that's how you know AI didn't generate that line, because only a person could make that mistake when typing." @BobDickinson's read on the tool-form UX generally — "pretty clunky, it does sort of work" — met agreement that it exists now and can therefore be improved.

Docker needs a real documentation page. Running the Inspector container without mounting the configuration directory means --rm wipes the saved servers every time. The suggested command and the Dockerfile were updated, but with more Docker work coming, @cliffhall wants proper coverage on the main documentation site of how to use Docker with the Inspector successfully.

Everything server V2: publishing first, then one big PR. @olaservo has the V2 branch on servers plus a large PR bringing the everything server up to the V2 spec, building on Konstantin's earlier TypeScript V2 update. The publishing changes go first regardless, since semantic versioning on the npm packages is what makes the rest manageable. PyPI access is sorted; her npm invite still 404s and she has given up on diagnosing it for now.

Both agreed the everything-server PR does not need breaking down — @cliffhall's experience with the code-mod approach on the Inspector suggests it is mostly imports, and you cannot half-upgrade "everything" anyway. He and @olaservo will both review, test, and merge on confidence.

The file system server should be handed off. @olaservo made the case directly: it breaks every couple of months without the team changing anything, and someone external comes in to fix it — it has effectively become a Claude Desktop dependency, with a desktop-extension wrapper layered on top of the open-source library. "We're kind of responsible for the security of these things and I don't know if people are really thinking to go in and maintain it." @cliffhall agreed — it is "a magnet for security vulnerability stuff" — and both see Den, now inside the core maintainers and Claude team, as the person to route the handoff through. The key distinction: every other server in the repo is an example, not a production dependency, and file system is the one that is genuinely being relied on as a service.

Should the servers repo grow at all? Probably not. @cliffhall floated adding servers that demonstrate different things now that the state of the world is less chaotic. @olaservo pushed back from her own recent experience: pointing an agent at the TypeScript SDK repo plus the spec now produces good results, since the SDK's examples have improved a lot — so examples may belong in the language SDKs or the docs, where people look first. She also invoked Den's roadmap goal that the spec and documentation should be good enough to generate an SDK, let alone a server, from.

The stronger argument was volume. The servers repo is in GitHub's top 1% for traffic, "it's forever going to be a thing where people are like, I'm trying to add my server here," a chunk of it is already archived, and the security alerts pile up on two fronts — Dependabot (manageable) and drive-by vulnerability reports (not). Having Python and TypeScript in one repo also makes publishing awful; the quickstart-resources repo has the same problem across eight languages. @olaservo: "I think we should be removing things from there." @cliffhall's conclusion — "adding more stuff is really just asking for more work."

So: drive-by PRs get shut off on servers too, the same move made on the Inspector, which was itself driven by anxiety over the servers repo's volume. @olaservo will set it up now that the Inspector work has settled. "Put my server in there" issues are easy to close; the goal is to stop urgent issues being buried under a hundred copies of the same one.

The composable test server stays with the Inspector — and may be published from it at some future point. @BobDickinson came into the meeting open to moving it to servers and left convinced otherwise: "that conversation has convinced me that the composable server does not belong in the servers repo." It isn't an example — it is complicated and hairy, and only incidentally instructive when it happens to implement some obscure feature nobody else has. What matters about it is the CI harness: "I don't want to make 50 bespoke servers to demonstrate every permutation of this set of things."

The middle ground both liked is the one raised last week: publish it as a package from the Inspector repo, framed as the counterpart to the Inspector — if you're building a client and need a server to manifest some behavior, you shouldn't have to build one. @BobDickinson had just hit this himself, building his own throwaway server because he had no clean way to pull the composable server in as a dependency. He's clear-eyed about the audience: "there's like 10 people in the world building clients and we're one of them. There's a million people building servers." Small, but it matters to the people it matters to. @cliffhall's use of it is already routine — tell Claude to build a smoke test with a server that does X, Y and Z — with the ones worth keeping enshrined as configs.

Conformance suite over the composable server. @BobDickinson carried forward last week's thread with direct experience: he ran the conformance suite against a hand-rolled protocol on another project, building small harnesses around it, and it worked well. "It's not as beefy as I thought it was going to be," but it caught a real bug — and it would have caught the missing param-in-header bug here. He is confident it can be run against the test server and will look at whether there is a way to run it against the client too.

Triggers and events look further along than they appear. @BobDickinson liked the roadmap document (#1981, kept as a document rather than folded into the release) and singled out triggers and events. A member of that working group did a full walkthrough at the event @olaservo spoke at, and both had the same reaction: the public signals — one PR, quiet Discord, quiet SEP — badly understate the progress. "It looks like one of those wandering-around working groups, but actually they're almost done."

On the reachability question, @BobDickinson was unbothered from experience with webhook client/server work: it is the client's problem, full stop. The Inspector exposes a path that waits on the webhook and hands the user the URI; making it reachable from the other end is up to them. "Every time I've done it, that's how it worked." Mechanically it comes down to long poll, short poll, or webhook — all three doable without much trouble.

Interceptors — and what integrating them would mean for the Inspector. @BobDickinson introduced the concept: a way to hook a client, server, or gateway so all MCP traffic runs through something that can inspect and potentially mutate it. The problem it solves is what he calls "gateways all the way down" — each MCP gateway does one specific thing, so you end up stacking them and every layer adds mess. Instead, one gateway calls a series of interceptors — DLP here, some other policy there — as pluggable policy engines over the traffic.

For the Inspector the use case is a sidecar: run every MCP call the Inspector sends through a configured chain of interceptors. The tricky part is surfacing them — you need some indication that an interceptor was called, what it returned, and whether it mutated the payload. His own suggestion for a V1 is that the HTTP log may already be enough, since it's all visible there. @cliffhall sees UI work in it regardless: configuring their settings, seeing what came in and what went out. One structural note that makes it easier and harder at once — interceptors are MCP servers, so the Inspector could treat one as just another URI you type in, except it sits in the client context rather than being the server under test.

Dependency placement and rule creep. The claude.yml changes in this release don't matter much day to day, but forked PRs being shut off left the workflow without a backstop if it were ever re-enabled, so it now aligns with the policy. On dependencies, @cliffhall wants a clean sweep moving everything to the top-level package.json — the SDK was in five places in the last version, with a script to update them all and verify it was done right — while acknowledging a blanket rule might be too simplistic.

That fed into the meeting's closing thought, prompted by an as unknown as cast that had crept into a useServers response entry. @BobDickinson: "I feel like that should just be a linter rule." It is a rule — which is the point. Rules accumulate in AGENTS.md every time something goes wrong, the file gets big, and then "sometimes all the rules don't get clearly followed." @cliffhall thinks the time has come to simplify the rule set rather than keep growing it.

Next Steps

• Cliff Hall: Review the everything server V2 PR (imports and structural changes); add Docker usage instructions to the main documentation site; look at simplifying the AGENTS.md rule set, including promoting as unknown as to an enforced lint rule.
• Ola Hungerford: Merge the Python everything-server publishing updates; land the everything server V2 PR after review; disable drive-by pull requests on the servers repo; raise handing file system server maintenance to the core maintainers.
• Bob Dickinson: Investigate running the conformance suite against the composable test server, and whether it can be pointed at the client too.
• The group: Move remaining dependency declarations up to the top-level package.json to keep versions consistent; decide whether the composable test server gets published as a package from the Inspector repo; keep the Windows testing items at medium priority.

Transcript

• Gemini Meeting Transcript / Summary

Operational Details

• Our Charter
• Weekly Working Group Meeting - Wed 11am EST on Google Meet
• Agenda / Meeting Notes - published on GitHub Discussions
• Inspector V2 board - maintainer planning and issue triage kanban
• v2/main - v2 Inspector, merged to main for milestone releases
• v1/main - deprecated v1 Inspector, urgent security patches only
• Open pull requests labeled as v2
• Open issues labeled as v2

Repo contributions

• We now accept issues only, no drive-by PRs. We triage the issues and build the feature or fix, ensuring specification, idiomatic style, and quality gates are observed
• ** If you are an organization member with write access to the repo**, we ask that you follow the above procedure, but even if you submit a PR, also create and link an associated issue for tracking.

WG Leads:

• @olaservo
• @cliffhall
• @BobDickinson