AI & Agents

Your Pinned MCP Server May Not Be Pinned: One Ran on 15 Different Dependency Sets in Five Weeks

Leave a comment

Corelight’s James Lagermann found that an MCP server configured to run one fixed release ran with 15 different sets of dependencies over five weeks, with the config untouched, Help Net Security reports. Twenty-three of its 69 packages changed versions, including the cryptography library, the JWT library and the MCP SDK itself.

The assistants launched servers with uvx, which downloads and runs a Python package from one config line. Each entry named an exact release, version or commit. But for one community server, the launcher installed from declared dependencies and skipped the project’s hash-pinned lock file, so about 60 packages were resolved fresh from PyPI whenever the environment rebuilt. Corelight reviewed 35 MCP servers; 23 had a recommended install that would pull dependencies from a public registry on every launch or install. When it froze five servers (pinned to a commit, installed once from a hash-pinned lock file, launched directly, update checks off), their package lists stayed identical across 457 starts. Frozen code ages, though, so you still have to re-lock and update.

My take

MCP servers often hold your credentials. Pinning the top package isn’t pinning the tree. I wrote up how I check mine in today’s How-To.

God Bless, and May the Source Be with You!

References & Further Reading

Subscribe (RSS) Follow AI & Agents via RSS

Leave a note

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.