Verify your installed MCP package matches its published source before relying on it
You will confirm which MCP package version actually runs and that its installed code matches the source it claims to come from. This matters because published packages and repository source have drifted apart in real cases.
Trusting the package name and @latest
- Config says @latest, version unknown
- Installed code never checked against source
- Env variable silently ignored
Verified installed version
- Exact version pinned in client config
- Installed files compared to matching source tag
- Env behavior tested with an absolute path
- Recheck after each update
Why it matters
An installed MCP package is not always the code you expect. npm still served @modelcontextprotocol/server-memory 0.6.2 while the repository source was at 0.6.3, and the published build ignored MEMORY_FILE_PATH (source (opens external site)). A package can behave differently from its repository, so the only reliable check is the installed artifact your client executes.
Steps
-
Record the exact version your MCP client launches. Open the server entry in your client config and note the package name and version tag. Pin an explicit version rather than relying on @latest.
-
Find the installed files on disk. For a global npm install, look under your node lib/node_modules directory for the package folder and open its dist/index.js. Compare that path with the one the server reports at startup.
-
Compare the installed code against the source at the matching tag. Clone the repository, check out the tag or commit for that version, and diff the built output or the relevant source file. Look for the environment variable or behavior you depend on, such as whether MEMORY_FILE_PATH is read at all.
-
Confirm which release contains your fix. For the memory server, a maintainer said version 2025.4.25 was understood to include the fix (source (opens external site)). Install that version explicitly and repeat the diff.
-
Test the behavior directly. Set the variable to an absolute path, start the server, and confirm the file appears where you expect. Relative paths were not resolved against the project root even on @latest, so use absolute paths (source (opens external site)).
-
If the published package still differs from source, build from the repository and point your client at the local build. A node command pointing at dist/index.js with an env block in the client config works as a fallback (source (opens external site)).
-
Re-check after every reinstall or update. Hand edits to files inside node_modules are overwritten by updates, so repeat the comparison whenever the version changes.
Common mistakes
- Assuming the version tag in your config is what actually runs. Confirm it from the installed files.
- Trusting the repository alone. The npm artifact is what your client executes, so check that one.
- Editing files under node_modules and forgetting about them. Keep a note of the change or switch to a pinned local build.
- Assuming a fix in one server applies to another. The reference servers were rebuilt in v2, so check the specific package you use (source (opens external site)).
Checklist
0 of 7 done