Inspector V2 Working Group Meeting - Jun 24, 2026

Agenda

• Items on the V2 board and planning
• Discuss Client Profiles, the shape, storage, and maintenance UX.
• Status update on OAuth changes needed for the July spec release
• Discuss progress toward readiness for a release candidate.

Attendees

• Cliff Hall
• Bob Dickinson
• Ola Hungerford

Discussion

Enterprise Managed Authorization (EMA). @BobDickinson integrated EMA / Cross-App Auth and validated it end-to-end against the xa.dev authorization server, extending the composable test MCP server so it can act as its own configurable authorization server. That finally gives the group an in-house apparatus for exercising every flavor of OAuth locally — historically the hardest thing to test. @cliffhall: "it always comes down to ... do I have a good go-to server ... we should really have that capability in house." The UX impact is deliberately tiny (a checkbox under OAuth, a connect button); as @BobDickinson put it, "when it works, it's just sort of magic. You just click connect and it's connected." The connection-info tab now surfaces an OAuth section showing mode (OAuth vs. EMA), client ID, scopes, and a decodable access token so authors can verify the issuer and audience.

Config import — client and registry. @cliffhall demoed importing servers from a client config (per-client lookup strategies) or a registry config, with per-server import/skip and overwrite/rename/skip on name collisions, animated borders marking freshly added servers, and tabs hidden when a capability isn't present. @BobDickinson flagged a bug — the Tools tab shows even on resource-only servers (e.g. the EMA test server) — which @cliffhall will fix. @BobDickinson offered a full-disk scanner from his own tooling (optimized scan with skip-dirs) as an alternative discovery mechanism; the group judged a whole-drive scan overkill and a privacy concern for this audience, keeping the targeted manual approach.

Server config form & parameterization. The parameterized-config form is the tricky part — anything that can vary (env vars, tokens injected into headers) needs UX. @cliffhall found the settings dialog is missing UI for the working directory (CWD) and environment variables on stdio servers even though both are already collected and persisted to the catalog; he'll wire up those fields. @BobDickinson reiterated the value of keeping a reference to the originating server.json / URI so a server can later be reconfigured through the same generated UI, and offered his existing validator/linter (schema checks plus ~20 rules for malformed server files) to harden the current debounced validation.

Registry browser. @BobDickinson has a registry mirror/browser (search, version pinning, configure-from-form, lint). The group agreed integrating it — "I'm getting ready to put something up on the registry; is this good?" — is a natural next step but a follow-on release; @BobDickinson will open an issue and capture notes so it isn't lost.

Client settings → client profiles. @BobDickinson added a gear-icon "Client Settings" dialog serialized to a client.json via the existing storage API — one store per Inspector instance today, intended as the foundation for profiles. The driving use case is emulating other clients to test server fallbacks: writing an Open FGA MCP server that uses URL elicitation for OIDC, he needed to make the Inspector behave like a client that doesn't support it. "I want Inspector to act like Claude Code ... I want it to not support URL [elicitation] ... I want to be able to switch back and forth." Profiles would be named collections of capabilities/protocol level you toggle between — @BobDickinson: "I want to pick the protocol level and ... the capabilities within that protocol level ... and then that's now like a profile." @olaservo backed simulating common real-world failure modes (clients sending invalid requests), and the group converged on assigning a profile per server rather than jamming capabilities into server settings. Operationally, switching a profile means disconnect/reconnect.

Client-settings cog stays live while connected. The team decided not to disable the settings cog during an active connection. Logging out of the IDP mid-session is a legitimate test (the connected client should keep working until the access token expires, then re-trigger the flow), so the dialog must stay reachable. Changing values while connected may cause unpredictable behavior, but — with the debounced save-as-you-type model offering no natural confirmation point — that's left as the user's responsibility, likely with a "this is hot" indicator and a documentation note.

Retiring guided OAuth. @cliffhall, @BobDickinson, and @olaservo agreed to remove the legacy guided-OAuth walkthrough. With the whole exchange now happening server-side, the network tab plus the new connection-info OAuth section already expose everything needed to debug — @BobDickinson: "what we have right now might be enough because ... it's all there." It's less hand-holding but, as @olaservo noted, "I don't feel that the walkthrough is a super important thing for us to solve"; conceptual OAuth teaching belongs in docs/skills, not embedded in the Inspector. Removing it also kills a large to-do (figuring out guided OAuth for EMA) and simplifies the codebase.

