fix: hard-coded CLI inspector version

[richardkmichael]

Motivation and Context

The CLI is hard-coded at version 0.5.1, from when it was merged in #177 f4e6f4d.

It can use the package.json version, as does the client.

How Has This Been Tested?

Tested by inspecting raw protocol messages.

Incorrect version on main:

{
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-03-26",
    "capabilities": {},
    "clientInfo": {
      "name": "inspector-cli",
      "version": "0.5.1"
    }
  },
  "jsonrpc": "2.0",
  "id": 0
}

Corrected:

{
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-03-26",
    "capabilities": {},
    "clientInfo": {
      "name": "inspector-cli",
      "version": "0.14.3"
    }
  },
  "jsonrpc": "2.0",
  "id": 0
}

Breaking Changes

Unlikely.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Broader discussion

I have few questions and comments, but Discussions aren't enabled, so I'm not sure where to raise
them --

TL;DR:

• Should the server use NodeNext modules?
• Should "noUncheckedIndexedAccess": true be used throughout? Potential errors are detected.
• Code consistency across the sub-packages would be helpful

Despite this being a very tiny change, the varying TypeScript configurations across the sub-packages
tripped me up quite a bit, so I investigated a few details. Overall, consistency throughout the
monorepo would result in less confusion when reading and working with the parts of the inspector.
Generally lower cognitive overhead -- because, personally, when the same thing is accomplished in
multiple ways, it slows me down because I wonder why and which is correct or preferrable; especially
with unfamiliar code. Maybe this is second nature to experienced TS developers, working in
difficult contexts?

For example, the package.json import in the cli and client here.

The cli TypeScript config uses NodeNext modules, which requires an import attribute (... with: { type: "json" }).

The client uses ESNext (and bundler configuration), which tolerates an import attribute. So
the quickest approach would be to add the import attribute in the client files,
useConnection.tsx and Sidebar.tsx.

However, I could not find an easy way to enforce it (detection), so one needs to know. I briefly
checked the TS compiler options and eslint-plugin-import; a custom rule might be needed, which is
a bit too crufty, IMO.

Alternately, change the CLI to Node16 (used by the server and the TypeScript SDK). This would
eliminate the requirement of an import attribute. It seems less preferable because enforcing modern
usage is ideal. Perhaps the server should go to NodeNext too?

Somewhat related, the cli compiler config uses "noUncheckedIndexedAccess": true, which caught
the potential bug in the destructuring of split() (but not in the client). If this option is
enabled on the client and server, there are many errors. Should it be enabled?

[olaservo]

Hi @richardkmichael thanks for catching this and for bringing up the inconsistencies. If you could fix the linting error in the CI I think we can go ahead and merge the CLI version fix. I created this to track the points you brought up here and discuss them further: #588
And if we find that too clunky I think we can use the Community Working Groups Discord server (which I think I already linked you to elsewhere?)

[richardkmichael]

@olaservo

If you could fix the linting error in the CI I think we can go ahead and merge the CLI version fix.

I didn't notice, sorry! Fixed.

I did this without changing the eslint config. I find underscore prefixed unused variables to be self-documenting and less error prone, but the eslint configuration only permits the terser, omitted style. Not intending to bikeshed, just mentioning in case you wonder.

[olaservo]

Hi @richardkmichael was revisiting this one and it looks like there's some conflicts - besides that I think we're good to merge this, would you mind resolving those? Thanks!

[richardkmichael]

@olaservo I extracted the identity to a constant, aiming to reduce test brittleness. If you prefer a more straight-forward conflict resolution, it's just the string change in the test; I can drop the most recent commit for that resolution only.

Making changes