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?