Reverse env variable sourcing order

[olaservo]

Reverses what overrides what when env variables are being applied.
Note, I am not sure this is actually what we should do, but will share more rationale below.

Motivation and Context

As noted in this issue , when the PATH is set for the Inspector process, it appears to get overridden with the defaults set by the SDK.

Looking at the order, it seems like it would make more sense to do this the other way around.

My reasoning is that if you are explicitly setting the PATH then you would want that path to be used.

How Has This Been Tested?

Wrote some ad-hoc scripts to test this outside of Inspector, just to verify that my custom PATH was being referenced. I can add some dedicated testing to the repo if we would like to make sure there aren't any other side effects.

Breaking Changes

Technically if users are expecting the existing behavior to be correct, then this could break existing usage.

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

[cliffhall]

@olaservo I agree that env vars should override defaults and query vars from the request should trump both. This seems correct. Maybe some videos of the tests for confidence?

[cliffhall]

Looks good and I approved because it is straightforward and the order is unquestionably more correct. However in local testing I was not successful in setting a PATH then running npm run start and then connecting to the everything server and invoking the printenv tool. It showed the PATH I usually see if I open a new terminal and printenv, not the one I set on the line. I added a console.log of the env just inside the start script and it didn't show the one I set for the test either, before your changes ever come into play.

I suspect it's because I'm doing npm run and not npx @modelcontextprotocol/inspector or something. I will look deeper tomorrow.

[olaservo]

Thanks @cliffhall ! Since nobody is really screaming for this, I think we can take a little more time to test since small innocent changes like this can end up having weird consequences. Testing through both a local build and npx makes sense as something we want to do consistently. What I usually do is publish my own experimental version to npm.

[cliffhall]

What I usually do is publish my own experimental version to npm.

@olaservo When you have a chance, would you mind publishing this one and trying something like:

PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin npx @olaservo/inspector then connect to the everything server and use the printenv tool to verify the PATH made it through?