Storage refactor. @BobDickinson will fold an OAuth cleanup into a single PR: drop the remnant Zustand wrapper still framing the file I/O, and consolidate the browser-based and file-based stores into one file-based implementation so the CLI, TUI, and web all share OAuth state (today the web client uses the browser store while CLI/TUI use the file store). This also dodges a long-standing V1 bug where "clear OAuth" misses a key in the browser store.

Release readiness & parity. @cliffhall has been using V2 exclusively for weeks — "pretty well-formed" — with no-ops, placeholders, and to-dos cleared. The near-term goal is a group assessment confirming parity with V1 so V2 can replace it, targeting end of Q2 (end of the month) per the charter. The release ships as the official package (a new 2.0 under the same npm name), dropping the separate CLI/proxy publishing in favor of the launcher. @olaservo has been defaulting to the V2 TypeScript SDK for full JSON-schema support; Konstantin wants to brief the group on SDK changes next week (this meeting slot or a special call).

Contribution policy. The group will restrict external code PRs in favor of well-formed issues, to keep design control and curb low-quality/AI-generated contributions. @BobDickinson's framing: if a contributor has already fixed something locally, "take the prompt that you used and put that in the issue ... if all we're doing is converting a good prompt into an issue, we'd rather use our tooling to do that." Acceptance criteria are essential — @cliffhall: it's "the most important thing." They'll add a CONTRIBUTORS.md and, per @olaservo, put explicit hints and links in the agent-facing files (AGENTS.md / CLAUDE.md) to the policy and issue templates, since agents routinely ignore .github/dot folders. The new org-wide shared AI policy (pending merge in the modelcontextprotocol repo) should also be referenced.

Publishing permissions. Frustration over NPM admin being a single point of failure (Paul) and the trusted-publisher setup that ties publishing to a specific repo/branch — which blocks shipping a 2.0 beta from v2/main. @olaservo flagged the security angle: "it's a ... risk when you're getting all these critical security vulnerability alerts and then we can't release something to patch it" (the servers repo publish is still broken). The plan: pin down Linux Foundation rules on maintainer access, do housekeeping on stale approvers (e.g. Adam), and take a concrete ask to Dan and the maintainers channel.

Recruiting testers. The team wants more hands on V2: review Tobin's large apps-testing PR (and the proposed inspector debugger view), and promote testing via Discord, LinkedIn, and the AI-fund channels — encouraging users to build v2/main locally for now, since publishing an interim beta isn't straightforward under the current setup.

Next Steps

• Cliff Hall: Hide the Tools tab on servers with no tools; add the settings-dialog UI for stdio CWD and environment variables (and verify); draft a CONTRIBUTORS.md formalizing the issues-first contribution policy.
• Bob Dickinson: Open an issue / write notes for the registry-browser integration; land an OAuth cleanup PR (remove guided OAuth, drop the Zustand wrapper, migrate the auth store to the file-based implementation); weigh the pros/cons of client profiles for server settings.
• @olaservo: Take a concrete ask to Dan and the maintainers channel for the repo-admin / NPM trusted-publisher rights needed to unblock releases.
• The group: Assess V2 against V1 for feature parity; add contribution-policy and issue-template hints to the agent-facing files; review Tobin's apps-testing PR; test V2 and log gaps on the V2 board (label v2) or ping Cliff; recruit testers via Discord, LinkedIn, and the AI-fund channels.

Transcript

• Gemini Meeting Transcript / Summary

Operational Details

• Our Charter
• Weekly Working Group Meeting takes place Wednesdays 11am EST on Google Meet
• Agenda / Meeting Notes are published on GitHub Discussions
• We are planning on an Inspector V2 kanban board in GitHub Project
• We are building on a v2/main branch of the Inspector repo
• We are experimenting on a v1.5/main branch of the Inspector repo
• View the Open pull requests labeled as V2
• View the Open issues labeled as V2