The report
Pinning the Git commit of an MCP server helps reviewers know which server code they approved. It does not necessarily specify the transitive packages that install beside that code. In Corelight's dependency analysis, repeated installations from an unchanged top-level source revision resolved different dependency sets over a multiweek period.
The reproducibility boundary
The investigators describe 15 distinct installed dependency sets over roughly five weeks, including changes in 23 of 69 package entries in one comparison. A source-code hash still matched the approved server. Yet a fresh install could execute code from an altered lower-level package because a floating version constraint, package index or resolver selected something different. This result does not allege that the newly selected packages were hostile. It shows that source identity alone is insufficient evidence of the runtime contents an agent will execute.
For an MCP tool with external effects, that distinction has operational consequences. A tool owner might test and authorize a stable repository version, later rebuild it and silently obtain different parsing, authentication or network behavior through dependencies. The Case dossier separates the demonstrated installation drift from any hypothetical attack on a package registry.
What must be pinned and measured
A reproducible build needs a resolved lockfile, immutable artifacts or verified package hashes, along with the actual environment used in testing. Teams should compare dependencies between approved and deployed builds rather than assuming a commit ID is a complete software bill of materials. This evidence supports a supply-chain integrity warning, not a claim that a named server was breached or that a listed dependency carried malware.